diff options
| author | Peter Todd <pete@petertodd.org> | 2023-11-08 00:51:31 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-11-08 00:51:46 +0000 |
| commit | 666aaff5d948c809cfc535a83fc944ce6d997481 (patch) | |
| tree | 21841b7ee79fc653cb3d58919d379bd0278d053e | |
| parent | 7e133513921145363880ce10ceb97c7a8f47b796 (diff) | |
| download | pi-bitcoindev-666aaff5d948c809cfc535a83fc944ce6d997481.tar.gz pi-bitcoindev-666aaff5d948c809cfc535a83fc944ce6d997481.zip | |
Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
| -rw-r--r-- | 47/10ba4aa3378ad75c2d076db01a10a6df38affb | 246 |
1 files changed, 246 insertions, 0 deletions
diff --git a/47/10ba4aa3378ad75c2d076db01a10a6df38affb b/47/10ba4aa3378ad75c2d076db01a10a6df38affb new file mode 100644 index 000000000..f094dd180 --- /dev/null +++ b/47/10ba4aa3378ad75c2d076db01a10a6df38affb @@ -0,0 +1,246 @@ +Return-Path: <pete@petertodd.org> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 62C16C0032; + Wed, 8 Nov 2023 00:51:46 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 1B2F781973; + Wed, 8 Nov 2023 00:51:46 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1B2F781973 +Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key, + unprotected) header.d=messagingengine.com header.i=@messagingengine.com + header.a=rsa-sha256 header.s=fm3 header.b=FQtAE9rd +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.6 +X-Spam-Level: +X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, + RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id S9nSE0r92NO8; Wed, 8 Nov 2023 00:51:44 +0000 (UTC) +Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com + [66.111.4.27]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 5561781971; + Wed, 8 Nov 2023 00:51:44 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5561781971 +Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) + by mailout.nyi.internal (Postfix) with ESMTP id 98DF35C02A9; + Tue, 7 Nov 2023 19:51:41 -0500 (EST) +Received: from mailfrontend2 ([10.202.2.163]) + by compute3.internal (MEProxy); Tue, 07 Nov 2023 19:51:41 -0500 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= + messagingengine.com; h=cc:cc:content-type:content-type:date:date + :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to + :message-id:mime-version:reply-to:sender:subject:subject:to:to + :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= + fm3; t=1699404701; x=1699491101; bh=jCaEie1Q1nNa6ptu8bMv7xYw0Wy0 + wDqJd07ETdAw8qk=; b=FQtAE9rdUO6LIBhB5g/Sp2Xx5YlqiZzBxLM4OxPYkPkN + Xi6l+yjYtO0Q9fQkubaeE2TbCYqkfyi08MYemGpGpxA5NzABaOUEaYwp+vl38xT+ + o9hF83z4GBFmOM3cmIPqqGq5gIIPsdxewQPeaW8QRS+cNoujB8iRi748NcO4q6+2 + bgi/RIU7837Wo5jOtM3XWBnshXhrTifUbKcQdA8yfs6erM9IcKKd1HfJFz/E+Ckc + JjEvyjTitBMuXKs2H5j4XhYjw0Pi/5UuGU+tniA4+JFV9pVF0LdZg9a49bZW+vC8 + OImNqmmJEelKy9pi+KxKizgdH82fsbl2KZydlc/+gw== +X-ME-Sender: <xms:ndtKZc-2o9NoUf28m8OgGQ_Nes3SPt5RpTXLhrPcu5d-vNNLYiwuBQ> + <xme:ndtKZUvsvINNKUF_kObOgoWcNJn0nhSQH5GlFy93pnoZyGwCbIC-WceKBuju-xTvR + KqTfJcwDESByALGDi8> +X-ME-Received: <xmr:ndtKZSBWQKrVcnZiUcalWz18gnyxjdTOVaW224t4q0wjdoOVXFA_owhJQowN> +X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedruddukedgvdeiucetufdoteggodetrfdotf + fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen + uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne + cujfgurhepfffhvfevuffkgggtuggjsehgtderredttddvnecuhfhrohhmpefrvghtvghr + ucfvohguugcuoehpvghtvgesphgvthgvrhhtohguugdrohhrgheqnecuggftrfgrthhtvg + hrnhepffejtdegleeivdeigeektedtteethfevveffvdevteduhfeugfffveelheegjedv + necuffhomhgrihhnpehgihhthhhusgdrtghomhdpphgvthgvrhhtohguugdrohhrghenuc + evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvges + phgvthgvrhhtohguugdrohhrgh +X-ME-Proxy: <xmx:ndtKZcfXKLWRpIRIkV2UV4XF2g8vZ4Ay1kYHj90XH1nHi3ctLkS7cw> + <xmx:ndtKZRNu-I3yr0ifoepsU3np0e3aO7zWjVZUL_ywJhEyjtwedlaubA> + <xmx:ndtKZWmMFhpwViK5gUEcJzxQIhjO3cqifnRHJpgl1vsc9tP3LXvL0A> + <xmx:ndtKZdBtOCWPc1DCdLAkWzOHG8vzG6D5X6c94JYOwjmU3HYG2_X92A> +Feedback-ID: i525146e8:Fastmail +Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, + 7 Nov 2023 19:51:41 -0500 (EST) +Received: by localhost (Postfix, from userid 1000) + id AA46E5F81E; Wed, 8 Nov 2023 00:51:31 +0000 (UTC) +Date: Wed, 8 Nov 2023 00:51:31 +0000 +From: Peter Todd <pete@petertodd.org> +To: Antoine Riard <antoine.riard@gmail.com> +Message-ID: <ZUrbk9a9jiL87pxd@petertodd.org> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; boundary="Pi2QqCtP9yCVsVtf" +Content-Disposition: inline +In-Reply-To: <CALZpt+EZqfj=G=E37hA+k9pKYfvE0jkc3UU+H8sJVm=H3CO-JA@mail.gmail.com> + <CALZpt+GXGBbo0JjOyMr3B-3dVY2Q_DuzF6Sn3xE5W24x77PRYg@mail.gmail.com> +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + security@ariard.me, "lightning-dev\\\\@lists.linuxfoundation.org" + <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] OP_Expire and Coinbase-Like Behavior: Making + HTLCs Safer by Letting Transactions Expire Safely +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: Wed, 08 Nov 2023 00:51:46 -0000 + + +--Pi2QqCtP9yCVsVtf +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Mon, Nov 06, 2023 at 06:45:21PM +0000, Antoine Riard wrote: +> > I think you are misunderstanding a key point to my OP_Expire proposal: +> because +> > the ability to spend the preimage branch of the HTLC goes away when the +> refund +> > branch becomes available, replacing cycling or any similar technique +> becomes +> > entirely irrelevant. +>=20 +> > The situation where Carol prevents Bob from learning about the preimage +> in time +> > simply can't happen: either Carol collects the HTLC with knowledge of t= +he +> > preimage, by spending it in a transaction mined prior to the expiration +> time +> > and ensuring that Bob learns the preimage from the blockchain itself. Or +> the +> > HTLC expires and Bob can use the refund branch at his leisure. +>=20 +> I think I understand the semantic of the OP_Expire proposal overall +> correctly, however I'm not sure it prevents replacing cycling or any +> similar adversarial technique, as the forwarding node might be the attack= +er +> in some scenario. + +<snip> + +> Assuming this advanced scenario is correct, I'm not sure the OP_Expire +> proposal is substantially fixing all the adversarial replacement cycling +> situations. + +What you are describing here is a completely different problem than what +OP_Expire aims to solve. + +The problem that OP_Expire aims to solve is the fact that Carol could preve= +nt +Bob from learning about the preimage in time, while still getting a chance = +to +use the preimage herself. OP_Expire thoroughly solves that problem by ensur= +ing +that the preimage is either broadcast in the blockchain in a timely fashion= +, or +becomes useless. + +The problem you are describing, as Zmm points out below, doesn't actually e= +xist +in Bitcoin right now. But it could exist if we adopted v3 package relay, wh= +ich +as I've pointed out elsewhere, is inferior to using RBF. + + +On Tue, Nov 07, 2023 at 03:44:21PM +0000, Antoine Riard wrote: +> Hi Zeeman, +>=20 +> > Neither can Bob replace-recycle out the commitment transaction itself, +> because the commitment transaction is a single-input transaction, whose +> sole input requires a signature from +> > Bob and a signature from Carol --- obviously Carol will not cooperate on +> an attack on herself. +>=20 +> The replacement cycling happens on the commitment transaction spend itsel= +f, +> not the second stage, which is effectively locked until block 100. +>=20 +> If the commitment transaction is pre-signed with 0 sat / vb and all the +> feerate / absolute fee is provided by a CPFP on one of the anchor outputs, +> Bob can replace the CPFP itself. After replacement of its child, the +> commitment transaction has a package feerate of 0 sat / vb and it will be +> trimmed out of the mempool. +>=20 +> This is actually the scenario tested here on the nversion =3D 3 new mempo= +ol +> policy branch (non-deployed yet): +> https://github.com/ariard/bitcoin/commits/2023-10-test-mempool-2 +>=20 +> As of today commitment transactions might not propagate if dynamic mempool +> min fee is above pre-signed commitment transaction, which is itself unsaf= +e. +> I think this behavior can currently be opportunistically exploited by +> attackers. + +Yes, obviously it can be. For starters, you can easily end up in a situation +where the commitment transaction simply can't get mined, an obvious problem. + +> In a post-package relay world, I think this is possible. And that +> replacement cycling attacks are breaking future dynamic fee-bumping of +> pre-signed transactions concerns me a lot. + +Well the answer here is pretty clear: v3 package relay with anchors is brok= +en. + +My suggestion of pre-signing RBF replacements, without anchor outputs, and = +with +all outputs rendered unspendable with 1 CSV, is clearly superior: there are +zero degrees of freedom to the attacker, other than the possibility of +increasing the fee paid or broadcasting a revoked commitment. The latter of +course risks the other party punishing the fraud. + +This does have the practical problem that a set of refund transactions will +also need to be signed for each fee variant. But, eg, signing 10x of each i= +sn't +so burdensome. And in the future that problem could be avoided with +SIGHASH_NOINPUT, or replacing the pre-signed refund transaction mechanism w= +ith +a covenant. + +Using RBF rather than CPFP with package relay also has the advantage of bei= +ng +more efficient, as no blockspace needs to be consumed by the anchor outputs= + or +transactions spending them. Of course, there are special circumstances where +BIP125 rules can cause CPFP to be cheaper. But we can easily fix that, eg by +reducing the replacement relay fee, or by delta-encoding transaction update= +s. + + +As SIGHASH_NOINPUT is desirable for LN-Symmetry, a softfork containing both= + it +and OP_Expire could make sense. + +--=20 +https://petertodd.org 'peter'[:-1]@petertodd.org + +--Pi2QqCtP9yCVsVtf +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- + +iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmVK25EACgkQLly11TVR +Lzd6ZRAAgpGQmGngE/Wnz87IeQiSZnlR9l4AVHMrx1GUqU1id7DoV+WMytwLqEz5 +fMQ4Cj1tKnc3ELKWJgOuXNaeHi9hu1yzBxYAoaLBqVujHJ56H8kjVGX3NPfhfjxf +5pn5kOXQBnosm5++3H5k9MvxgGvXE4LkXKszFXEVRw5Yaal33J1HYJzSpKbHcrxN +f7WjGePzOSjrTRR5wPbIS/Yr1AXzyXsVqi4dQY1i7T4g5UvcxcByDUuYLEiWb1mH +WjvG5dZ/FiMKLKPMLib/pPvwcx3xs6fFNEq1ketdBS7B1l+Ddqfju/5jyjtnJPl/ +nwiA9Dl8vSUGJFxIlen3fg/d+FSZWuQUYmLLnABsoU6xi7q1xWYr9MCLvLAq06G9 +eX718SAh1xyeRpZyIvdS5OK9JP9m918yZtZ6/fysnlwYV27YhtvkLG3ceBy2tvW1 +GQRwfWtsNaZAJ0EKlSiFxDznE6U4J1dQKf52PTM6QkDTElAVEEroWjzgNa6MRnB0 +tDpryrlaNe9G3RJusAJTanTbU8Esmr7I6T1mFvl2u75FATn1lWNOkVuIKp+xIYGj +tDQDIZ/dDKPAaW7DzUNh10RWdw+TPeweu3q0Q29CRa6xeSRfmdAS9oV2FxclQXbW +jIcprbbk0dSlHGNb8yycQfMUrsMnApkB90dcIYLb03TasFt3Y7Q= +=edNz +-----END PGP SIGNATURE----- + +--Pi2QqCtP9yCVsVtf-- + |