Merge commit '0749c5bffa010dc94d32f3e1214b3e5f913094e2'

CHANGELOG.md

@@ -1,8 +1,37 @@
 Changelog
 =========
 
+[0.8.3](https://github.com/ordinals/ord/releases/tag/0.8.3) - 2023-08-28
+------------------------------------------------------------------------
+
+### Added
+
+- Tweaks to front-end (#2381)
+- Add some links  to docs  (#2364)
+- Add testing guide for recursion (#2357)
+- Make homepage more interesting (#2374)
+- Add proper block inscriptions HTML (#2337)
+- Render GLB/GLTF models in preview (#2369)
+- Add tags and inscription id documentation (#2351)
+- Add hint about maximum number of open files for testing (#2348)
+- Reduce index durability when testing (#2347)
+- Homogenize design (#2346)
+
+### Fixed
+
+- Fix slice error for inscriptions block view (#2378)
+- Use correct height and depth in reorg log (#2352)
+
+### Changed
+
+- Remove transaction ID to inscription ID conversion (#2370)
+- Return JSON from all commands (#2355)
+- Allow splitting merged inscriptions (#1927)
+- Update explorer.md (#2215)
+- Recognize media types without explicit charset (#2349)
+
 [0.8.2](https://github.com/ordinals/ord/releases/tag/0.8.2) - 2023-08-17
----------------------------------------------------------------------
+------------------------------------------------------------------------
 
 ### Added
 
@@ -14,22 +43,19 @@ Changelog
 - Add JSON API endpoint `/sat/<SAT>` (#2250)
 - Add `amount` field to `wallet inscriptions` output. (#1928)
 
-
 ### Changed
 
 - Only fetch inscriptions that are owned by the ord wallet (#2310)
 - Inform user when redb starts in recovery mode (#2304)
 - Select multiple utxos (#2303)
 
-
 ### Fixed
 
 - Use `--fee-rate` when sending an amount (#1922)
 - Fix typos in documentation (#2328)
 - Fix dust limit for padding in `TransactionBuilder` (#1929)
 - Fix remote RPC wallet commands (#1766)
 
-
 [0.8.1](https://github.com/ordinals/ord/releases/tag/0.8.1) - 2023-07-23
 ---------------------------------------------------------------------
 
@@ -55,7 +81,6 @@ Changelog
 - Fix docs inconsistency (#2276)
 - Add contributing section (#2261)
 
-
 [0.8.0](https://github.com/ordinals/ord/releases/tag/0.8.0) - 2023-07-01
 ---------------------------------------------------------------------
 
@@ -66,7 +91,6 @@ Changelog
 - Update redb from 0.13.0 to 1.0.2 (#2141)
 - Fix typo in BIP (#2220)
 
-
 [0.7.0](https://github.com/ordinals/ord/releases/tag/0.7.0) - 2023-06-23
 ---------------------------------------------------------------------
 
@@ -78,7 +102,6 @@ Changelog
 - Add blob urls to Content Security Policy headers (#2203)
 - Check inscribe destination address network (#2189)
 
-
 [0.6.2](https://github.com/ordinals/ord/releases/tag/0.6.2) - 2023-06-15
 ---------------------------------------------------------------------
 
@@ -91,15 +114,13 @@ Changelog
 ### Misc
 - Update ord dependency in lockfile (#2168)
 
-
 [0.6.1](https://github.com/ordinals/ord/releases/tag/0.6.1) - 2023-06-06
 ---------------------------------------------------------------------
 
 ### Changed
 - Fix sat index test and unbound assignment (#2154)
 - Updated install.sh for new repo name (#2155)
 
-
 [0.6.0](https://github.com/ordinals/ord/releases/tag/0.6.0) - 2023-06-04
 ---------------------------------------------------------------------
 
@@ -127,7 +148,6 @@ Changelog
 - Fix test name typos(#2043)
 - Switch to nightly clippy (#2037)
 
-
 [0.5.2](https://github.com/ordinals/ord/releases/tag/0.5.2) - 2023-04-17
 ---------------------------------------------------------------------
 

Cargo.toml

@@ -1,7 +1,7 @@
 [package]
 name = "ord-litecoin"
 description = "◉ Ordinal wallet and block explorer for litecoin"
-version = "0.8.2"
+version = "0.8.3"
 license = "CC0-1.0"
 edition = "2021"
 autotests = false

README.md

@@ -151,6 +151,10 @@ just doc
 just watch ltest --all
 ```
 
+If the tests are failing or hanging, you might need to increase the maximum
+number of open files by running `ulimit -n 1024` in your shell before you run
+the tests, or in your shell configuration.
+
 We also try to follow a TDD (Test-Driven-Development) approach, which means we
 use tests as a way to get visibility into the code. Tests have to run fast for that
 reason so that the feedback loop between making a change, running the test and

docs/src/SUMMARY.md

@@ -3,6 +3,7 @@
 - [Overview](overview.md)
 - [Digital Artifacts](digital-artifacts.md)
 - [Inscriptions](inscriptions.md)
+  - [Recursion](inscriptions/recursion.md)
 - [FAQ](faq.md)
 - [Contributing](contributing.md)
 - [Donate](donate.md)
@@ -12,6 +13,7 @@
   - [Sat Hunting](guides/sat-hunting.md)
   - [Collecting](guides/collecting.md)
     - [Sparrow Wallet](guides/collecting/sparrow-wallet.md)
+  - [Testing](guides/testing.md)
   - [Moderation](guides/moderation.md)
 - [Bounties](bounties.md)
   - [Bounty 0: 100,000 sats Claimed!](bounty/0.md)

docs/src/guides/explorer.md

@@ -5,6 +5,19 @@ The `ord` binary includes a block explorer. We host a instance of the block
 explorer on mainnet at [ordinals.com](https://ordinals.com), and on signet at
 [signet.ordinals.com](https://signet.ordinals.com).
 
+### Running The Explorer
+The server can be run locally with:
+
+`ord server`
+
+To specify a port add the `--http-port` flag:
+
+`ord server --http-port 8080`
+
+To test how your inscriptions will look you can run:
+
+`ord preview <FILE1> <FILE2> ...`
+
 Search
 ------
 

docs/src/guides/testing.md

@@ -0,0 +1,73 @@
+Testing
+=======
+
+Ord can be tested using the following flags to specify the test network. For more
+information on running Bitcoin Core for testing, see [Bitcoin's developer documentation](https://developer.bitcoin.org/examples/testing.html).
+
+Most `ord` commands in [inscriptions](inscriptions.md) and [explorer](explorer.md)
+can be run with the following network flags:
+
+| Network | Flag |
+|---------|------|
+| Testnet | `--testnet` or `-t` |
+| Signet  | `--signet` or `-s` |
+| Regtest | `--regtest` or `-r` |
+
+Regtest doesn't require downloading the blockchain or indexing ord.
+
+Example
+-------
+
+Run bitcoind in regtest with:
+```
+bitcoind -regtest -txindex
+```
+Create a wallet in regtest with:
+```
+ord -r wallet create
+```
+Get a regtest receive address with:
+```
+ord -r wallet receive
+```
+Mine 101 blocks (to unlock the coinbase) with:
+```
+bitcoin-cli generatetoaddress 101 <receive address>
+```
+Inscribe in regtest with:
+```
+ord -r wallet inscribe --fee-rate 1 <file>
+```
+Mine the inscription with:
+```
+bitcoin-cli generatetoaddress 1 <receive address>
+```
+View the inscription in the regtest explorer:
+```
+ord -r server
+```
+
+Testing Recursion
+-----------------
+
+When testing out [recursion](../inscriptions/recursion.md), inscribe the
+dependencies first (example with [p5.js](https://p5js.org):
+```
+ord -r wallet inscribe --fee-rate 1 p5.js
+```
+This should return a `inscription_id` which you can then reference in your
+recursive inscription.
+
+ATTENTION: These ids will be different when inscribing on
+mainnet or signet, so be sure to change those in your recursive inscription for
+each chain.
+
+Then you can inscribe your recursive inscription with:
+```
+ord -r wallet inscribe --fee-rate 1 recursive-inscription.html
+```
+Finally you will have to mine some blocks and start the server:
+```
+bitcoin-cli generatetoaddress 6 <receive address>
+ord -r server
+```

docs/src/inscriptions.md

@@ -69,40 +69,59 @@ Content
 The data model of inscriptions is that of a HTTP response, allowing inscription
 content to be served by a web server and viewed in a web browser.
 
-Sandboxing
-----------
+Fields
+------
 
-HTML and SVG inscriptions are sandboxed in order to prevent references to
-off-chain content, thus keeping inscriptions immutable and self-contained.
+Inscriptions may include fields before an optional body. Each field consists of
+two data pushes, a tag and a value.
 
-This is accomplished by loading HTML and SVG inscriptions inside `iframes` with
-the `sandbox` attribute, as well as serving inscription content with
-`Content-Security-Policy` headers.
+Currently, the only defined field is `content-type`, with a tag of `1`, whose
+value is the MIME type of the body.
+
+The beginning of the body and end of fields is indicated with an empty data
+push.
+
+Unrecognized tags are interpreted differently depending on whether they are
+even or odd, following the "it's okay to be odd" rule used by the Lightning
+Network.
 
-Recursion
----------
+Even tags are used for fields which may affect creation, initial assignment, or
+transfer of an inscription. Thus, inscriptions with unrecognized even fields
+must be displayed as "unbound", that is, without a location.
 
-An important exception to sandboxing is recursion: access to `ord`'s `/content`
-endpoint is permitted, allowing inscriptions to access the content of other
-inscriptions by requesting `/content/<INSCRIPTION_ID>`.
+Odd tags are used for fields which do not affect creation, initial assignment,
+or transfer, such as additional metadata, and thus are safe to ignore.
 
-This has a number of interesting use-cases:
+Inscription IDs
+---------------
 
-- Remixing the content of existing inscriptions.
+The inscriptions are contained within the inputs of a reveal transaction. In
+order to uniquely identify them they are assigned an ID of the form:
 
-- Publishing snippets of code, images, audio, or stylesheets as shared public
-  resources.
+`521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0`
 
-- Generative art collections where an algorithm is inscribed as JavaScript,
-  and instantiated from multiple inscriptions with unique seeds.
+The part in front of the `i` is the transaction ID (`txid`) of the reveal
+transaction. The number after the `i` defines the index (starting at 0) of new inscriptions
+being inscribed in the reveal transaction.
 
-- Generative profile picture collections where accessories and attributes are
-  inscribed as individual images, or in a shared texture atlas, and then
-  combined, collage-style, in unique combinations in multiple inscriptions.
+Inscriptions can either be located in different inputs, within the same input or
+a combination of both. In any case the ordering is clear, since a parser would
+go through the inputs consecutively and look for all inscription `envelopes`.
 
-A couple other endpoints that inscriptions may access are the following:
+| Input | Inscription Count | Indices    |
+|:-----:|:-----------------:|:----------:|
+| 0     | 2                 | i0, i1     |
+| 1     | 1                 | i2         |
+| 2     | 3                 | i3, i4, i5 |
+| 3     | 0                 |            |
+| 4     | 1                 | i6         |
 
-- `/blockheight`: latest block height.
-- `/blockhash`: latest block hash.
-- `/blockhash/<HEIGHT>`: block hash at given block height.
-- `/blocktime`: UNIX time stamp of latest block.
+Sandboxing
+----------
+
+HTML and SVG inscriptions are sandboxed in order to prevent references to
+off-chain content, thus keeping inscriptions immutable and self-contained.
+
+This is accomplished by loading HTML and SVG inscriptions inside `iframes` with
+the `sandbox` attribute, as well as serving inscription content with
+`Content-Security-Policy` headers.

docs/src/inscriptions/recursion.md

@@ -0,0 +1,27 @@
+Recursion
+=========
+
+An important exception to [sandboxing](../inscriptions.md#sandboxing) is recursion: access to `ord`'s `/content`
+endpoint is permitted, allowing inscriptions to access the content of other
+inscriptions by requesting `/content/<INSCRIPTION_ID>`.
+
+This has a number of interesting use-cases:
+
+- Remixing the content of existing inscriptions.
+
+- Publishing snippets of code, images, audio, or stylesheets as shared public
+  resources.
+
+- Generative art collections where an algorithm is inscribed as JavaScript,
+  and instantiated from multiple inscriptions with unique seeds.
+
+- Generative profile picture collections where accessories and attributes are
+  inscribed as individual images, or in a shared texture atlas, and then
+  combined, collage-style, in unique combinations in multiple inscriptions.
+
+A few other endpoints that inscriptions may access are the following:
+
+- `/blockheight`: latest block height.
+- `/blockhash`: latest block hash.
+- `/blockhash/<HEIGHT>`: block hash at given block height.
+- `/blocktime`: UNIX time stamp of latest block.

docs/src/introduction.md

@@ -38,6 +38,8 @@ Links
 - [GitHub](https://github.com/ordinals/ord/)
 - [BIP](https://github.com/ordinals/ord/blob/master/bip.mediawiki)
 - [Discord](https://discord.gg/ordinals)
+- [Open Ordinals Institute Website](https://ordinals.org/)
+- [Open Ordinals Institute X](https://x.com/ordinalsorg)
 - [Mainnet Block Explorer](https://ordinals.com)
 - [Signet Block Explorer](https://signet.ordinals.com)
 

src/arguments.rs

@@ -10,7 +10,7 @@ pub(crate) struct Arguments {
 }
 
 impl Arguments {
-  pub(crate) fn run(self) -> Result {
+  pub(crate) fn run(self) -> SubcommandResult {
     self.subcommand.run(self.options)
   }
 }