📅 Original date posted:2022-05-03
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220503/0dcb6bd3/attachment.html>;
Swambo, Jacob [ARCHIVE] /
npub1j4…ck54p
2023-06-07 23:08:55
in reply to nevent1q…aqzf
Author Public Key
npub1j4wu6d8jvnpht5gy9gfskeprr95ryv8qs0lc4quh7u4yptfarhzs8ck54pSeen on
wss://relay.nostr.bandPublished at
2023-06-07 23:08:55Event JSON
{
"id": "3e7514abad752fdc2a60eb8a23edf4e58704674e6eee214ef115a435b4d16382",
"pubkey": "955dcd34f264c375d1042a130b642319683230e083ff8a8397f72a40ad3d1dc5",
"created_at": 1686179335,
"kind": 1,
"tags": [
[
"e",
"487fbec84c395e5cf2a53ec5ed0e3bd967995706171f5cc248803ee81727e399",
"",
"root"
],
[
"e",
"55b2a9be8d679637071f96a7eb72db4c7dc5a41c5671117485bf994b8c9c7ffa",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2022-05-03\n📝 Original message:Thanks Darosior for your response.\n\nI 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?\n\nFirstly, 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.\n\nSecondly, 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.\n\nThird, 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:\n\n\u003cpk1\u003e OP_CHECKSIG \u003cpk2\u003e OP_CHECKSIGADD \u003cpk3\u003e OP_CHECKSIGADD 2 OP_EQUAL \u003cAPOAS|SINGLE:signature_covenant_tx\u003e \u003ccovenant_PK\u003e OP_CHECKSIG\n\nAnd they produce this witness:\n\n\u003cSINGLE:sig_1\u003e \u003cALL:sig_2\u003e\n\nThe second participant can, for example, add a change output before signing. \u003csig_1\u003e is not sufficient and so can't be repackaged without the authorisation of participant 2.\n\n\nThe 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.\n\n\nJacob Swambo\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220503/0dcb6bd3/attachment.html\u003e",
"sig": "972a1be8ad65dd1c7c5d6e9aaa7d6b2a616580c6935b75cdcf83eb8d1661e73c19fb8002f8bd64b46ade964dff8751b9236b4548424c1c8fa2812243cc6f192d"
}