Scalable Generative Inscriptions on BTC

[huuep]

Background: Generative Inscriptions can be scalable on Bitcoin

Collections vs individual Ordinals

Currently, the Ordinals protocol only supports one single collection that includes every single Ordinal ever inscribed. There isn't a native concept of a collection of Ordinals that are a subset of all the Ordinals yet. Creating a Collection Ordinal will greatly improve scalability of Ordinals on Bitcoin, especially for generative collections. For folks familiar with Ethereum, the Collection Ordinal is like an ERC-721 contract for NFTs (I'll use the term NFT interchangeably) on Bitcoin.

Generative NFTs

Generative NFTs can create a rich set of NFTs at very small data sizes. These type of NFTs can be great for scalability of NFTs on Bitcoin. For example, OnChainMonkey launched 10k images with Ordinals using less than 20,000 bytes, so it cost only 2 bytes/image. This was done with a single Ordinal which I referred to as the Collection Ordinal above.

https://ordinals.com/inscription/fb162a46943e5d7d31d72ee2c8c850e66c1ca5d0d453068aa63883528285ed21i0

There are so many amazing generative artists who can create amazing work and very efficiently inscribe them on Bitcoin.

The next step of distributing (or airdropping) the work can be super efficient too. Let's say an artist creates a 1,000 piece generative art collection in a single (Collection) Ordinal. The next step is to distribute it to 1,000 bitcoin addreses. These can be done as a one-time operation to sequentially distribute the 1,000 child Ordinals to the new addresses. No addition image or art data is needed for the 1,000 child Ordinals, thus saving tons of storage space.

The order of the child ordinals determines their tokenID. The code for the generative art in the Collection Ordinal should respond to tokenID. For example, Ordinal 20219 has a tokenID field that can be used as follows to find the data/art for a given tokenID/child.

https://ordinals.com/content/fb162a46943e5d7d31d72ee2c8c850e66c1ca5d0d453068aa63883528285ed21i0?tokenID=3

This way, we have distributed a 1,000 generative NFT collection for a very small amount of cost. The bitcoin network would not even notice it. Many generative artists can distribute their work this way.

Proposed system to support generative NFT collections with ordinals:

Up to this point, ordinals have been inscribed individually. While this is a great step forward for Bitcoin and NFTs, it's somewhat inefficient when inscribing collections of one thousand or more Ordinals. To remedy this problem we suggest utilizing a hierarchical (two level) system of a parent (collection) ordinal and one or more child ordinals. To add clarity to the discussion we will refer to the pre-existing ordinal NFT system Individual Ordinals. The new system is called OrdinalCollection.

OrdinalCollection V1: Hierarchical Collection Individual Ordinals that share rendering code.

A parent ordinal is an ordinal made under the pre-existing scheme with text/html MIME type and embedded Javascript code. This javascript code looks at the query string parameters in the URL and renders different imagery (or SVG, or text) accordingly as part of the HTML page. An example parameter name is tokenID which could be a number between 1 and 10000 allowing for many different variations to be rendered based on the number using generative art implemented in Javascript.

A child ordinal represents a pointer to a parent ordinal along with a specific set of query parameters that drive the rendering. A typical query parameter included in a child ordinal could be tokenID. A child ordinal has text/uri-list MIME type and contains exactly one URL of the form:

https://ordinals.com/content/fb162a46943e5d7d31d72ee2c8c850e66c1ca5d0d453068aa63883528285ed21i0?tokenID=3

This URI refers to a parent ordinal to perform rendering using JS code shared among all child ordinals thus saving significant space and cost on the blockchain. The example above provides the tokenID parameter with value 3 to retrieve the generative art.

Security feature

Require child ordinal inscribers to be equal to the inscriber of the parent ordinal at the time of inscribing. Require parent ordinals to never be transferred (a transfer of the parent would make all future inscriptions invalid, thus locking the max supply). This allows for a secure permissioned system such that only the original author of a parent ordinal can inscribe children using it.

Strengths

Shares generative art rendering code across many children for significant storage savings. Fits into the pre-existing ord wallet framework without modification to the wallet code and only minor modification to the blockchain explorer to support rendering. Enables code sharing in the way most familiar to web developers using JS and query parameters.

Weaknesses

Still requires the overhead of one individual ordinal per child ordinal. For a 10000 size collection these costs may be substantial. No way to express a maximum collection size.

OrdinalCollection V2: Block Allocated Hierarchical Collection Ordinals

To improve the efficiency of inscribing large collections we may devise an ordinal block allocation system. This can be done in the context of the child ordinals by using more than one entry in the text/uri-list array. These represent a block of sats instead of a single sat as the Individual Ordinal scheme allows.

The first entry in the URI list can be the same as in the V1 case with the restriction that the URI must match the regular expression

