diff options
author | Greg Sanders <gsanders87@gmail.com> | 2023-12-20 15:16:25 -0500 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2023-12-20 20:16:40 +0000 |
commit | d52e2f0f3b74f00ac2584405942f11ec71838a83 (patch) | |
tree | 78c1f9752e2ae7b6b57f29bdd5db13274cc42985 | |
parent | 2e7d3dd8d37d30ae19f67e8883156c2fbc220933 (diff) | |
download | pi-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/22bd0d91db7f92039566f3f1e3ba4bb3424495 | 299 |
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 "static" approach I think there are fundam= +ental limitations because</div><div>the user has to commit "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'd like something much m= +ore flexible, but we'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'll have t= +radeoffs.</div><div><br></div><div>When I think of "pinning potential&= +quot;, I consider not only the parent size, and not</div><div>only the maxi= +mum child size, but also the "honest" 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 "max pin" is effective indeed.</div><div><br><= +/div><div>> Alice would have had to pay a 2.6x higher fee than</div>expe= +cted.<div><br></div><div>I think that'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>> 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> +> The "damage" of the pin can quantified by the extra fees Ali= +ce has to pay.<br> +> <br> +> For a v3 transaction, Mallory can attach 1000vB at 80sat/vB. This can<= +br> +> increase the cost of replacement to 80,000sat.<br> +> For a non-v3 transaction, Mallory can attach (101KvB - N) before maxin= +g out<br> +> the descendant limit.<br> +> Rule #4 is pretty negligible here, but since you've already specif= +ied<br> +> Alice's child as 152vB, she'll need to pay Rule #3 + 152sats f= +or a<br> +> replacement.<br> +> <br> +> Let's say N is 1000vB. AFAIK commitment transactions aren't us= +ually smaller<br> +> 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> +> > Mallory can improve the efficiency of his griefing attack by atta= +cking<br> +> multiple<br> +> > targets at once. Assuming Mallory uses 1 taproot input and 1 tapr= +oot<br> +> output for<br> +> > his own funds, he can spend 21 ephemeral anchors in a single 1000= +vB<br> +> > transaction.<br> +> <br> +> 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> 'peter'[:-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-- + |