casey
commented
11 months ago I think the ship has kind of sailed on this one. There is definitely the potential for instability, but it only exists within a single transaction, i.e., you would have to create a transaction which hit an edge case for one inscription, but not the others, and only inscription IDs within that one transaction would change. We could introduce a new inscription ID, and I actually thought about using the offset of the envelope within the tapscript, however having a second type of inscription ID would be very confusing, and getting people to migrate would be hard.
The changes in 7e6eb73b5212f3b6647785cba7bc001b4ed7c604 (PR #2145) create the potential for instability of inscription Ids.
Specifically, prior to this commit all values were i0 due to it being 'txid.into()' (where the conversion populated a 0 automatically if not provided). The change makes it the index within the parsed envelopes. This would be fine, except that it relies on the envelopes that are parsed being stable between versions (and more importantly between services). While this is the ideal, it recreates the instability that led to the confusion about inscription numbers.
We can keep this id for backwards compatibility (as it is reliable if we assume that all envelopes are parsed equally by two parties and no one has triggered any of the very specific edgecases), but we should further define an id that uses only on-chain data that doesn't require indexing anything other than the specific envelope that an id references.
While we should explore other options, my kneejerk reaction would be defining identifiers such that they point to the transaction (using txid like we already do) and then further define the location of the envelope within the transaction. This could be done using (vIn, offsetWithinTapscript) or offsetWithinRawTransaction.
The gut reaction of most developers will be to assume this doesn't matter as the ids are stable for any given version, but the purpose of a stable identifier goes beyond individual versions and MUST be stable between versions to be useful (or when we share and use them we would also need to include which version they correspond with).