=[0-9]+$

In other words, the URI must end with an = followed by an ASCII decimal number. This restriction allows for the possibility to increment the final query parameter sequentially.

The second entry in the URI list can be the maximum size of the collection. A typical value would be 10000.

The third and successive entries in the list can be taproot bitcoin addresses to whom the corresponding NFT is airdropped.

Consistency constraints

All child ordinals of a given parent ordinal must have the same maximum size value as the first child ordinal for the same parent ordinal. Any child ordinals whose maximum size value differs will be ignored and considered invalid.
Each starting URI must end with the number which is next in sequence contiguously. In other words, if the first child ordinal looks like:

https://ordinals.com/content/fb162a46943e5d7d31d72ee2c8c850e66c1ca5d0d453068aa63883528285ed21i0?tokenID=1
10000
bc1ql84f2292nvjzfq9r46lw2vxpcu8xdmdy7tec5a
bc1qc5vqa5mmyw5a3acanjqv44uh97nzx2lnkq7f2n
bc1q0ut7zke9ahdvrpqe8vhfh07gcazmcdk7k3dep4

Then the next child ordinal must begin with the two lines
https://ordinals.com/content/fb162a46943e5d7d31d72ee2c8c850e66c1ca5d0d453068aa63883528285ed21i0?tokenID=4
10000

All child ordinals must not list more addresses than implied by the collection size parameter that is specified in the first child ordinal and all successive airdrops. If more addresses are listed, then the child ordinal is invalid and ignored.

Strengths

Allows for inscribing a block of child ordinals and airdropping them for less cost than doing them individually. One transaction can create multiple child ordinals.

OrdinalCollection V3: Efficient Block Allocated Hierarchical Collection Ordinals

In the OrdinalCollection V2 protocol, we described a way to allocate satoshis sequentially in blocks using child ordinals with a given parent ordinal and starting offset and maximum collection size. We listed each receiver address in the text/uri-list list after the first two lines for clarity. In order to ensure the proper owners own each individual satoshi, it is necessary to also generate UTXO output transactions of value 1 satoshi in order. These UTXO output transactions will appear in the same order as the receiver addresses in the text/uri-list.

Therefore, we can drastically improve the efficiency of the V2 protocol by eliminating the addresses listed in the text/uri-list for children ordinals. We can keep the first two lines as before, but there is never any need to use a third line in children ordinals. Instead we can have the understanding that any 1 satoshi valued UTXO output in the transaction creates a child NFT and is considered to have received the corresponding sequential NFT from the parent ordinal generative collection.

References:

https://github.com/casey/ord/issues/1082 (Recursion)
https://github.com/casey/ord/issues/1545 (Generative Art Libraries)
https://github.com/casey/ord/issues/876 (Bundles)
https://github.com/casey/ord/issues/783 (Collections and Provenance)

[veryordinally]

Sounds like an interesting concept. Can you elaborate a bit on the specifics? How would the “child ordinals” work?

[rudi-cilibrasi]

