From: "Swambo, Jacob" <jacob.swambo@kcl•ac.uk>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
Date: Tue, 3 May 2022 16:40:22 +0000 [thread overview]
Message-ID: <VI1PR03MB51031D56CE0EFBAAB86CC370CCC09@VI1PR03MB5103.eurprd03.prod.outlook.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1932 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6159 bytes --]
next reply other threads:[~2022-05-03 16:40 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-03 16:40 Swambo, Jacob [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-04-29 13:22 Swambo, Jacob
2022-05-03 10:38 ` darosior
2022-04-22 17:14 pushd
2022-04-22 13:35 pushd
2022-04-25 13:34 ` Hampus Sjöberg
2022-04-22 11:11 darosior
2022-04-22 11:44 ` rot13maxi
2022-04-22 11:54 ` darosior
2022-04-22 17:01 ` Luke Dashjr
2022-04-24 20:41 ` Richard Myers
2022-04-25 13:35 ` darosior
2022-04-25 16:35 ` darosior
2022-04-25 1:46 ` Erik Aronesty
2022-04-25 16:35 ` Nadav Ivgi
2022-04-25 16:57 ` Nadav Ivgi
2022-04-26 20:13 ` Jeremy Rubin
2022-04-29 5:08 ` Nadav Ivgi
2022-04-29 8:30 ` darosior
2022-04-29 10:21 ` Nadav Ivgi
2022-04-29 11:40 ` Nadav Ivgi
2022-05-01 23:35 ` Billy Tetrud
2022-04-30 8:09 ` Nadav Ivgi
2022-04-30 11:15 ` Greg Sanders
2022-05-01 14:25 ` Nadav Ivgi
2022-05-03 15:51 ` Jeremy Rubin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR03MB51031D56CE0EFBAAB86CC370CCC09@VI1PR03MB5103.eurprd03.prod.outlook.com \
--to=jacob.swambo@kcl$(echo .)ac.uk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox