> 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@lists.linuxfoundation.org> wrote: > Hi Antoine, > > On Sat, Jun 10, 2023 at 2:23 AM Antoine Riard <antoine.ri...@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@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
