Stable Rune IDs for Etching pre-signed

[JeremyRubin]

The 0:0 RuneID feature allows a premine in an etch to allocate to its outputs.

However, suppose we wanted to etch and premine into a smart contract, e.g., a channel.

We can send the initial runes to the output we want, but subsequently the only way to allocate runes that have just been etched is via the pointer, which only allows sending all the runes to a particular output, and can't handle multiple runes.

RuneIDs are 12 bytes long, or 96 bits. That is quite large, but is not collision proof, so it can't trivially be a hash.

What could be done, without breaking compatibility, is either:

• to make 0:1 (which cause a cenotaph) to be the first input's historically first etched rune. When a new etching occurs, it would be 0:2, up to 2**32
• to make 0:1 (which cause a cenotaph) to be the first input's most recent etched rune. When a new etching occurs, it resets the most recent

This would enable a wide class of presigned contracts that can deal with etchings. It'd be nice to have a way to deal with something other than the first-input recursion rule, to allow for contracts with multiple etched runes. However, generally, this would enable a wide variety of functionality.

[raphjaph]

Do you have a specific context in mind for this? Brollups?

[JeremyRubin]

i was looking into how runes could be etched into CTV addresses and distributed e.g. over time.

Otherwise, you need to premine, wait for confirmation, and then trustedly send the premine to a CTV tree created once you know ID.

[raphjaph]

Let's revisit this when CTV activates. I'll keep it open