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: AQHYW8tdARvP2FleBkG9x4CUtBW6Kw==
Date: Fri, 29 Apr 2022 13:22:14 +0000
Message-ID: <VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9@VI1PR03MB5103.eurprd03.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8Vm76W+qXmp2aoMnhNbIRfPkLiWnlQ+ztqoOFp9QmTeyeARMX3zbm4vBJ+R7?=
 =?us-ascii?Q?ZtkzHvD1iPEnoGawZwo9ej8/hTzA5Ulvdza9OV7nv6t0PBnUGIWaQQ9e9tcL?=
 =?us-ascii?Q?S/xaqFV1M4OqLChQxCft4wQ+bDXi9joU2dlGLD8HO/h4POfdINUfThiAqwRL?=
 =?us-ascii?Q?0/c/nPGHB75ueRoMpr5+l9BUt7aH9hfKMw68MtO4Rmd9WdrBGdFXBpx7Rles?=
 =?us-ascii?Q?tEIAM6LeD0SwiPOkSvkT9GSPfTAc+tdKz+9vsgji77g7DR5iE4BarryCQKvs?=
 =?us-ascii?Q?KwC2sNaD9nr7L5u0mUhJjEKV9ZywekIYC2EIEGy7TXiO6b3xK1j3hqDxf27b?=
 =?us-ascii?Q?Wrr4QgyS85Tn265d/xzYFUmvib+PJ8evRyFFOXtwCLBdNObNn+gGuN7ij10M?=
 =?us-ascii?Q?STgyHLq4Vb+tn4eoySh7EbbsbJiximY3yi12Bv5rYc8ybx450ldNejmlbrhJ?=
 =?us-ascii?Q?h/yNTBQ5Z+I5cktUJY1upcWQIRLpA2PTdCGQUzK/qz+3PHCz8DdnCty0JquW?=
 =?us-ascii?Q?i7/G7kRo1Duz4at3xRDlPbSdsQjViizCge/43mkwgoTt93aWU09tsi0NEauz?=
 =?us-ascii?Q?l5NqY8egxtRC6vbQCpVi2rMYrDa+C8LbOMAo6Ovx6wmMGRbERJDKYdgRZpv3?=
 =?us-ascii?Q?T7e0sB1+4Yj+rlUr7IraaqkFPCjbghewtWHIUGXTHEgXIiZjMTjpNysyaRa/?=
 =?us-ascii?Q?5KN2cI5T4O0sr92g4hI44LaGB+vEyJZnczgoyXe3aBuvDLsKpmC0te+ij5q+?=
 =?us-ascii?Q?14ZKJMXyC3ZG92Urtf0DI/U52xMZKU//YNPL06t7re6994AD/eDrlsd2Ug62?=
 =?us-ascii?Q?DUstlNuFGumKVinfCA6LKN7a/JMTzD0Qh9yYorU20a43DseMXmB1EXASnvXY?=
 =?us-ascii?Q?O3Nd0urT5P+a7MOB3umPy6iON5kFiBeLUEaBOMYEYBM4RnBsoGm0un0OCCSl?=
 =?us-ascii?Q?aNcmSaxCpK295te8acXrvktuBQ6J0hx4CLH+jDAVNdS+Rsdmgtmlw9JafW7w?=
 =?us-ascii?Q?YoUZFulWYkPKAFVlbgAdW4EFYmASNCZl5mitgYqrWXAj1K/WUk79qknTQ8Q9?=
 =?us-ascii?Q?15rBNTyMrjtMrGtCC41l9Wz94NeboA6SACGJRbJK/SrXswTWxrPl6t7ie7hH?=
 =?us-ascii?Q?KWqjJ/Ogkg4K74B0H27DgRM5P1cVR+jZD9H2Pb56yCZIiuAI6EDMYgzGK9ga?=
 =?us-ascii?Q?zp7xY8brrZlcDITSBv1ERjjNzu9hacSE4woxBygmCo80JcWoFA3/+Z6mCbZs?=
 =?us-ascii?Q?/wvYzBC9YBWgrUahIFXwW/wEvFEUfM3jFy1X+VUA30rXujwasMlq4gYW7aj4?=
 =?us-ascii?Q?68J01pYQ7SwG7WC8O2rgeV+4RSADhak2iO90TeVBLBAOR2rpQODqOFIS1uEC?=
 =?us-ascii?Q?avTzQkADPDzWNjVTmE7T8hL3o4L7w0A8aHO5lp7O+A67djDN9mopeW5jVzLU?=
 =?us-ascii?Q?+68tHZJtobbIt20P42cbfOf8MXVMJg86ii2AWZOU+PVJS8Fy96nt53eFG7Dq?=
 =?us-ascii?Q?qTMetb76d0lz/h1GLz2JJ6dPJLKu1lntDJ+gE2Mfl3QqKPFO1ro+1cKAIDzN?=
 =?us-ascii?Q?Jx3A6+7epiBk7o0FL891vJGtjdVrP3HD5gzvhyxD8AoaWXKbVSsEWCBYxG97?=
 =?us-ascii?Q?wh/qSsKLWdY/h3BcuduFMnzaq8WV+oGYZEySGIhwsAqg4d45ybxW6713XqdO?=
 =?us-ascii?Q?0yXrBzObvlL1l0B0uXAQ5oKQpFfVZPN8PDOzxV9XjY3DdvcT5PtgHblahvHS?=
 =?us-ascii?Q?y9Oax9OECC0NLOJbOfXko/v5vcaWGi0=3D?=
