[prev in list] [next in list] [prev in thread] [next in thread]
List: bitcoin-dev
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
From: "Swambo, Jacob via bitcoin-dev" <bitcoin-dev () lists ! linuxfoundation ! org>
Date: 2022-05-03 16:40:22
Message-ID: VI1PR03MB51031D56CE0EFBAAB86CC370CCC09 () VI1PR03MB5103 ! eurprd03 ! prod ! outlook ! com
[Download RAW message or body]
Thanks Darosior for your response.
I see now that APOAS (e.g. with ANYONECANPAY and/or SINGLE) and CTV (with l=
ess restrictive templates) fall prey to the same trade-off between flexibil=
ity 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 unavoi=
dable. 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, an=
d it may well be acceptable to take the risk of using something like ANYONE=
CANPAY|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 follo=
wing locking script as a single leaf in the tapscript:
<pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APO=
AS|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 authoris=
ation of participant 2.
The additional flexibility through composing APOAS with other SIGHASH modes=
, and the ability to re-bind covenant transactions to different UTXOs allow=
s protocol designers to do more with APOAS covenants than with CTV covenant=
s (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 #3 (text/html)]
<html xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.DefaultFontHxMailStyle
{mso-style-name:"Default Font HxMail Style";
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-GB" link="blue" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">Thanks Darosior for your response. \
<o:p></o:p></span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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? <o:p></o:p></span></span></p>
<p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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.<o:p></o:p></span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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:<o:p></o:p></span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p class="MsoNormal" \
style="text-indent:36.0pt"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><pk1> OP_CHECKSIG <pk2> OP_CHECKSIGADD \
<pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SINGLE:signature_covenant_tx> \
<covenant_PK> OP_CHECKSIG<o:p></o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">And they produce this witness:<o:p></o:p></span></span></p> \
<p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p class="MsoNormal" \
style="text-indent:36.0pt"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><SINGLE:sig_1> \
<ALL:sig_2><o:p></o:p></span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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.<o:p></o:p></span></span></p>
<p class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">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.<o:p></o:p></span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> <p \
class="MsoNormal"><span class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt">Jacob Swambo</span></span></p> <p class="MsoNormal"><span \
class="DefaultFontHxMailStyle"><span \
style="font-size:16.0pt"><o:p> </o:p></span></span></p> </div>
</body>
</html>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============1629155340203794177==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic