Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4FD8BC0037 for ; Wed, 20 Dec 2023 17:15:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0563A61031 for ; Wed, 20 Dec 2023 17:15:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0563A61031 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=T6Fsl2Sq 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQICm9ctds1K for ; Wed, 20 Dec 2023 17:15:05 +0000 (UTC) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0EEEC60EF3 for ; Wed, 20 Dec 2023 17:15:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0EEEC60EF3 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2CA7A3200A93 for ; Wed, 20 Dec 2023 12:15:03 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 20 Dec 2023 12:15:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1703092502; x=1703178902; bh=bHRQz93e1yTXp3cEIFSX/BwPif+3MNcL5pp zu4ceKbw=; b=T6Fsl2Sqeg2DLwCcEC+DAo6PqYCrxHcbphFxWhBcE+8r62S0OD9 GZ8Y0V/XpMM3sC9CXRdAJZkCd1+/X/69t1MI8dTrWqQgYi8MuaTRYlYweMA+skHv uJWuh0Ygyb/yCOn6v0+N/s4ZzowLmrX0uAQS+701cbQUhn+dyV8WZCEsLUCpkJqB 2i3XxOZ9Wwh9LI1F4YtfG+BRpKQz81b+PROieHtgm4QD/au1aYTEgD0Ua6KMkqIO +Zb+P39xRvpvQrGAd0vArSqugah8DD5/ICY7EJmiqzpnfbY8YCf+Km4lHjTyTR1K VqbJV3DPQgiqTYTBzBJlIVxE4V34aktX9+A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduvddgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd dtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthhouggu rdhorhhgqeenucggtffrrghtthgvrhhnpeeitedvffffkefhhefgveffueefkeefkeelke efkeektedvtdffudejueelleelheenucffohhmrghinheplhhinhhugihfohhunhgurght ihhonhdrohhrghdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehp vghtvghrthhouggurdhorhhg X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 20 Dec 2023 12:15:01 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 72ED55F84E; Wed, 20 Dec 2023 17:14:56 +0000 (UTC) Date: Wed, 20 Dec 2023 17:14:56 +0000 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VFDNCntG010qouRD" Content-Disposition: inline Subject: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks 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: Wed, 20 Dec 2023 17:15:08 -0000 --VFDNCntG010qouRD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable V3 transactions(1) is a set of transaction relay policies intended to aim L2/contracting protocols, namely Lightning. The main aim of V3 transactions= is to solve Rule 3 transaction pinning(2), allowing the use of ephemeral anchors(3) that do not contain a signature check; anchor outputs that _do_ contain a signature check are not vulnerable to pinning attacks, as only the intended party is able to spend them while unconfirmed. The main way that V3 transactions aims to mitigate transaction pinning is w= ith the following rule: A V3 transaction that has an unconfirmed V3 ancestor cannot be larger t= han 1000 virtual bytes. Unfortunately, this rule - and thus V3 transactions - is insufficient to substantially mitigate transaction pinning attacks. # The Scenario To understand why, let's consider the following scenario: Alice has a Light= ning channel with Bob, who has become unresponsive. Alice is using a Lightning protocol where using V3 commitment transactions with a single OP_TRUE ephem= eral anchor of zero value. The commitment transaction must be broadcast in a package, containing both the commitment transaction, and a transaction spen= ding the anchor output; regardless of the fee of the commitment transaction, thi= s is a hard requirement, as the zero-valued output is considered non-standard by= V3 rules unless spent in the same package. To pay for the transaction fee of the commitment transaction, Alice spends = the ephemeral output in a 2 input, 1 output, taproot transaction of 152vB in si= ze, with sufficient feerate Ra to get the transaction mined in what Alice considers to be a reasonable amount of time. # The Attack Enter Mallory. His goal is to grief Alice by forcing her to spend more money than she intended, at minimum cost. He also maintains well connected nodes, giving him the opportunity to both learn about new transactions, and quickly broadcast transactions to a large number of nodes at once. When Mallory learns about Alice's commitment+anchor spend package, he signs= a replacement anchor spend transaction, 1000vB in size, with a lower feerate = Rm such that the total fee of Alice's anchor spend is <=3D Mallory's anchor sp= end (in fact, the total fee can be even less due to BIP-125 RBF Rule #4, but for sake of a simple argument we'll ignore this). Next, Mallory broadcast's that package widely, using his well-connected nodes. Due to Rule #3, Alice's higher feerate transaction package does not replace Mallory's lower fee rate, higher absolute fee, transaction package. Alice's options are now: 1. Wait for Mallory's low feerate transaction to be mined (mempool expirati= on does not help here, as Mallory can rebroadcast it indefinitely). 2. Hope her transaction got to a miner, and wait for it to get mined. 3. Replace it with an even higher fee transaction, spending at least as much money as Mallory allocated. In option #1 and #3, Mallory paid no transaction fees to do the attack. Unfortunately for Alice, feerates are often quite stable. For example, as I write this, the feerate required to get into the next block is 162sat/vB, w= hile the *lowest* feerate transaction to get mined in the past 24 hours is approximately 80sat/vB, a difference of just 2x. Suppose that in this circumstance Alice needs to get her commitment transac= tion mined within 24 hours. If Mallory used a feerate of 1/2.5th that of Alice, Mallory's transaction would not have gotten mined in the 24 hour period, wi= th a reasonable safety margin. Thus the total fee of Mallory's package would have been 6.6 * 1/2.5 =3D 2.6x more than Alice's total fee, and to get her trans= action mined prior to her deadline, Alice would have had to pay a 2.6x higher fee = than expected. ## Multi-Party Attack Mallory can improve the efficiency of his griefing attack by attacking mult= iple targets at once. Assuming Mallory uses 1 taproot input and 1 taproot output= for his own funds, he can spend 21 ephemeral anchors in a single 1000vB transaction. Provided that the RBF Rule #4 feerate delta is negligible relative to curre= nt feerates, Mallory can build up the attack against multiple targets by broadcasting replacements with slightly higher feerates as needed to add and remove Alice's. The cost of the attack to Mallory is estimating fees incorrectly, and using= a sufficiently high feerate that his transaction does in fact get mined. In t= hat circumstance, if he's attacking multiple targets, it is likely that all his transactions would get mined at once. Thus having only a single attack transaction reduces that worst case cost. Since Mallory can adding and remo= ve Alice's, he can still force multiple Alice's to spend funds bumping their transactions. # Solutions ## Replace-by-Feerate Obviously, this attack does not work if Rule #3 is removed for small transactions, allowing Alice's transaction to replace Mallory via replace-by-feerate. In the common situation where mempools are deep, this is arguably miner incentive compatible as other transactions at essentially the same feerate will simply replace the "space" taken up by the griefing transaction. ## Restrict V3 Children Even Further If V3 children are restricted to, say, 200vB, the attack is much less effec= tive as the ratio of Alice vs Mallory size is so small. Of course, this has the disadvantage of making it more difficult in some cases to find sufficient UTXO's to pay for fees, and increasing the number of UTXO's needed to fee b= ump large numbers of transactions. # References 1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/0= 20937.html, "[bitcoin-dev] New transaction policies (nVersion=3D3) for contracting p= rotocols", Gloria Zhao, Sep 23 2022 2) https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implement= ation-details, "The replacement transaction pays an absolute fee of at least the sum pa= id by the original transactions." 3) https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralan= chors.mediawiki --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --VFDNCntG010qouRD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWDIQ4ACgkQLly11TVR Lzdm7RAAiadisypXQECGJfQZzBw/Ofx25Rarv3O4jaKkIXp4MK4OB/sWeDUnsMu0 +7A3oKyiwl34bo2MvYdLhnkh77VincjSSTFxLgJ8gRMxbQLQoFFjlzAyjyhS8Rw6 0DXFViVcc8w587DEViSwEcLJkdSpf7CFLOrn822tlu8LU+/PgAvZt+WOGFuc77Xw vn/I4Hc2Yn0EhZmWfHUaRcSng0QCHjHSZSnQC4dMUYhFO7B+PePS1d/F7QHSzRG7 sZjh3kfZ+v47Aftr4x0O94X9iZb9/K3guZOhMYu9ll33wEoxHdOruqmtW2wstUxz CaXCQd75dOeCRvLksHYz8pDLgJHe9+6I4YiD+EE1QWXYHynnhHfSXexf11GAy3EU EICAM8CEFiP3k8D7L97EqDanBvpA/UCU4zZX+6Yn0efxTZkTZrupdn2vtpAPPm+X SrpnvkpFBJaMHADTghIhSRsFUfBrWhVfCa9uox5S6Ldg2Ent82ESq6yYY/Do58A/ eI2CkeOm+j5pcLIPAx3JseGkXxPttnZphC5IOxSl7fOiCodYGkLT6ktkBY5pAPId 3Nm7SeorZhOi4SePotxs+/3+sw7a/lTwRjXyCn1JZOBXA6i0HZnZISseZM3l9w/X 2M8peWo+Bo9aBDClDfwO/ewc0R+rjys5qeNflW7uOnloTu0slUc= =87tv -----END PGP SIGNATURE----- --VFDNCntG010qouRD--