path: root/27/c167818bc676504aa43c1817db44fe18db817b

Return-Path: <gloriajzhao@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 683D4C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Dec 2023 19:13:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3A44640A74
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Dec 2023 19:13:37 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3A44640A74
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=e0Ehu0EQ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JxXWxUJ9xov5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Dec 2023 19:13:34 +0000 (UTC)
Received: from mail-il1-x135.google.com (mail-il1-x135.google.com
 [IPv6:2607:f8b0:4864:20::135])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 29EF5400A4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Dec 2023 19:13:34 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 29EF5400A4
Received: by mail-il1-x135.google.com with SMTP id
 e9e14a558f8ab-35fc1a1b52bso7511885ab.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 20 Dec 2023 11:13:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1703099613; x=1703704413;
 darn=lists.linuxfoundation.org; 
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=6GDkTp+s9ttWMuwh4axCCvULmIdXkJ3V3YluWX0g0F0=;
 b=e0Ehu0EQ/LxeVhosKiHrCy6DcHnLO7w3U4ch1Jwm/ZHe0Pe4gVaccB+K4+ldJb1+6f
 ylOY+an+uzOcMjrHDH5PnFI9/IzthR2ZFGS71tl0aPK/JP5QNsR6KUSxOAHnINCf1MKZ
 hNEOsUO0spjLr6X49IGmXhOZbadJ7bnwLjWC4xUxDvhfRWkQhEYC7uxJRLPC8YOxvBD/
 tCYjSOo+7tPonpIkbAKYQYwgfb6vZOC0jl4wuvsnF119uVcfN8cDeteTQSCkU3rNAS9+
 SH1CRUWZ7nkKn/qyATcEOFJUHPpA0JCnO1GBV+rBxynI9/cel4rL2HrhBs38DfAhJVHs
 8bZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1703099613; x=1703704413;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=6GDkTp+s9ttWMuwh4axCCvULmIdXkJ3V3YluWX0g0F0=;
 b=Pt9Y9oMB3o7to683vo3Af9tMHb5v0AG8chcgrlWI0NS5prQLnSrsStGrSEUYy+C2Ec
 nv0ThrB8rO065BR4oBezgNGEnSG4U/quS02vEGEbTBJZmNqHy/QArfCe82mStDRn3ZXD
 JdwXxi6BaxSYO7p8Bo4LcCXygQZt0vyQ3m243/C+4nNkfTboZqp0cbzcQddjI00S4MxQ
 qMr3XFNfGVW0zVO0k1+dABlhD36aZJkKcaw626j/M/6gDZOx13n3Ce7Z2sYEsSnc5NA6
 kmC8mJGXGQcFUqfYJTQGRFHkiI70zu+iuCy5MJGZTbd61JSkdFGsJRmnjx4koBSg3zpu
 MVjA==
X-Gm-Message-State: AOJu0Yz2+W9KV8F7RUTThVBcu5/x7ojpoRjhCg2nHJ1TxOkIj8x2LqTH
 gSP5+LWCcKD6Cd5IOAAzGLJbcei0BcN3VdKFBB0=
X-Google-Smtp-Source: AGHT+IEfXeb4gt5NMzj+rW/A4GVZsIZOsNQH1UANudXI7mcORkxunEhBtU8rdcFTgbCQ8McKuD9JUeytU/3DDmQiSao=
X-Received: by 2002:a05:6e02:339c:b0:35f:ca3f:fa67 with SMTP id
 bn28-20020a056e02339c00b0035fca3ffa67mr1996938ilb.43.1703099612976; Wed, 20
 Dec 2023 11:13:32 -0800 (PST)
MIME-Version: 1.0
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
In-Reply-To: <ZYMhEJ3y11tnDOAx@petertodd.org>
From: Gloria Zhao <gloriajzhao@gmail.com>
Date: Wed, 20 Dec 2023 19:13:22 +0000
Message-ID: <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000072dc68060cf5c763"
X-Mailman-Approved-At: Fri, 22 Dec 2023 01:02:16 +0000
Subject: Re: [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 19:13:37 -0000

--00000000000072dc68060cf5c763
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

Thanks for spending time thinking about RBF pinning and v3.

> Enter Mallory. His goal is to grief Alice by forcing her to spend more
money
than she intended...
> ...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
transaction
> mined prior to her deadline, Alice would have had to pay a 2.6x higher
fee than
> expected.

I think this is a good understanding of the goal of Rule #3, but I'm not
sure how you're getting these numbers without specifying the size and fees
of the commitment transaction. We should also quantify the severity of the
"damage" of this pin in a meaningful way; the issue of "Alice may need to
pay to replace descendant(s) she isn't aware of" is just a property of
allowing unconfirmed descendants.

Let's use some concrete numbers with your example. As you describe, we need
80-162sat/vB to get into the next block, and Alice can fund a CPFP with a
152vB CPFP. Let's say the commitment transaction has size N, and pays 0
fees.

The lower number of 80sat/vB describes what Mallory needs to shoot below in
order to "pay nothing" for the attack (i.e. otherwise it's a CPFP and gets
the tx confirmed). Mallory can maximize the cost of replacement according
to Rule #3 by keeping a low feerate while maximizing the size of the tx.

The higher number of 162sat/vB describes the reasonable upper bound of what
Alice should pay to get the transactions confirmed. As in: If Alice pays
exactly 162sat/vB * (N + 152vB) satoshis to get her tx confirmed, nothing
went wrong. She hopes to not pay more than that, but she'll keep
broadcasting higher bumps until it confirms.

The "damage" of the pin can quantified by the extra fees Alice has to pay.

For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can
increase the cost of replacement to 80,000sat.
For a non-v3 transaction, Mallory can attach (101KvB - N) before maxing out
the descendant limit.
Rule #4 is pretty negligible here, but since you've already specified
Alice's child as 152vB, she'll need to pay Rule #3 + 152sats for a
replacement.

Let's say N is 1000vB. AFAIK commitment transactions aren't usually smaller
than this:
- Alice is happy to pay 162sat/vB * (1000 + 152vB) =3D 186,624sat
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 =3D 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(100,000vB) + 152 =3D 8,000,152sat
    - Mallory does succeed, Alice would need to pay ~7 million sats extra

Let's say N is 10,000vB:
- Alice is happy to pay 162sat/vB * (10,000 + 152vB) =3D 1,644,624
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 =3D 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(91,000vB) + 152 =3D 7,280,152sat
    - Mallory does succeed Alice would need to pay ~5 million sats extra

Let's say N is 50,000vB:
- Alice is happy to pay 162sat/vB * (50,000 + 152vB) =3D 8,124,624
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 =3D 80,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(51,000vB) + 152 =3D 4,080,152sat
    - Mallory doesn't succeed, Alice's CPFP easily pays for the replacement
    - The key idea here is that there isn't much room for descendants and
the cost to CPFP is very high

These numbers change if you tweak more variables - the fees paid by the
commitment tx, the feerate range, etc. But the point here is to reduce the
potential "damage" by 100x by restricting the allowed child size.

> If V3 children are restricted to, say, 200vB, the attack is much less
effective
as the ratio of Alice vs Mallory size is so small.

This is exactly the idea; note that we've come from 100KvB to 1000vB.

> Mallory can improve the efficiency of his griefing attack by attacking
multiple
> 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.

Note that v3 does not allow more than 1 unconfirmed parent per tx.

Let me know if I've made an arithmetic error, but hopefully the general
idea is clear.

Best,
Gloria

On Wed, Dec 20, 2023 at 5:16=E2=80=AFPM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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
> with
> the following rule:
>
>     A V3 transaction that has an unconfirmed V3 ancestor cannot be larger
> than
>     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
> Lightning
> channel with Bob, who has become unresponsive. Alice is using a Lightning
> protocol where using V3 commitment transactions with a single OP_TRUE
> ephemeral
> anchor of zero value.  The commitment transaction must be broadcast in a
> package, containing both the commitment transaction, and a transaction
> spending
> the anchor output; regardless of the fee of the commitment transaction,
> this 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 spend=
s
> the
> ephemeral output in a 2 input, 1 output, taproot transaction of 152vB in
> size,
> 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 node=
s,
> 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 feerat=
e
> Rm
> such that the total fee of Alice's anchor spend is <=3D Mallory's anchor
> spend
> (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 repla=
ce
> 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
> expiration
>    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,
> while
> 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
> transaction
> 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,
> with 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
> transaction
> mined prior to her deadline, Alice would have had to pay a 2.6x higher fe=
e
> than
> expected.
>
>
> ## Multi-Party Attack
>
> Mallory can improve the efficiency of his griefing attack by attacking
> multiple
> 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
> current
> 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
> that
> circumstance, if he's attacking multiple targets, it is likely that all h=
is
> transactions would get mined at once. Thus having only a single attack
> transaction reduces that worst case cost. Since Mallory can adding and
> remove
> 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
> effective
> as the ratio of Alice vs Mallory size is so small. Of course, this has th=
e
> 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
> bump
> large numbers of transactions.
>
>
> # References
>
> 1)
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/02=
0937.html
> ,
>    "[bitcoin-dev] New transaction policies (nVersion=3D3) for contracting
> protocols",
>    Gloria Zhao, Sep 23 2022
>
> 2)
> https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementa=
tion-details
> ,
>    "The replacement transaction pays an absolute fee of at least the sum
> paid by the original transactions."
>
> 3)
> https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanc=
hors.mediawiki
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--00000000000072dc68060cf5c763
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi Peter,</div><div><br></div><div>T=
hanks for spending time thinking about RBF pinning and v3.</div><div><br></=
div><div>&gt; Enter Mallory. His goal is to grief Alice by forcing her to s=
pend more money<br>
than she intended...<br></div><div>&gt; ...Thus the total fee of Mallory&#3=
9;s package would have<br>
&gt; been 6.6 * 1/2.5 =3D 2.6x more than Alice&#39;s total fee, and to get =
her transaction<br>&gt; mined prior to her deadline, Alice would have had t=
o pay a 2.6x higher fee than<br>
&gt; expected.</div><br></div><div dir=3D"ltr">I think this is a good under=
standing of the goal of Rule #3, but I&#39;m not sure how you&#39;re gettin=
g these numbers without specifying the size and fees of the commitment tran=
saction. We should also quantify the severity of the &quot;damage&quot; of =
this pin in a meaningful way; the issue of &quot;Alice may need to pay to r=
eplace descendant(s) she=20
isn&#39;t aware of&quot; is just a property of allowing unconfirmed descend=
ants.<br><div><br></div><div>Let&#39;s use some concrete numbers with your =
example. As you describe, we need 80-162sat/vB to get into the next block, =
and Alice can fund a CPFP with a 152vB CPFP. Let&#39;s say the commitment t=
ransaction has size N, and pays 0 fees.<br></div><div><br></div><div>The lo=
wer number of 80sat/vB describes what Mallory needs to shoot below in order=
 to &quot;pay nothing&quot; for the attack (i.e. otherwise it&#39;s a CPFP =
and gets the tx confirmed). Mallory can maximize the cost of replacement ac=
cording to Rule #3 by keeping a low feerate while maximizing the size of th=
e tx.<br></div><div><br></div><div>The higher number of 162sat/vB describes=
 the reasonable upper bound of what Alice should pay to get the transaction=
s confirmed. As in: If Alice pays exactly 162sat/vB * (N + 152vB) satoshis =
to get her tx=20
confirmed, nothing went wrong. She hopes to not pay more than that, but=20
she&#39;ll keep broadcasting higher bumps until it confirms.</div><div><br>=
</div><div>The &quot;damage&quot; of the pin can quantified by the extra fe=
es Alice has to pay.<br></div><div><br></div><div>For a v3 transaction, Mal=
lory can attach 1000vB at 80sat/vB. This can increase the cost of replaceme=
nt to 80,000sat.</div><div>For a non-v3 transaction, Mallory can attach (10=
1KvB - N) before maxing out the descendant limit.</div><div>Rule #4 is pret=
ty negligible here, but since you&#39;ve already specified Alice&#39;s chil=
d as 152vB, she&#39;ll need to pay Rule #3 + 152sats for a replacement.<br>=
</div><div><br></div><div>Let&#39;s say N is 1000vB. AFAIK commitment trans=
actions aren&#39;t usually smaller than this:<br></div><div>- Alice is happ=
y to pay 162sat/vB * (1000 + 152vB) =3D 186,624sat</div><div>- In a v3 worl=
d, Mallory can make the cost to replace 80sat/vB * (1000vB)=C2=A0+ 152 =3D =
80,152sat</div><div>=C2=A0=C2=A0=C2=A0 - Mallory doesn&#39;t succeed, Alice=
&#39;s CPFP easily pays for the replacement</div><div>- In a non-v3 world, =
Mallory can make the cost to replace 80sat/vB * (100,000vB)=C2=A0+ 152 =3D =
8,000,152sat<br></div><div>=C2=A0=C2=A0=C2=A0 - Mallory does succeed, Alice=
 would need to pay <span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos">~7 millio=
n sats extra<br></span></div><div><br></div><div>Let&#39;s say N is 10,000v=
B:</div><div><div>- Alice is happy to pay 162sat/vB * (10,000 + 152vB) =3D =
<span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos">1,644,624</span> </div><div>=
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB)=
=C2=A0+ 152 =3D 80,152sat</div><div>=C2=A0=C2=A0=C2=A0 - Mallory doesn&#39;=
t succeed, Alice&#39;s CPFP easily pays for the replacement<br></div><div>-=
 In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (91,000=
vB)=C2=A0+ 152 =3D 7,280,152sat<br></div><div>=C2=A0=C2=A0=C2=A0 - Mallory =
does succeed Alice would need to pay <span class=3D"gmail-qv3Wpe" id=3D"gma=
il-cwos">~5 million sats extra</span></div><div><br></div><div>Let&#39;s sa=
y N is 50,000vB:</div><div>- Alice is happy to pay 162sat/vB * (50,000 + 15=
2vB) =3D <span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos">8,124,624</span>  <=
/div><div>- In a v3 world, Mallory can make the cost to replace 80sat/vB * =
(1000vB)=C2=A0+ 152 =3D 80,152sat</div><div>=C2=A0=C2=A0=C2=A0 - Mallory do=
esn&#39;t succeed, Alice&#39;s CPFP easily pays for the replacement</div><d=
iv>- In a non-v3 world, Mallory can make the cost to replace 80sat/vB * (51=
,000vB)=C2=A0+ 152 =3D 4,080,152sat<br></div><div>=C2=A0=C2=A0=C2=A0 - Mall=
ory doesn&#39;t succeed, Alice&#39;s CPFP easily pays for the replacement</=
div><div>=C2=A0=C2=A0=C2=A0 - The key idea here is that there isn&#39;t muc=
h room for descendants and the cost to CPFP is very high<br></div><div><br>=
</div></div><div>These numbers change if you tweak more variables - the fee=
s paid by the commitment tx, the feerate range, etc. But the point here is =
to reduce the potential &quot;damage&quot; by 100x by restricting the allow=
ed child size.</div><div><br></div><div>&gt; If V3 children are restricted =
to, say, 200vB, the attack is much less effective<br>
as the ratio of Alice vs Mallory size is so small. <br></div><div><br></div=
><div>This is exactly the idea; note that we&#39;ve come from 100KvB to 100=
0vB.<br></div><div><br></div><div>&gt; Mallory can improve the efficiency o=
f his griefing attack by attacking multiple<br>
&gt; targets at once. Assuming Mallory uses 1 taproot input and 1 taproot o=
utput for<br>
&gt; his own funds, he can spend 21 ephemeral anchors in a single 1000vB<br=
>
&gt; transaction.</div><div><br></div><div>Note that v3 does not allow more=
 than 1 unconfirmed parent per tx.</div><div><br></div><div>Let me know if =
I&#39;ve made an arithmetic error, but hopefully the general idea is clear.=
</div><div><br></div><div>Best,</div><div>Gloria<br></div></div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec=
 20, 2023 at 5:16=E2=80=AFPM Peter Todd via bitcoin-dev &lt;<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">V3 transactions(1) is a set of transaction relay policies intended to a=
im<br>
L2/contracting protocols, namely Lightning. The main aim of V3 transactions=
 is<br>
to solve Rule 3 transaction pinning(2), allowing the use of ephemeral<br>
anchors(3) that do not contain a signature check; anchor outputs that _do_<=
br>
contain a signature check are not vulnerable to pinning attacks, as only th=
e<br>
intended party is able to spend them while unconfirmed.<br>
<br>
The main way that V3 transactions aims to mitigate transaction pinning is w=
ith<br>
the following rule:<br>
<br>
=C2=A0 =C2=A0 A V3 transaction that has an unconfirmed V3 ancestor cannot b=
e larger than<br>
=C2=A0 =C2=A0 1000 virtual bytes.<br>
<br>
Unfortunately, this rule - and thus V3 transactions - is insufficient to<br=
>
substantially mitigate transaction pinning attacks.<br>
<br>
<br>
# The Scenario<br>
<br>
To understand why, let&#39;s consider the following scenario: Alice has a L=
ightning<br>
channel with Bob, who has become unresponsive. Alice is using a Lightning<b=
r>
protocol where using V3 commitment transactions with a single OP_TRUE ephem=
eral<br>
anchor of zero value.=C2=A0 The commitment transaction must be broadcast in=
 a<br>
package, containing both the commitment transaction, and a transaction spen=
ding<br>
the anchor output; regardless of the fee of the commitment transaction, thi=
s is<br>
a hard requirement, as the zero-valued output is considered non-standard by=
 V3<br>
rules unless spent in the same package.<br>
<br>
To pay for the transaction fee of the commitment transaction, Alice spends =
the<br>
ephemeral output in a 2 input, 1 output, taproot transaction of 152vB in si=
ze,<br>
with sufficient feerate Ra to get the transaction mined in what Alice<br>
considers to be a reasonable amount of time.<br>
<br>
<br>
# The Attack<br>
<br>
Enter Mallory. His goal is to grief Alice by forcing her to spend more mone=
y<br>
than she intended, at minimum cost. He also maintains well connected nodes,=
<br>
giving him the opportunity to both learn about new transactions, and quickl=
y<br>
broadcast transactions to a large number of nodes at once.<br>
<br>
When Mallory learns about Alice&#39;s commitment+anchor spend package, he s=
igns a<br>
replacement anchor spend transaction, 1000vB in size, with a lower feerate =
Rm<br>
such that the total fee of Alice&#39;s anchor spend is &lt;=3D Mallory&#39;=
s anchor spend<br>
(in fact, the total fee can be even less due to BIP-125 RBF Rule #4, but fo=
r<br>
sake of a simple argument we&#39;ll ignore this). Next, Mallory broadcast&#=
39;s that<br>
package widely, using his well-connected nodes.<br>
<br>
Due to Rule #3, Alice&#39;s higher feerate transaction package does not rep=
lace<br>
Mallory&#39;s lower fee rate, higher absolute fee, transaction package. Ali=
ce&#39;s<br>
options are now:<br>
<br>
1. Wait for Mallory&#39;s low feerate transaction to be mined (mempool expi=
ration<br>
=C2=A0 =C2=A0does not help here, as Mallory can rebroadcast it indefinitely=
).<br>
2. Hope her transaction got to a miner, and wait for it to get mined.<br>
3. Replace it with an even higher fee transaction, spending at least as muc=
h<br>
=C2=A0 =C2=A0money as Mallory allocated.<br>
<br>
In option #1 and #3, Mallory paid no transaction fees to do the attack.<br>
<br>
Unfortunately for Alice, feerates are often quite stable. For example, as I=
<br>
write this, the feerate required to get into the next block is 162sat/vB, w=
hile<br>
the *lowest* feerate transaction to get mined in the past 24 hours is<br>
approximately 80sat/vB, a difference of just 2x.<br>
<br>
Suppose that in this circumstance Alice needs to get her commitment transac=
tion<br>
mined within 24 hours. If Mallory used a feerate of 1/2.5th that of Alice,<=
br>
Mallory&#39;s transaction would not have gotten mined in the 24 hour period=
, with a<br>
reasonable safety margin. Thus the total fee of Mallory&#39;s package would=
 have<br>