Content-Type: multipart/alternative;
 boundary="_000_VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9VI1PR03MB5103eurp_"
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: d45709c1-f23f-402d-6a6c-08da29e3467e
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2022 13:22:14.3195 (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: ZSAPxrvgFLl4JXtgCGCZst4efXuOG1iVQyWd8dxeHtysUCsXahDopFBsYxHTJ+7gBXFBq0X8UlW8EYkbunQYKA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0302MB2589
X-Mailman-Approved-At: Fri, 29 Apr 2022 13:25:19 +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: Fri, 29 Apr 2022 13:22:20 -0000

--_000_VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9VI1PR03MB5103eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS=
 in lieu of CTV in the short-term (given the additional benefit of enabling=
 Eltoo), there's a point to add in favour of CTV (or similar) in the long-t=
erm beyond as an optimisation.

With APOAS-based covenants, the signature message algorithm is tied to both=
 the covenant commitment and transaction validation. Coupling these things =
introduces a trade-off between safety and flexibility with covenant-based a=
pplications. E.g. the maximally safe and restricted covenant commits to all=
 inputs and outputs of the transaction (using SIGHASH ALL). However, a less=
 restricted covenant commits to, for example, a single input and a single o=
utput (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use=
 of transaction malleability and signature replay. If instead we separate t=
he covenant commitment from the signatures to validate transactions (as wit=
h CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off. The f=
lexibility of additional templates with new CTV versions or with the TXHASH=
 primitive seems to me to enable significantly more utility for covenant-ba=
sed applications.

Best regards,

Jacob Swambo

--_000_VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9VI1PR03MB5103eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body>
Hi,
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">While I agree with the arguments in favour of (optional A=
NYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional b=
enefit of enabling Eltoo), there's a point to add in favour of CTV (or simi=
lar) in the long-term beyond as an
 optimisation.&nbsp;</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">With APOAS-based covenants, the signature message algorit=
hm is tied to both the covenant commitment and transaction validation. Coup=
ling these things introduces a trade-off between safety and flexibility wit=
h covenant-based applications. E.g.
 the maximally safe and restricted covenant commits to all inputs and outpu=
ts of the transaction (using SIGHASH ALL). However, a less restricted coven=
ant commits to, for example, a single input and a single output (using ANYO=
NECANPAY|SINGLE) but opens itself
 up to attacks making use of transaction malleability and signature replay.=
 If instead we separate the covenant commitment from the signatures to vali=
date transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-p=
ass this trade-off. The flexibility
 of additional templates with new CTV versions or with the TXHASH primitive=
 seems to me to enable significantly more utility for covenant-based applic=
ations.</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Best regards,</div>
<div dir=3D"auto"><br>
</div>
<div dir=3D"auto">Jacob Swambo</div>
</body>
</html>

--_000_VI1PR03MB5103AF9CB4D99A32F88B4BF6CCFC9VI1PR03MB5103eurp_--