📅 Original date posted:2023-06-10
🗒️ Summary of this message: The proposed annex design for unstructured data storage on the blockchain can benefit existing data storage uses and improve space efficiency, particularly for time-locked vaults. The annex's data is not included in the calculation of the txid, making it a powerful tool for applications that would ideally use covenants. However, there are trade-offs associated with various encodings, and smaller bits of unstructured data may not afford the overhead.
📝 Original message:
Hi Antoine,
On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard <antoine.riard at gmail.com>
wrote:
> From a taproot annex design perspective, I think this could be very
> valuable if you have a list of unstructured data use-cases you're thinking
> about ?
>
The annex's list of unstructured data use-cases includes existing data
storage uses that utilize OP_RETURN or inscriptions. Consider ordinals,
timestamps, and any other data already stored on the chain. These
applications would immediately benefit from the annex's improved space
efficiency.
However, the primary advantage I see in the annex is that its data isn't
included in the calculation of the txid or a potential parent commit
transaction's txid (for inscriptions). I've explained this at [1]. This
feature makes the annex a powerful tool for applications that would ideally
use covenants.
The most critical application in this category, for me, involves
time-locked vaults. Given the positive reception to proposals such as
OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably
a bit further out, but pre-signed transactions signed using an ephemeral
key can fill the gap and improve the safeguarding of Bitcoin in the short
term.
Backing up the ephemeral signatures of the pre-signed transactions on the
blockchain itself is an excellent way to ensure that the vault can always
be 'opened'. However, without the annex, this is not as safe as it could
be. Due to the described circular reference problem, the vault creation and
signature backup can't be executed in one atomic operation. For example,
you can store the backup in a child commit/reveal transaction set, but the
vault itself can be confirmed independently and the backup may never
confirm. If you create a vault and lose the ephemeral signatures, the funds
will be lost.
This use case for the annex has been labeled 'speculative' elsewhere. To
me, every use case appears speculative at this point because the annex
isn't available. However, if you believe that time-locked vaults are
important for Bitcoin and also acknowledge that soft forks, such as the one
required for OP_VAULT, aren't easy to implement, I'd argue that the
intermediate solution described above is very relevant.
> As raised on the BIP proposal, those unstructured data use-cases could use
> annex tags with the benefit to combine multiple "types" of unstructured
> data in a single annex payload. As you're raising smaller bits of
> unstructured data might not afford the overhead though my answer with this
> observation would be to move this traffic towards some L2 systems ? In my
> mind, the default of adding a version byte for the usage of unstructured
> data comes with the downside of having future consensus enabled use-cases
> encumbering by the extended witness economic cost.
>
When it comes to the trade-offs associated with various encodings, I fully
acknowledge their existence. The primary motivation behind my proposal to
adopt a simple approach to the Taproot annex is to avoid a potentially long
standardization process. While I am not entirely familiar with the
decision-making process of Bitcoin Core, my experience with other projects
suggests that simpler changes often encounter less resistance and can be
implemented more swiftly. Perhaps I am being overly cautious here, though.
> About the annex payload extension attack described by Greg. If my
> understanding of this transaction-relay jamming griefing issue is correct,
> we can have an annex tag in the future where the signer is committing to
> the total weight of the transaction, or even the max per-input annex size ?
> This should prevent a coinjoin or aggregated commitment transaction
> counterparty to inflate its annex space to downgrade the overall
> transaction feerate, I guess. And I think this could benefit unstructured
> data use-cases too.
>
Regarding the potential payload extension attack, I believe that the
changes proposed in the [3] to allow tx replacement by smaller witness
would provide a viable solution?
Joost
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html
[2] https://github.com/bitcoin/bips/pull/1421
[3] https://github.com/bitcoin/bitcoin/pull/24007
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230610/4a037e1d/attachment.html>;
Joost Jager [ARCHIVE] /
npub1as…wfqmx
2023-06-19 20:19:54
in reply to nevent1q…ps0z
Author Public Key
npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxPublished at
2023-06-19 20:19:54Event JSON
{
"id": "0e357af5079abcfbb18dfb7df8c6b540bc30c298a20ad92bec3a2ef4f211b182",
"pubkey": "ec3fb08b335b94aace30d13181f2ad0280df9bc34f1a99832c4e2da8fb125eb3",
"created_at": 1687198794,
"kind": 1,
"tags": [
[
"e",
"68ea5a0105a7a492dce97362b0bd66bf00dac11bf2874dff55cd731b6f35e825",
"",
"root"
],
[
"e",
"e6362b4065e638c33ccd5bf7a77f9477ed445a90274ce2a87dc908a0e3dc6157",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-06-10\n🗒️ Summary of this message: The proposed annex design for unstructured data storage on the blockchain can benefit existing data storage uses and improve space efficiency, particularly for time-locked vaults. The annex's data is not included in the calculation of the txid, making it a powerful tool for applications that would ideally use covenants. However, there are trade-offs associated with various encodings, and smaller bits of unstructured data may not afford the overhead.\n📝 Original message:\nHi Antoine,\n\nOn Sat, Jun 10, 2023 at 2:23 AM Antoine Riard \u003cantoine.riard at gmail.com\u003e\nwrote:\n\n\u003e From a taproot annex design perspective, I think this could be very\n\u003e valuable if you have a list of unstructured data use-cases you're thinking\n\u003e about ?\n\u003e\n\nThe annex's list of unstructured data use-cases includes existing data\nstorage uses that utilize OP_RETURN or inscriptions. Consider ordinals,\ntimestamps, and any other data already stored on the chain. These\napplications would immediately benefit from the annex's improved space\nefficiency.\n\nHowever, the primary advantage I see in the annex is that its data isn't\nincluded in the calculation of the txid or a potential parent commit\ntransaction's txid (for inscriptions). I've explained this at [1]. This\nfeature makes the annex a powerful tool for applications that would ideally\nuse covenants.\n\nThe most critical application in this category, for me, involves\ntime-locked vaults. Given the positive reception to proposals such as\nOP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably\na bit further out, but pre-signed transactions signed using an ephemeral\nkey can fill the gap and improve the safeguarding of Bitcoin in the short\nterm.\n\nBacking up the ephemeral signatures of the pre-signed transactions on the\nblockchain itself is an excellent way to ensure that the vault can always\nbe 'opened'. However, without the annex, this is not as safe as it could\nbe. Due to the described circular reference problem, the vault creation and\nsignature backup can't be executed in one atomic operation. For example,\nyou can store the backup in a child commit/reveal transaction set, but the\nvault itself can be confirmed independently and the backup may never\nconfirm. If you create a vault and lose the ephemeral signatures, the funds\nwill be lost.\n\nThis use case for the annex has been labeled 'speculative' elsewhere. To\nme, every use case appears speculative at this point because the annex\nisn't available. However, if you believe that time-locked vaults are\nimportant for Bitcoin and also acknowledge that soft forks, such as the one\nrequired for OP_VAULT, aren't easy to implement, I'd argue that the\nintermediate solution described above is very relevant.\n\n\n\u003e As raised on the BIP proposal, those unstructured data use-cases could use\n\u003e annex tags with the benefit to combine multiple \"types\" of unstructured\n\u003e data in a single annex payload. As you're raising smaller bits of\n\u003e unstructured data might not afford the overhead though my answer with this\n\u003e observation would be to move this traffic towards some L2 systems ? In my\n\u003e mind, the default of adding a version byte for the usage of unstructured\n\u003e data comes with the downside of having future consensus enabled use-cases\n\u003e encumbering by the extended witness economic cost.\n\u003e\n\nWhen it comes to the trade-offs associated with various encodings, I fully\nacknowledge their existence. The primary motivation behind my proposal to\nadopt a simple approach to the Taproot annex is to avoid a potentially long\nstandardization process. While I am not entirely familiar with the\ndecision-making process of Bitcoin Core, my experience with other projects\nsuggests that simpler changes often encounter less resistance and can be\nimplemented more swiftly. Perhaps I am being overly cautious here, though.\n\n\n\u003e About the annex payload extension attack described by Greg. If my\n\u003e understanding of this transaction-relay jamming griefing issue is correct,\n\u003e we can have an annex tag in the future where the signer is committing to\n\u003e the total weight of the transaction, or even the max per-input annex size ?\n\u003e This should prevent a coinjoin or aggregated commitment transaction\n\u003e counterparty to inflate its annex space to downgrade the overall\n\u003e transaction feerate, I guess. And I think this could benefit unstructured\n\u003e data use-cases too.\n\u003e\n\nRegarding the potential payload extension attack, I believe that the\nchanges proposed in the [3] to allow tx replacement by smaller witness\nwould provide a viable solution?\n\nJoost\n\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021737.html\n[2] https://github.com/bitcoin/bips/pull/1421\n[3] https://github.com/bitcoin/bitcoin/pull/24007\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230610/4a037e1d/attachment.html\u003e",
"sig": "cb0ca9a084097a70cb8f0dac251e3f3dd9b5f84bddbe1c86eef8f89e9c5922591353103bf0dccb9000ec53446feba8903fbfb7ad0ee6941bf50e086e577396e0"
}