summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGreg Sanders <gsanders87@gmail.com>2023-12-20 15:16:25 -0500
committerbitcoindev <bitcoindev@gnusha.org>2023-12-20 20:16:40 +0000
commitd52e2f0f3b74f00ac2584405942f11ec71838a83 (patch)
tree78c1f9752e2ae7b6b57f29bdd5db13274cc42985
parent2e7d3dd8d37d30ae19f67e8883156c2fbc220933 (diff)
downloadpi-bitcoindev-d52e2f0f3b74f00ac2584405942f11ec71838a83.tar.gz
pi-bitcoindev-d52e2f0f3b74f00ac2584405942f11ec71838a83.zip
Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
-rw-r--r--d8/22bd0d91db7f92039566f3f1e3ba4bb3424495299
1 files changed, 299 insertions, 0 deletions
diff --git a/d8/22bd0d91db7f92039566f3f1e3ba4bb3424495 b/d8/22bd0d91db7f92039566f3f1e3ba4bb3424495
new file mode 100644
index 000000000..67bea72b5
--- /dev/null
+++ b/d8/22bd0d91db7f92039566f3f1e3ba4bb3424495
@@ -0,0 +1,299 @@
+Return-Path: <gsanders87@gmail.com>
+Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
+ by lists.linuxfoundation.org (Postfix) with ESMTP id E48F7C0037
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 20 Dec 2023 20:16:40 +0000 (UTC)
+Received: from localhost (localhost [127.0.0.1])
+ by smtp1.osuosl.org (Postfix) with ESMTP id B1F59834C6
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 20 Dec 2023 20:16:40 +0000 (UTC)
+DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B1F59834C6
+Authentication-Results: smtp1.osuosl.org;
+ dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
+ header.a=rsa-sha256 header.s=20230601 header.b=Tc9EFPm0
+X-Virus-Scanned: amavisd-new at osuosl.org
+X-Spam-Flag: NO
+X-Spam-Score: -1.848
+X-Spam-Level:
+X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp1.osuosl.org ([127.0.0.1])
+ by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
+ with ESMTP id 2RXGZn12hlAd
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 20 Dec 2023 20:16:39 +0000 (UTC)
+Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com
+ [IPv6:2a00:1450:4864:20::136])
+ by smtp1.osuosl.org (Postfix) with ESMTPS id 39C2A83455
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 20 Dec 2023 20:16:39 +0000 (UTC)
+DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 39C2A83455
+Received: by mail-lf1-x136.google.com with SMTP id
+ 2adb3069b0e04-50e2d00f99cso133303e87.0
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Wed, 20 Dec 2023 12:16:39 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=gmail.com; s=20230601; t=1703103397; x=1703708197;
+ darn=lists.linuxfoundation.org;
+ h=cc:to:subject:message-id:date:from:in-reply-to:references
+ :mime-version:from:to:cc:subject:date:message-id:reply-to;
+ bh=UD4gYWm5fxLJnhfkzifQO/2os2f5IMfW5I2dJxEiJho=;
+ b=Tc9EFPm0GPTh6uxa/a+AXDSpjne9Nwna1O6KobihJouJzCSjMLfov2rA6ToR4E3asL
+ HB4spm1LIAQK4EiFKSds5a2BLixpzM6USSuz7uJ7ulMIsw0ya7HgNAZ+lMm5SBIodnSp
+ 6T7ROnAx9x2hgoZP+JaeayiDtgD7EMFL3Ka5Mkq/NVEmAoUBdEAXuN0dO0bBJH/RRCDU
+ SXSV9JuchoasZ/16SGhKnJm4Dy6oq+nydfAvYaRpvtsfsTc71zctUA5jfCYFagyJPc+W
+ VjLhxIhW3ULt8WodieSQtYuQK90D9e9lN2DS/bAUOHmI9ToZeTFxhjalBLP1ATOWSUQD
+ Ty+A==
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+ d=1e100.net; s=20230601; t=1703103397; x=1703708197;
+ h=cc: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=UD4gYWm5fxLJnhfkzifQO/2os2f5IMfW5I2dJxEiJho=;
+ b=NFNITIMvKCt6M32fXrKeXICmcTrT8YOR7EcYwMlIJzgJrPhUYwBNYCP1Og0WBqT1A4
+ fa7MUuKC8ZRISPDsuoALRTi0p0c0fRuErM2VWZq1i3hXXvC1D9fKQEnf9qu6ZHpOAiMO
+ jxYcZG7BeY+3/lUI9hkR0PkNDZoP52I+BG2kLHeSh4OsA2y5BkJwbCwtVqSlPl58Qx5q
+ bt5LmECY+T/NsxuXR8ezD+0sUv8Z+cGHItoo3aqDIwEpe6hvvc7BdR6vLU4i2wmUA5ah
+ wkbCjobgFl3T07G+W69qSPmPSwxYTRp0qL0DpCDT3s5KiBGDdI0D5sgpakuCRu10Pm/2
+ wYqQ==
+X-Gm-Message-State: AOJu0YxxDC+CnGfSGa6pSVSGzbJuK2usKNZf+aFQitBkvpPBoXjX8nYo
+ Qi8xGQLsC5XJa8lyPeMz2bqr+TM1coXfu5DR/Xw=
+X-Google-Smtp-Source: AGHT+IHYWowH7TOc5g2Vyg+5xucCotg3kyQ9XC/bzxXvOnrt94MW/FDUyYZZiNglb9mHPImgzoV2XJJfDQT8bgIMzB0=
+X-Received: by 2002:a05:6512:33c8:b0:50b:e08a:4d00 with SMTP id
+ d8-20020a05651233c800b0050be08a4d00mr12709788lfg.84.1703103396534; Wed, 20
+ Dec 2023 12:16:36 -0800 (PST)
+MIME-Version: 1.0
+References: <ZYMhEJ3y11tnDOAx@petertodd.org>
+ <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
+ <ZYNFK5V5e9PnT9eL@petertodd.org>
+In-Reply-To: <ZYNFK5V5e9PnT9eL@petertodd.org>
+From: Greg Sanders <gsanders87@gmail.com>
+Date: Wed, 20 Dec 2023 15:16:25 -0500
+Message-ID: <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
+To: Peter Todd <pete@petertodd.org>,
+ Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
+Content-Type: multipart/alternative; boundary="000000000000f75db9060cf6a882"
+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 20:16:41 -0000
+
+--000000000000f75db9060cf6a882
+Content-Type: text/plain; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+Hi Peter,
+
+Thanks for taking the time to understand the proposal and give thoughtful
+feedback.
+
+With this kind of "static" approach I think there are fundamental
+limitations because
+the user has to commit "up front" how large the CPFP later will have to be.
+1kvB
+is an arbitrary value that is two orders of magnitude less than the
+possible package
+size, and allows fairly flexible amounts of inputs(~14 taproot inputs
+IIRC?) to effectuate a CPFP.
+I'd like something much more flexible, but we're barely at whiteboard stage
+for alternatives and
+they probably require more fundamental work. So within these limits, we
+have to pick some number,
+and it'll have tradeoffs.
+
+When I think of "pinning potential", I consider not only the parent size,
+and not
+only the maximum child size, but also the "honest" child size. If the hones=
+t
+user does relatively poor utxo management, or the commitment transaction
+is of very high value(e.g., lots of high value HTLCs), the pin is
+essentially zero.
+If the honest user ever only have one utxo, then the "max pin" is effective
+indeed.
+
+> Alice would have had to pay a 2.6x higher fee than
+expected.
+
+I think that's an acceptable worst case starting point, versus the status
+quo which is ~500-1000x+.
+Not great, not terrible.
+
+Cheers,
+Greg
+
+
+On Wed, Dec 20, 2023 at 2:49=E2=80=AFPM Peter Todd via bitcoin-dev <
+bitcoin-dev@lists.linuxfoundation.org> wrote:
+
+> On Wed, Dec 20, 2023 at 07:13:22PM +0000, Gloria Zhao wrote:
+> > 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:
+>
+> You make a good point that the commitment transaction also needs to be
+> included
+> in my calculations. But you are incorrect about the size of them.
+>
+> With taproot and ephemeral anchors, a typical commitment transaction woul=
+d
+> have
+> a single-sig input (musig), two taproot outputs, and an ephemeral anchor
+> output. Such a transaction is only 162vB, much less than 1000vB.
+>
+> In my experience, only a minority of commitment transactions that get min=
+ed
+> have HTLCs outstanding; even if there is an HTLC outstanding, that only
+> gets us
+> up to 206vB.
+>
+> > > Mallory can improve the efficiency of his griefing attack by attackin=
+g
+> > 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.
+>
+> Ah, pity, I had misremembered that restriction as being removed, as that
+> is a
+> potentially significant improvement in scenarios where you need to do
+> things
+> like deal with a bunch of force closes at once.
+>
+> --
+> https://petertodd.org 'peter'[:-1]@petertodd.org
+> _______________________________________________
+> bitcoin-dev mailing list
+> bitcoin-dev@lists.linuxfoundation.org
+> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
+>
+
+--000000000000f75db9060cf6a882
+Content-Type: text/html; charset="UTF-8"
+Content-Transfer-Encoding: quoted-printable
+
+<div dir=3D"ltr">Hi Peter,<div><br></div><div>Thanks for taking the time to=
+ understand the proposal and give thoughtful feedback.</div><div><br></div>=
+<div>With this kind of &quot;static&quot; approach I think there are fundam=
+ental limitations because</div><div>the user has to commit &quot;up front&q=
+uot; how large the CPFP later will have to be. 1kvB</div><div>is an arbitra=
+ry=C2=A0value that is two orders of magnitude less than the possible packag=
+e</div><div>size, and allows fairly flexible amounts of inputs(~14 taproot =
+inputs IIRC?) to effectuate a CPFP.</div><div>I&#39;d like something much m=
+ore flexible, but we&#39;re barely at whiteboard=C2=A0stage for alternative=
+s and=C2=A0</div><div>they probably require more fundamental work. So withi=
+n these limits, we have to pick some number,</div><div>and it&#39;ll have t=
+radeoffs.</div><div><br></div><div>When I think of &quot;pinning potential&=
+quot;, I consider not only the parent size, and not</div><div>only the maxi=
+mum child size, but also the &quot;honest&quot; child size. If the honest</=
+div><div>user does relatively poor utxo management, or the commitment trans=
+action</div><div>is of=C2=A0very high value(e.g., lots of high value HTLCs)=
+, the pin is essentially zero.</div><div>If the honest user ever only have =
+one utxo, then the &quot;max pin&quot; is effective indeed.</div><div><br><=
+/div><div>&gt; Alice would have had to pay a 2.6x higher fee than</div>expe=
+cted.<div><br></div><div>I think that&#39;s an acceptable worst case starti=
+ng point, versus the status quo which is ~500-1000x+.</div><div>Not great, =
+not terrible.</div><div><br></div><div>Cheers,</div><div>Greg</div><div><br=
+></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
+_attr">On Wed, Dec 20, 2023 at 2:49=E2=80=AFPM Peter Todd via bitcoin-dev &=
+lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
+ts.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_q=
+uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
+04);padding-left:1ex">On Wed, Dec 20, 2023 at 07:13:22PM +0000, Gloria Zhao=
+ wrote:<br>
+&gt; The &quot;damage&quot; of the pin can quantified by the extra fees Ali=
+ce has to pay.<br>
+&gt; <br>
+&gt; For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can<=
+br>
+&gt; increase the cost of replacement to 80,000sat.<br>
+&gt; For a non-v3 transaction, Mallory can attach (101KvB - N) before maxin=
+g out<br>
+&gt; the descendant limit.<br>
+&gt; Rule #4 is pretty negligible here, but since you&#39;ve already specif=
+ied<br>
+&gt; Alice&#39;s child as 152vB, she&#39;ll need to pay Rule #3 + 152sats f=
+or a<br>
+&gt; replacement.<br>
+&gt; <br>
+&gt; Let&#39;s say N is 1000vB. AFAIK commitment transactions aren&#39;t us=
+ually smaller<br>
+&gt; than this:<br>
+<br>
+You make a good point that the commitment transaction also needs to be incl=
+uded<br>
+in my calculations. But you are incorrect about the size of them.<br>
+<br>
+With taproot and ephemeral anchors, a typical commitment transaction would =
+have<br>
+a single-sig input (musig), two taproot outputs, and an ephemeral anchor<br=
+>
+output.=C2=A0 Such a transaction is only 162vB, much less than 1000vB.<br>
+<br>
+In my experience, only a minority of commitment transactions that get mined=
+<br>
+have HTLCs outstanding; even if there is an HTLC outstanding, that only get=
+s us<br>
+up to 206vB.<br>
+<br>
+&gt; &gt; Mallory can improve the efficiency of his griefing attack by atta=
+cking<br>
+&gt; multiple<br>
+&gt; &gt; targets at once. Assuming Mallory uses 1 taproot input and 1 tapr=
+oot<br>
+&gt; output for<br>
+&gt; &gt; his own funds, he can spend 21 ephemeral anchors in a single 1000=
+vB<br>
+&gt; &gt; transaction.<br>
+&gt; <br>
+&gt; Note that v3 does not allow more than 1 unconfirmed parent per tx.<br>
+<br>
+Ah, pity, I had misremembered that restriction as being removed, as that is=
+ a<br>
+potentially significant improvement in scenarios where you need to do thing=
+s<br>
+like deal with a bunch of force closes at once.<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>
+
+--000000000000f75db9060cf6a882--
+