-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Store inscriptions in taproot signature annex #2405
Comments
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. |
Interesting if rough maths of block space usage compression gains at constant inscription demand. |
@ariard Yeah, it would be a huge win. I'm thinking about creating a few patches and bundling them up in a branch:
|
Okay understanding the chain-space usage saving comes from eliminating the two-phase commit/reveal procedure.
By the way, while reading https://docs.ordinals.com/inscriptions.html (which I understood is best inscription spec available instead to look more in 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 |
I think I have a branch open to do this, but we haven't gotten around to actually doing it #1403. |
@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:
The text was updated successfully, but these errors were encountered: