path: root/d4/1ba918e3fb4c780551f5c93b539c9c69ae558b

Return-Path: <pete@petertodd.org>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4FD8BC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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: <xms:FiGDZSuTyu8oTAXHMgn1HsRVKB6AVEysAg_PnouOTycVhtc1ooIXtw>
 <xme:FiGDZXdnE1dpYaE5vR2h404aKvKQBzxdg_wnnNil5Sffgsqwm4Zcvx-e-uItsSQi7
 Kpyb7KP9Uiod6AyhZY>
X-ME-Received: <xmr:FiGDZdxPTA0R8hnSwoTrc7dIUXkXAxb5tW0rpjElyOi95xG21qUnzWxxqA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdduvddgleelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtugesghdtreertd
 dtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthhouggu
 rdhorhhgqeenucggtffrrghtthgvrhhnpeeitedvffffkefhhefgveffueefkeefkeelke
 efkeektedvtdffudejueelleelheenucffohhmrghinheplhhinhhugihfohhunhgurght
 ihhonhdrohhrghdpghhithhhuhgsrdgtohhmpdhpvghtvghrthhouggurdhorhhgnecuve
 hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvsehp
 vghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:FiGDZdMU8eSaf2kyEt_vQphBJEvizhHHxOfne7CpBQT5BoXimlmhhQ>
 <xmx:FiGDZS80I3z1IsF5LhBz2cTv1boMnJNoqitK5iTZt7tR4QF1beyCfQ>
 <xmx:FiGDZVUOGtqTmewz8K9ii_3pDt4citaKtWhkCDQEDxjfnil5b6wVjw>
 <xmx:FiGDZUL4iFbYVERch-LWCnO2b4srO3mEfvz1kmoOxYPrW4HhTkwJPg>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 <bitcoin-dev@lists.linuxfoundation.org>; 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 <pete@petertodd.org>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <ZYMhEJ3y11tnDOAx@petertodd.org>
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 <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, 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--