Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3644FC002D for ; 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 ; 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 ; 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 ; 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" To: "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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: OP_CHECKSIG OP_CHECKSIGADD OP_CHECKSIGADD 2 OP_EQUAL OP_CHECKSIG And they produce this witness: The second participant can, for example, add a change output before signing= . 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

Thanks Darosior for your response.

 

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?

 

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.<= /p>

 

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 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:

 

<pk1> OP_CHECKSIG &l= t;pk2> OP_CHECKSIGADD <pk3> OP_CHECKSIGADD 2 OP_EQUAL <APOAS|SI= NGLE:signature_covenant_tx> <covenant_PK> OP_CHECKSIG

 

And they produce this witness:

 

<SINGLE:sig_1> <A= LL:sig_2>

 

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.

 

 

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>

 

 

Jacob Swambo

 

--_000_VI1PR03MB51031D56CE0EFBAAB86CC370CCC09VI1PR03MB5103eurp_--