Another Approach to Provenance

[dannydeezy]

I'm new to provenance and i'm here to fix it.

Just kidding, but there's an interesting proposal for provenance, though I think it has a challenge around mint volume

I proposed something with nostr, but introducing nostr is overkill and not necessary, so let's ignore nostr for now.

Here's a potential approach that is very similar to the original proposal #783 with prime ordinals, but does not require the collection ordinal to be included on every mint transaction:

A collection is initiated as an inscription of a json blob like this:

{
  "name": "Astral Babes",
   "max_supply": 10000,
   "nostr": "npub1234...", // optional
}

The ordinal on which this inscription is made is now the Ordinal of the collection, as in #783
The difference from #783 is that this Ordinal will not be included on item-mint transactions, but instead all collection provenance info will be inscribed directly onto this ordinal

So the next step is to commit to some items. So the owner should make another inscription on the Collection Ordinal, with something like this:

{
  "items": [{
      "ordinal": 2099994106992659,
      "data_hash": "abc123456...", // optional
  }, {
      "ordinal": 1099994106992659,
      "data_hash": "def123456...", // optional
  }, {
    ...etc
   }]
}

This message (let's call it a "commitment inscription") means that the first item will be inscribed onto ordinal 2099994106992659 and the second item will be inscribed onto ordinal 1099994106992659.... etc. The data_hash is an optional field committing to the hash of the item contents.
This allows the collection owner to pre-allocate enough utxos in their wallet to eliminate mempool chain issues. The entire 10,000 item collection could presumably be minted in a single block.

The above commitment inscription must be mined before any of its mentioned items are minted.
The commitment inscriptions can be broken up as desired if the minting of the collection is in a phased approach.
Commitment inscriptions are respected until the max_supply is reached.
So the owner could commit to 100 items, then mint 100, then commit to 50 more, then mint 50 more, etc, until they reach max_supply

Thoughts on this? @casey

[dannydeezy]

oh i guess this would require multiple inscriptions on the same sat to be possible, which appears to be in consideration

[dannydeezy]

Another possibility that I'm thinking of, for a supply of 10,000 items:

First, the collection creator creates 10,000 outputs each of small amount like 1000 sats
The collection creator should use bitcoin-cli lockunspent and lock all these utxos to ensure they are not spent in normal ord wallet operations.

Then they create an inscription of a file that has a list of the first satpoint on each of those output, like this:

txid1:vout1:0
txid2:vout2:0
txid3:vout3:0
... etc

This inscription has some id, call it inscription_id_of_satpoints_list

Then they publish an inscription for the collection like this:

{
   "name": "Astral Babes",
   "items": <inscription_id_of_satpoints_list>,
   "max_supply": 10000, // optional
   "nostr": "npub1234...", // optional
}

This way they are committing to say, "there are 10,000 items in this collection, and each will be inscribed on one of the ordinals in that list"

Then one by one during minting the collection, a utxo from the list can be unlocked and its ordinalscan be inscribed with an item, and people can know that it is as valid item in the collection.

Note: if the creator wants to commit to item data hashes upfront as well, their initial inscription file can look like this:

txid1:vout1:0,datahash-1
txid2:vout2:0,datahash-2
txid3:vout3:0,datahash-3
... etc