From mboxrd@z Thu Jan 1 00:00:00 1970
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_--