1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
|
Return-Path: <jacob.swambo@kcl.ac.uk>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3644FC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 16:40:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 14FA0417CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 16:40:30 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=kcl.ac.uk
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id WDrolqlSeyvY
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 16:40:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from EUR04-HE1-obe.outbound.protection.outlook.com
(mail-he1eur04on0714.outbound.protection.outlook.com
[IPv6:2a01:111:f400:fe0d::714])
by smtp4.osuosl.org (Postfix) with ESMTPS id 08F0B417CD
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 3 May 2022 16:40:26 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=GGhukwXXJPITgRFcO0uMQ9kHX1jC6buao7A4m/a6l+Tmyk7ixaT0s8cxPQcJQXjtMqpGadKfi8kKZ8tJCt2rrVxvFSbWwXLHaCye84ob3rY5BK1E2dC8Jyxo4F68+0Iie6nWUX554YoZjdHn063HUP2V4il9Vg3IyRLpYAQeVdbuL5m/5mzFbh7QiBnL+o/yPDmt1VIguCrQn6T9sY7r/KQAGmpAnP52p+E+CIYEQ5LuKBXlX2evMKm8GvQW1aromJDRoGBszXe4fgccugSa6Vq5zPgwjl/KXcuobixWbx9HqeQLx9wOgL944o/NjrMD+obb/wO5D4f5bZ1GReBeUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=1lnMlChV2bDb7qOOQYQbJBrIVsT0wqgBZWMees3UwDo=;
b=VSA2pPDMWdz50dbKxd0UYtPIU9/HdNKpbJNjVY6RU53hHx6+qvzpDCXuLspnGXwv6BzCcF5HHD6RJa6496uUPHdT9t8McjzWR94tLCDra2g44yEis7iVRaASobOG/uqjsH2/sZVA+sNGVngZxdMn9zAQEc+krZtioJrs7nA2FCeAi66LlxZYGV/ODEe5rqDICePdby8QMchbSYfl9eRPVM/DVV7ofpTJhoNcp+Fhyj6NUN89RkAwfwwHigELvC5xV5K40Rk3Z+XFxt3M2kpGDJ45g0ZKEvxEkDyDPJ8UngvjmeoTr3g9reFZ+IWvGpKe3TE6rrSlfWA8aCgU30bWLQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=kcl.ac.uk; dmarc=pass action=none header.from=kcl.ac.uk;
dkim=pass header.d=kcl.ac.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kcl.ac.uk; s=selector2;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=1lnMlChV2bDb7qOOQYQbJBrIVsT0wqgBZWMees3UwDo=;
b=tsNSiU/89DgxrinUOmQy0oNVF6+dZccp5KTutLo+F/3bFBj5FgErVtm4eNLkEiMkzi6uMQfUtIcq97OkmlYsMXATzieKPxx5uP0sbsOBEd7PX/kRP6ojI926UaEAh7E6DM3hTCj1LrKP919eoBG1e9y5wQRI6Rma2dMnzMbUDaQ=
Received: from VI1PR03MB5103.eurprd03.prod.outlook.com (2603:10a6:803:b6::30)
by DB6PR0301MB2294.eurprd03.prod.outlook.com (2603:10a6:4:47::17)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.24; Tue, 3 May
2022 16:40:22 +0000
Received: from VI1PR03MB5103.eurprd03.prod.outlook.com
([fe80::c95d:a320:c15e:e62c]) by VI1PR03MB5103.eurprd03.prod.outlook.com
([fe80::c95d:a320:c15e:e62c%7]) with mapi id 15.20.5206.024; Tue, 3 May 2022
16:40:22 +0000
From: "Swambo, Jacob" <jacob.swambo@kcl.ac.uk>
To: "bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: ANYPREVOUT in place of CTV
Thread-Index: AQHYXwvwD9pqeYkcy0e4D5RUu7Awxg==
Date: Tue, 3 May 2022 16:40:22 +0000
Message-ID: <VI1PR03MB51031D56CE0EFBAAB86CC370CCC09@VI1PR03MB5103.eurprd03.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=kcl.ac.uk;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c7007ad3-30f5-4c80-cf5b-08da2d239dfe
x-ms-traffictypediagnostic: DB6PR0301MB2294:EE_
x-microsoft-antispam-prvs: <DB6PR0301MB229429BE2740230901BEC5AACCC09@DB6PR0301MB2294.eurprd03.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5ho3OyeR+X2pE9OQO1vi6uu8en4rSwt8ogpF5bsmAWSAI+/qYs+aho1KiPl5E1m5BmsuHjHvghIH6zejkKQpYum17Y1W/Ykfb+6acjtM/EJK9y4ADNxINvRtQa/RsCSKxOpjrNb0bCk/liMSObFXAddFE76sbh+LnbEy3vd7DCuXtf2UoANNHkfJt1IUap8pVS8aqBlSYd16PelyLlvvCbrJ4EWs/XvSFMLO+LSL0PdnLY55wPL09XV+O/GDHGL2Zv5m3fP/0XwVYbBTrOscrkzQi5ktZx5ShvSpRkds3NAolFxnDezLKm4UKDWpq1tLqj7ZJZfhvJdwGOgEctQSBJ/XZtjwqZTWYd7XscYtU1ElcqVRRErU/RdGWWekEzj8le4jUNPAfx+sPCuR65964ulMpCIAo7KohziIfKkYlD9ID+2q55LwwE6q8h3nRafnSkj9Avm+T41k2a5BXRgYL4K5lmUMtWDK5iWssGL9y8Ds1v3lT/4xTqzvhQvq7NDfQe2dnhmH38hz7oHHzbOJH64lq4TgN29L8KD9mtTlBv6+nRfJDAWT3YxF94eTbllOQ6z8QvXgUxAEIJm8vDzqwPczrxtswDZkvUMS2yCV+vzqb8qfnafU90TCf6md709hhSU5UTPZY5/0Y1yMOKLxlGVBv44MIPlGDb0ATzSicY5lt0G1XBn6Skw6+5Ul5Q8Uw/wn91b2df4P+7TUbGLeLw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:VI1PR03MB5103.eurprd03.prod.outlook.com; PTR:; CAT:NONE;
SFS:(13230001)(4636009)(366004)(52536014)(122000001)(508600001)(316002)(86362001)(2906002)(38100700002)(38070700005)(76116006)(66476007)(8676002)(66446008)(64756008)(91956017)(66556008)(66946007)(55016003)(5660300002)(8936002)(186003)(71200400001)(786003)(6916009)(7696005)(33656002)(26005)(9686003)(6506007)(83380400001);
DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?JFrb1vyu+UVtT0gzBI0pc99mU4YReuR/C1p8W7EswP3z/c1ELcxPvhgfoimp?=
=?us-ascii?Q?JA4B/UbjiKZLKMmLCHMvQ2xjMkhHowVnsKxRKuzsUkl/v9dW9UlnHfXHdJx/?=
=?us-ascii?Q?0sWZ4g3reLuVt5ve9oPllqxtHbGgEibgWXvqen77Y97FcifFp4YlYDLMN5dD?=
=?us-ascii?Q?RAkYrEtoRAnu2a2ibqLSWjZyTobSes+u5+UvADtby85lbviQSSK8acZGzJln?=
=?us-ascii?Q?u+MhYhftndrwX/uvrUqmL9Q7GlbcoAykaUhswAhEx/R4M5SjAjf1L9fiE4xe?=
=?us-ascii?Q?Mn1INQWw2MfNbG3UrRTcKzEcGKK49AOmj1FLGBhf18WEpOqO6DjrEEv/R5JK?=
=?us-ascii?Q?XgGmG22KMMJGWzO2ryJ5wODfJBw6d5UZpbq1BF4MRKwywAZymN90GqIPYmdL?=
=?us-ascii?Q?99sZroVXjRvHcTlSwUBHu6BtpaXq4E6YjGX8pAcABjEwvseQ+ojoGUnh0XJH?=
=?us-ascii?Q?RcGXrk06dtfmE50DMjz8/r+gFXJ+oC54brLAsnvtPPcw03TtplGH9H9oDfiz?=
=?us-ascii?Q?Gb83KKkkVsxEcduuoAbJpu5z4vWsJVfX7bfaZuJ8fu5S+QSlUiE8/ON9f6CH?=
=?us-ascii?Q?q6TrPRvx4T0mSmyF3YiscwIQhPcp6J/KTo+FMSBT9nq54RX6iX/oLrmQ4xom?=
=?us-ascii?Q?Qap8e7VubXldR8HTVnYaw+dg2b6zmxTlczs7fbVhc59cZifgbeK/VDxE/32Q?=
=?us-ascii?Q?AL9FfLmJlq5HpXnPbEBzyo60Eqd/zKK7+VI+JqtXdKTrPCdYIqX5zEHwuK1J?=
=?us-ascii?Q?A3Ly5RfrykMdO1yzS2YNrnRnHgniq7Eg3b7+cPDLleZ6f7szE0lK29z85XvX?=
=?us-ascii?Q?3YB2zWgAorOI3Rv/VaELf4qY0uRNBqJk29nBsEjbGwrOybP9g3XES7O5yB6E?=
=?us-ascii?Q?nt8+mPQ6+XSUBnC7IzclYVBJPYzkDUljd7IxeKHGMgpOZg47sbRZcf2WdfKd?=
=?us-ascii?Q?vZIPhY1ERAkxHuD8zjv7qjPKkwgtyRDZB7HYaUSvi/tEqned7a5DlIpMN4aP?=
=?us-ascii?Q?FbvP/6zdGJGByOyEMdlWZDLbqVOPwWrEwk0XUwlFYqhYDpNmPmANUdbsHHLa?=
=?us-ascii?Q?8aDLHNHOe6RMjXcNaVmUg7UIxvUy82NJVjOIEf2cD+RwXjVsL52k8fmJISs6?=
=?us-ascii?Q?PfcRe8Vs6NS4605/mJ6BuaTruJzs2Q1/FhCNXZOxRbMlq5YdMB2sPAzUb6XK?=
=?us-ascii?Q?Un965Ob7rpqRxkaEqjSHanSpN443mdV7FJwFdsz0CzhWdBLfd7JevWXzRybP?=
=?us-ascii?Q?FbYTAl+FN7peSqhOpdyZIZMXzway0Qx77XsMbPPzxqby0bEEUhwFz4aADv78?=
=?us-ascii?Q?fvgFo+A6bEUFCZpcCNSjkzOuJrU025lix5C3pnp8YEXiUlAz5N/TQVL5B0Q8?=
=?us-ascii?Q?DRfpPXkOdj8uzDMPU4Bin4jW+8iXEhUeuNlVaV7YBO6S2To73b2PuQNeXsHV?=
=?us-ascii?Q?i5MH7b3CpHgjAFwuzjXr5KkDHccGHJpxpCKNnYquOABlLQqQx+NEenMn3sNz?=
=?us-ascii?Q?3T9aAy/lP2VopahNAXFoyelqcj/x3hMSzYAUzwdeQIZJVRV6w4B8BZmzHmE2?=
=?us-ascii?Q?Q9ZWyi66RlcQ2kUzJ/KxE2yCC6qrbqdzEMcRCAFmubCTIe5w8CjekfAYvlYd?=
=?us-ascii?Q?/+eMOpLsVwaPCTc1vjjL5dfiockuZhcF8FEUxyirUp9ufk1Uwf2w0eeFPJ8O?=
=?us-ascii?Q?WjfJJ590Rh7BFj0Jg5Ybi9VK1E/fnUahsrWUI4UNqDtq/Gf6c/+ybsAxjbTR?=
=?us-ascii?Q?OWNZ7hOP0xlgS7SytolbVqLORt7a1zk=3D?=
Content-Type: multipart/alternative;
boundary="_000_VI1PR03MB51031D56CE0EFBAAB86CC370CCC09VI1PR03MB5103eurp_"
MIME-Version: 1.0
X-OriginatorOrg: kcl.ac.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR03MB5103.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c7007ad3-30f5-4c80-cf5b-08da2d239dfe
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 May 2022 16:40:22.4017 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8370cf14-16f3-4c16-b83c-724071654356
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /iTvprr+t5Gny1hw4gZRaiz+L3yfThAACL92nYtFlU27gD7lXYbYCpxwDwQ1KIbIzg8xKBNA+unWcd4sbCyQEw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0301MB2294
X-Mailman-Approved-At: Tue, 03 May 2022 16:52:15 +0000
Subject: Re: [bitcoin-dev] ANYPREVOUT in place of CTV
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2022 16:40:30 -0000
--_000_VI1PR03MB51031D56CE0EFBAAB86CC370CCC09VI1PR03MB5103eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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
--_000_VI1PR03MB51031D56CE0EFBAAB86CC370CCC09VI1PR03MB5103eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc=
hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of=
fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"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=3D"EN-GB" link=3D"blue" vlink=3D"#954F72" style=3D"word-wrap:bre=
ak-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">Thanks Darosior for your response.
<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">I see now that APOAS (e.g. with ANYONECANPAY and/or S=
INGLE) and CTV (with less restrictive templates) fall prey to the same trad=
e-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 t=
he question, why would we want to have a way to commit to less restrictive =
templates?
<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"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=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"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=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">Third, in a trusted multi-party context you can safel=
y 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=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span class=3D"DefaultF=
ontHxMailStyle"><span style=3D"font-size:16.0pt"><pk1> OP_CHECKSIG &l=
t;pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SI=
NGLE:signature_covenant_tx> <covenant_PK> OP_CHECKSIG<o:p></o:p></=
span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">And they produce this witness:<o:p></o:p></span></spa=
n></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal" style=3D"text-indent:36.0pt"><span class=3D"DefaultF=
ontHxMailStyle"><span style=3D"font-size:16.0pt"><SINGLE:sig_1> <A=
LL:sig_2><o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"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 rep=
ackaged without the authorisation of participant
2.<o:p></o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">The additional flexibility through composing APOAS wi=
th 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 de=
bate recently is part of that maturation process and I'm glad for it.<o:p><=
/o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt">Jacob Swambo</span></span></p>
<p class=3D"MsoNormal"><span class=3D"DefaultFontHxMailStyle"><span style=
=3D"font-size:16.0pt"><o:p> </o:p></span></span></p>
</div>
</body>
</html>
--_000_VI1PR03MB51031D56CE0EFBAAB86CC370CCC09VI1PR03MB5103eurp_--
|