Thanks Darosior for your response. I see now that APOAS (e.g. with ANYONECANPAY and/or SINGLE) and CTV (with less restrictive templates) fall prey to the same trade-off between flexibility and safety. So I retract my statement about that 'point in favour of OP_CTV'. It would be nice to by-pass the trade-off, but it seems to be unavoidable. That begs the question, why would we want to have a way to commit to less restrictive templates?
Firstly, I posit that if a transaction does not allow RBF, then it would be very difficult for an attacker to repackage parts of the transaction into a malicious alternative and rebroadcast it before it reaches the mempool of the majority of nodes, who would then reject the malicious alternative. Secondly, some covenant-based applications aren't as critical as others, and it may well be acceptable to take the risk of using something like ANYONECANPAY|ALL even with RBF enabled. Third, in a trusted multi-party context you can safely make use of flexible signature messages. Let's say there are 3 people and a UTXO with the following locking script as a single leaf in the tapscript: <pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SINGLE:signature_covenant_tx> <covenant_PK> OP_CHECKSIG And they produce this witness: <SINGLE:sig_1> <ALL:sig_2> The second participant can, for example, add a change output before signing. <sig_1> is not sufficient and so can't be repackaged without the authorisation of participant 2. The additional flexibility through composing APOAS with other SIGHASH modes, and the ability to re-bind covenant transactions to different UTXOs allows protocol designers to do more with APOAS covenants than with CTV covenants (as currently spec'd). I'm not yet convinced that BIP-118 is totally safe, but I think the debate recently is part of that maturation process and I'm glad for it. Jacob Swambo
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
