Store inscriptions in taproot signature annex

[casey]

@joostjager noticed that we could store inscriptions in the taproot signature annex, instead of in the tapscript. This would be great, since it would allow us to avoid needing two transactions to inscribe, and would allow us to use a simpler encoding independent of bitcoin script.

Before doing this, we should wait for some carve-out for unstructured annex data. One such proposal makes annexes starting with a zero byte unstructured[0]. If we don't wait for this, and a future soft fork gives the annex consensus meaning, we'll probably have to change the format of annex inscriptions.

If we do this, we should come up with an alternative encoding for inscriptions, since using the script-based encoding in the annex doesn't make much sense.

[0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021756.html

Related issues:

• https://github.com/bitcoin/bips/pull/1381
• https://github.com/bitcoin/bitcoin/pull/27926

[Psifour]

I can confirm that the isStandard rule is the only reason our (Luxor's) inscription tooling on the backend uses multiple transactions still. Would love to reduce that and also remove the need for tooling as honestly an annex inscription become simple enough that I would trust the browser with constructing them.

Would 100% 'concept ack' that proposal.

[ariard]

This would be great, since it would allow us to avoid needing two transactions to inscribe,

Interesting if rough maths of block space usage compression gains at constant inscription demand. This might be one of the lowest hanging technical fruit to slow down on-chain fees growth, and make everyone happy. If no consensus on the policy change deployment, easy to do standalone patch and let the market speaks.

[casey]

@ariard Yeah, it would be a huge win. I'm thinking about creating a few patches and bundling them up in a branch:

• Relax the 400kvb size limit for transactions as long as they have all segwit inputs. The quadratic hashing attack isn't an issue if no non-segwit inputs are spent, and this would allow users to create large inscriptions without having to submit transactions directly to miners.
• Relax the 80 byte OP_RETURN limit, to provide an alternative to storing data in bare multisig outputs, which is easily the most harmful way to store data.
• Relax the signature annex size limit for annexes which start with a zero byte, so inscriptions can be made in a single transaction.

[ariard]

Okay understanding the chain-space usage saving comes from eliminating the two-phase commit/reveal procedure.

• Relax the 400kvb size limit (MAX_STANDARD_TX_WEIGHT): conflict of use-case incentives with lightning pinning issues (i.e more surface to abuse rule 3 / rule 5) ; if default or viable tx-relay paths needs opt-in mechanism a la bip125 to segregate traffic
• Relax the 80 byte OP_RETURN limit (MAX_OP_RETURN_RELAY): needs to relax max 1 op_return (in IsStandardTx()) if not loss of space / fee efficiency as no batching ; note op_return outputs are pruned out of the UTXO set for any future lightweight inscription verification relying on assumeutxo
• Relax the signature annex size limit: rebased the annex patchset on core and incomplete toy implem here: https://github.com/ariard/bitcoin/commit/6ebaa0ab2332b68fa26fce61d205d31f142d2da0

By the way, while reading https://docs.ordinals.com/inscriptions.html (which I understood is best inscription spec available instead to look more in ord inner guts), I wonder if the default “hello world” example isn’t inefficient and OP_1 / OP_0 can be used to save few bytes (if stack binary is what is canonical for inscriptions apps not script ops).

By the way number 2, given the UTXO growth consumption surge arising from ordinals traffic over the past months (which is a real fucking issue), I wonder if ordinals format shouldn’t start to have some “utxo priority” marker. That way they could be cached in “spend likeliness” tiers by utreexo archive nodes. Still scaling inscriptions "on-chain" and maintaining some equilibrium for full-node operators.

edited - on max_standard_tx_weight both rule 3 / rule 5 can be abused for pinnings

[casey]

By the way, while reading https://docs.ordinals.com/inscriptions.html (which I understood is best inscription spec available instead to look more in ord inner guts), I wonder if the default “hello world” example isn’t inefficient and OP_1 / OP_0 can be used to save few bytes (if stack binary is what is canonical for inscriptions apps not script ops).

I think I have a branch open to do this, but we haven't gotten around to actually doing it #1403.