Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-10 🗒️ Summary of this message: The proposed ...
📅 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>;
🗒️ 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>;