path: root/d8/22bd0d91db7f92039566f3f1e3ba4bb3424495

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--