Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-12 🗒️ Summary of this message: The proposed ...
📅 Original date posted:2023-06-12
🗒️ Summary of this message: The proposed changes to allow tx replacement by smaller witness could provide a solution to the potential payload extension attack, but further analysis is needed. The annex feature in taproot can benefit unstructured data storage and time-locked vaults.
📝 Original message:
> 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?
The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or scriptpath spends, ala
https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 .
It's much easier to think about one-off replacements from an anti-DoS
perspective.
We would have to think a lot harder if that actually solves the problem and
maintains the prospective use-cases before diving into analysis, regardless.
Cheers,
Greg
On Sat, Jun 10, 2023 at 5:02 AM Joost Jager via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230612/2d695cd7/attachment.html>;
🗒️ Summary of this message: The proposed changes to allow tx replacement by smaller witness could provide a solution to the potential payload extension attack, but further analysis is needed. The annex feature in taproot can benefit unstructured data storage and time-locked vaults.
📝 Original message:
> 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?
The only plausible case I could see moving forward is replacing the
transaction to a form that has *no* annex or scriptpath spends, ala
https://github.com/bitcoin/bitcoin/pull/24007#issuecomment-1308104119 .
It's much easier to think about one-off replacements from an anti-DoS
perspective.
We would have to think a lot harder if that actually solves the problem and
maintains the prospective use-cases before diving into analysis, regardless.
Cheers,
Greg
On Sat, Jun 10, 2023 at 5:02 AM Joost Jager via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230612/2d695cd7/attachment.html>;