The question about the a) DNS of ordinals.com or b) whether or not there is a live server running at ordinals.com is immaterial. Casey already has a proposal from last year ( https://github.com/casey/ord/issues/1082 ) describing a shorter syntax ( /ID/ ) that already covers this case. The longer URI or the shorter /ID/ syntax can both be understood to refer to a parent ordinal with a small amount of simple code. It's not hard to invent a restricted syntax to refer to ordinals within a prefix-free code. Whatever syntax we choose doesn't matter much as the results are all structurally equivalent and we can make trivial code modifications to fix it if any unexpected service outages pop up. My ideal goal is to work towards a standard (like ERC-721) that can support and accelerate the Ordinal ecosystem and that standard can thrive regardless of the rise or fall of individual DNS names or server entities. I think this proposal represents one candidate implementation of issue 1082.

[cc0mfer]

The question about the a) DNS of ordinals.com or b) whether or not there is a live server running at ordinals.com is immaterial. Casey already has a proposal from last year ( #1082 ) describing a shorter syntax ( /ID/ ) that already covers this case. The longer URI or the shorter /ID/ syntax can both be understood to refer to a parent ordinal with a small amount of simple code. It's not hard to invent a restricted syntax to refer to ordinals within a prefix-free code. Whatever syntax we choose doesn't matter much as the results are all structurally equivalent and we can make trivial code modifications to fix it if any unexpected service outages pop up. My ideal goal is to work towards a standard (like ERC-721) that can support and accelerate the Ordinal ecosystem and that standard can thrive regardless of the rise or fall of individual DNS names or server entities. I think this proposal represents one candidate implementation of issue 1082.

Thanks for this perspective. I was not aware of proposal ( #1082 ) - I inscribed an ordinal in the same format and added a tokenId parameter to follow suit with @huuep's approach. I don't know enough about the blockchain or how ord protocol has been implemented but I'm curious to explore how the dependencies of ordinal.com or any live server could be replaced with on-chain resources.

[swapski]

Getting insight on how to accomplish this!

I want to do this with my 999 1/1 Collection, Thank you!

[cc0mfer]

Getting insight on how to accomplish this!

I want to do this with my 999 1/1 Collection, Thank you!

you can take a peek at the template collection on my account.

[curi0n-s]

@cc0mfer I'm curious what you've come up with - but everything is private on your github account. Are you referring to some other page?

[Nutter79]

would be cool to understand the mechanics on how the child ordinal points to the specific NFT in the parent ordinal.

[huuep]

to keep things as simple and space efficient as possible, it can be done in a sequential order.

[michaelgold]

Weaknesses

Still requires the overhead of one individual ordinal per child ordinal. For a 10000 size collection these costs may be substantial. No way to express a maximum collection size

I like this.

I would add that it might make sense for:

1. The initial ordinal in a collection to contain a CollectionStart.json with some metadata such as MaxCollectionSize
2. The very last child in a collection to contain a CollectionEnd.json with the hash of its parent (and potentially some other metadata)

This way, you can have a hash list where the JPEG / SVG of each child ordinal has embedded content (ie a base64 encoded hash that refers to the ordinal hash of its parent).

This would also allow any website to traverse backwards through all ordinals in a collection-- starting with the final json file.

[curi0n-s]

I'm a bit of a newb with the mime types - could you describe in more detail the format and file extension of the child inscriptions? I.e. how do I prepare/format the child inscription file to:

1. Render content at a uri of format like this - I made a parent inscription: https://ordinals.com/content/f88d9c436c75bfd06a6e96c5daaf653ff9efc16ad086f6aac31b26f537ab7ffci0?tokenID=1

2. Distribute N sats to addresses automatically? Does this mean that per-manual-inscription, I can send multiple copies of one child to different addresses, or can I also send ID 1 to Address 1, ID 2 to address 2, etc.?

Really interesting concepts, def want to get a handle on them.

Thanks!!

[rudi-cilibrasi]

Hi curi0n-s

Thanks for the good question.

First a quick warning: I can't guarantee this will work as I haven't tested it yet because signet.ordinals.com is still down. But I can explain what I think should work and why.

To your question number 1:

First, you might want to review http://amundsen.com/hypermedia/urilist/ to learn about the very simple line-oriented format for MIME type text/uri-list

Next, I suggest preparing a V1 child ordinal. These are expensive to mass produce but still quite a bit cheaper than including all your SVG code in every ordinal. It allows code reuse in ordinals. The syntax we thought makes sense is just how you have your URI written:

https://ordinals.com/content/f88d9c436c75bfd06a6e96c5daaf653ff9efc16ad086f6aac31b26f537ab7ffci0?tokenID=1

Just put that single line of text containing just your URI in a file called child.uri

If you then mint an ordinal using the current ord wallet I believe it should "just work" because hopefully your system recognizes the .uri extension as associated with MIME type text/uri-list

Note that these URI may simplify to be something like the syntax shown in issue 1082 or something else even.

If everything goes well I think that should mint a single NFT and it follows our suggested V1 syntax. That syntax is open for discussion still here so may change depending on which syntax everybody decides is best.

I don't think the current ordinal explorer will render it properly yet but I do think it's a relatively small change in the explorer code to make it work. I expect it is likely you can at least see that the child ordinal is created with the correct MIME type and content in there but probably not in graphical form yet.

Once some V1 child ordinals are minted for practice (and hopefully we can add better rendering for V1 child ordinals in the block explorer) then I think we are in a good position to think about if we want to pursue the more advanced and scalable but more challenging V3 child ordinal that will support large collections cheaply.

To your question number 2:

No, each Ordinal as well as each Ordinal NFT should be unique. Therefore you cannot "send multiple copies of one child to different addresses." In our (evolving) terminology a child ordinal in V3 can contain one or more child NFTs each with different tokenID. It should be possible to send different sats representing each different tokenID to the same or different taproot addresses using normal UTXO output addresses with value 1 all in one transaction. The problem is that V3 child ordinals are not currently supported by the ord wallet. We will need to get Casey's opinion about the scheme and perhaps make some adjustments before we can start to mint those highly efficient V3 child ordinals with an enhanced ord wallet.

Hope this helps!

😀

[curi0n-s]

Thank you much for that detailed response! That helps me understand quite a lot.

I tried to go forward with a V1 child with "child.uri" but get an error from ord-wallet (v0.4.2) reading:

error: unsupported file extension .uri, supported extensions: apng flac gif html jpg mp3 pdf png svg txt wav webm webp

ordinalsbot.com also does not accept this file extension.

I did add it as a mime type in my system just to do something, but no luck. How would you get around this / add a supported extension / have a .txt be read as text/uri-list?

I tried http/https, and confirmed the EOL char is CRLF.

[rudi-cilibrasi]

Somebody needs to make a 1-line PR to add it to this list https://github.com/casey/ord/blob/c9619fb7eabcf7e11acae30a8d5493e5d7ae384c/src/media.rs
In theory you could do that in your own fork and build the ord wallet yourself without @casey approval but I would personally want to hear his opinion before putting something like that on the blockchain even though i'm sure we could do it

[rudi-cilibrasi]

You're correct we could use .txt without a PR modification but I am thinking the text/uri-list is cleaner. we need a bit more consensus I suppose if we can generate it in order to make the right design choice here.

[curi0n-s]

agreed - and yeah ordinals.com could always just render any plaintext that only contains the above v1 format as a uri at least. As of now, would this be the case or would site modifications be necessary too?

[veryordinally]

Should consider #783 and #876

[huuep]

Definitely, we're thinking along the same lines!

[huuep]

For the Ordinals Protocol to be better adopted, we need to agree on some standards for a Collection. We talk about some of it in this Discussion, and also in #783.

Currently there are three types of collections being created on Ordinals:

1. Entire Collection inscribed together (as Discussed here)
2. Collection inscribed by individual Ordinals by a singler wallet (Taproot Wizards)
3. Collection inscribed by individual Ordinals by multiple different wallets (Astral Babes)

An agreed upon Standard that supports these Collections will help creators and collectors.

[michaelgold]

Here is an example of a provenance.json file that includes front matter metadata for a collection:
https://gist.github.com/michaelgold/7941ecc467fd7df4b1f509c17b69675f

This file is 172Kb and includes all the data necessary to generate a collection.

1. Collection information
2. Artist information
3. Collection thumbnail (base64 encoded jpeg file)
4. Collection generator (lzma compressed, base64 encoded Blender)

With this front matter inscribed before distribution, each inscription in the collection can be extremely small. They can include as little data as:

1. A unique seed necessary to generate the art
2. A reference to the on-chain hash of the provenance.json file
3. Potentially a thumbnail. (items 1 and 2 can even be embedded/hidden in a thumbnail as binary data)

Finally, after all items in the collection are inscribed, a manifest.json file can be inscribed with:

1. The hash of the provenance.json file for the collection
2. An array of key/value pairs for each seed in the collection and its corresponding inscription hash

[BennyTheDev]

Nice but you need to convince the Ord team to include this and notify all current projects working on Ordinals Wallets to support this.
And in the end you need to convince all the BTC maxis that "child" ("sub" probably a better term) inscriptions are not of lesser value than parent-only inscriptions.

[huuep]

An inscription is data on chain, like any other. Those are equivalent. The other part of an Ordinal is the inscription number. Those only matter for special cases, such as low inscription number. For the majority of ordinals, the value is in the data inscribed, not in the inscription number. Child ordinals are part of Casey's plan in #1082.

[ronval]

Hey guys great discussion that is going on here. I was playing around with the idea of creating what are essentially sprite sheets for jpeg related collections.

Right now the conversation here seems to only really cover generative art that essentially gets made each time the page loads. This doesn't really cover art that has already been made into a jpeg or png file for example.
I have been playing around with the idea of using what are essentially sprite sheets and the child holds the coordinates to your Ordinal image on the sprite sheet.

But this only really works for small collections not really for 10k collections.

I have already made the art for a 10k collection and used an image processor to make the parent sprite sheet image. Even when reducing the size of each image to 100x100 you are still left with a relatively large image. For example the parent image created ended up being 210mb. This would obviously not fit in 1 block and would also cost over $200k to inscribe.

Im not sure what the solution here is for large 10k collections except to mint each one separately and then have one last json file that has all the inscription numbers address in the collection.

Would like to hear peoples thought on this.

If anyone is interest in our project you can take a look here

https://www.sweetsnackclub.com

https://discord.gg/HYYhxjWk6r

Cheers :)

[diegomey]

Great conversation here! I do like both perspectives shared, first Ordinals as a pure canvas, and the second, ERC like features that have a potential to unlock even more value to Ordinals and sequentially BTC.

I'm happy there's a lot of big brains already working on these possibilities and do agree that adopting a standard may be a solution for easy frontend apps and adoption.

I love the dynamics that new collections maybe be created based on these attribute. Exciting!

[Luix87]

Is there any chance that you can inscribe every child like the example of the Inscription 20219??? It could be great to create a collection putting the like a generative Ordapp, inscribing every child individually as a part of one big collection