been 6.6 * 1/2.5 =3D 2.6x more than Alice&#39;s total fee, and to get her t=
ransaction<br>
mined prior to her deadline, Alice would have had to pay a 2.6x higher fee =
than<br>
expected.<br>
<br>
<br>
## Multi-Party Attack<br>
<br>
Mallory can improve the efficiency of his griefing attack by attacking mult=
iple<br>
targets at once. Assuming Mallory uses 1 taproot input and 1 taproot output=
 for<br>
his own funds, he can spend 21 ephemeral anchors in a single 1000vB<br>
transaction.<br>
<br>
Provided that the RBF Rule #4 feerate delta is negligible relative to curre=
nt<br>
feerates, Mallory can build up the attack against multiple targets by<br>
broadcasting replacements with slightly higher feerates as needed to add an=
d<br>
remove Alice&#39;s.<br>
<br>
The cost of the attack to Mallory is estimating fees incorrectly, and using=
 a<br>
sufficiently high feerate that his transaction does in fact get mined. In t=
hat<br>
circumstance, if he&#39;s attacking multiple targets, it is likely that all=
 his<br>
transactions would get mined at once. Thus having only a single attack<br>
transaction reduces that worst case cost. Since Mallory can adding and remo=
ve<br>
Alice&#39;s, he can still force multiple Alice&#39;s to spend funds bumping=
 their<br>
transactions.<br>
<br>
<br>
# Solutions<br>
<br>
## Replace-by-Feerate<br>
<br>
Obviously, this attack does not work if Rule #3 is removed for small<br>
transactions, allowing Alice&#39;s transaction to replace Mallory via<br>
replace-by-feerate. In the common situation where mempools are deep, this i=
s<br>
arguably miner incentive compatible as other transactions at essentially th=
e<br>
same feerate will simply replace the &quot;space&quot; taken up by the grie=
fing<br>
transaction.<br>
<br>
<br>
## Restrict V3 Children Even Further<br>
<br>
If V3 children are restricted to, say, 200vB, the attack is much less effec=
tive<br>
as the ratio of Alice vs Mallory size is so small. Of course, this has the<=
br>
disadvantage of making it more difficult in some cases to find sufficient<b=
r>
UTXO&#39;s to pay for fees, and increasing the number of UTXO&#39;s needed =
to fee bump<br>
large numbers of transactions.<br>
<br>
<br>
# References<br>
<br>
1) <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-=
September/020937.html" rel=3D"noreferrer" target=3D"_blank">https://lists.l=
inuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html</a>,<br=
>
=C2=A0 =C2=A0&quot;[bitcoin-dev] New transaction policies (nVersion=3D3) fo=
r contracting protocols&quot;,<br>
=C2=A0 =C2=A0Gloria Zhao, Sep 23 2022<br>
<br>
2) <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0125.mediawik=
i#implementation-details" rel=3D"noreferrer" target=3D"_blank">https://gith=
ub.com/bitcoin/bips/blob/master/bip-0125.mediawiki#implementation-details</=
a>,<br>
=C2=A0 =C2=A0&quot;The replacement transaction pays an absolute fee of at l=
east the sum paid by the original transactions.&quot;<br>
<br>
3) <a href=3D"https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-=
ephemeralanchors.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://gi=
thub.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawi=
ki</a><br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--00000000000072dc68060cf5c763--