path: root/d7/ff4ec8716d11b528ddcf63782fafb04fcf1c24

Return-Path: <gloriajzhao@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D4994C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 11:12:20 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id AA41E60C33
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 11:12:20 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org AA41E60C33
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20230601 header.b=RmfFT634
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id rP_DMEfOpHRb
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 11:12:19 +0000 (UTC)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com
 [IPv6:2607:f8b0:4864:20::d31])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 44ADD60BCE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  2 Jan 2024 11:12:19 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 44ADD60BCE
Received: by mail-io1-xd31.google.com with SMTP id
 ca18e2360f4ac-7bae735875bso436661439f.2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 02 Jan 2024 03:12:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1704193938; x=1704798738;
 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=cakYKAXWIw6SOMSckFeH7k/oOQ2qQLilAlVeBtvYwHs=;
 b=RmfFT634EWd5xAGqpedWgPFy5e9+A4nVPIZjPSDZhg1nuG+2W3GF7SwWRpbRxagqHg
 xCp6SMmw5aM8CLoPdgyWQoCftbDBlLNTVgIfw3ahLsufXocsxGyvkgzj4Yz6GYsKiYcB
 HghML+XZYQG24Z6RZ5aCRCCoowwrGQxSxSIfVj+u+qF7VejVOPTOjaPnPgAayU1UFaun
 qKJbfaSxkbQQDJdhIHIDe+FyXkP4Y7E4JgNy2U8jJHdBprD0PibMO+IG4s58Hfdm3kgm
 APj3UiwGiPRfA+wL1pTdSXx8qRA0ODj1OyfoLyjWsVpeZExydFm/O0wnXb+oaRTWeAN4
 6N0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1704193938; x=1704798738;
 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=cakYKAXWIw6SOMSckFeH7k/oOQ2qQLilAlVeBtvYwHs=;
 b=KzqIthVwVKiya5ZmLhGrzJhPHLU8RtKhuHXv4k6ZFotAFoJ0pGLiU0OegSNt1H3ssE
 OaP4JvZep3DGoom1Ho4PKJPEqlw70H90MZTrLzxjsov+fiks56XPs5ymAaRp0R9AbIh/
 YCIdNVCV4nu2I1ZjBAotVlTZERYYiz2+gCGVYnNelazl+vuphzgMUp16kVWCicSM/ZEh
 RQ5GYGw/zCdvi01pNbSBBnOCeGtUp0eLrVYtPIYY2KOVovhZ5huPE7hmfebvE8NzR5T4
 QKGd/O6FgVNWM6xqeU3+cbKBH4v8ZtkCbemKiknAYfJuEyeVM3KL507CuuOHU1wvIJpf
 AYdQ==
X-Gm-Message-State: AOJu0YznwiN3C8BiTkmARJuz0sEG+rt0GYqptraJiff5BZHEgMdvM0Dy
 EFT9XmhZZFcxpHGLw6Lj01rVESuLPquJz2T4lWE=
X-Google-Smtp-Source: AGHT+IH7pjet03OQN+C6CTUWtrZxIWj6aAkJRyhqLmC/jn4Ws86UFFTwpXprtHuJQKzNza3IN5meBuXWsY0LAR00uD4=
X-Received: by 2002:a05:6e02:1562:b0:35f:fa5a:d58d with SMTP id
 k2-20020a056e02156200b0035ffa5ad58dmr18783343ilu.28.1704193938102; Tue, 02
 Jan 2024 03:12:18 -0800 (PST)
MIME-Version: 1.0
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
 <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
 <ZYNFK5V5e9PnT9eL@petertodd.org>
 <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
 <ZYNYgBovvwodqSuZ@petertodd.org>
In-Reply-To: <ZYNYgBovvwodqSuZ@petertodd.org>
From: Gloria Zhao <gloriajzhao@gmail.com>
Date: Tue, 2 Jan 2024 11:12:05 +0000
Message-ID: <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="0000000000004f1eaf060df49246"
X-Mailman-Approved-At: Tue, 02 Jan 2024 11:37:12 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Greg Sanders <gsanders87@gmail.com>
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: Tue, 02 Jan 2024 11:12:20 -0000

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

Hi Peter,

> 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
would have
> a single-sig input (musig), two taproot outputs, and an ephemeral anchor
> output.  Such a transaction is only 162vB, much less than 1000vB.

Note that these scenarios are much less interesting for commitment
transactions with no HTLC outputs, so 162 isn't what I would use for the
minimum.

Looking at expected weights in bolt 3 (
https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-=
weight-of-the-commitment-transaction)
with 1 HTLC and anchors, we get (900 + 172 * num-htlc-outputs + 224
weight)/4 =3D 324vB.

So, I apologize for not using a more accurate minimum, though I think this
helps illustrate the 100x reduction of v3 a lot better.
While I think the true minimum is higher, let's go ahead and use your
number N=3D162vB.
- Alice is happy to pay 162sat/vB * (162 + 152vB) =3D 50,868sat
- In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
152 =3D 80,152sat
    - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 =3D *29,284sat=
*
more
- In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
(100,000vB) + 152 =3D 8,000,152sat
    - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 =3D *7,949,=
284sat
*more (maxed out by the HTLC amount)

As framed above, what we've done here is quantify the severity of the
pinning damage in the v3 and non-v3 world by calculating the additional
fees Mallory can force Alice to pay using Rule 3. To summarize this
discussion, at the lower end of possible commitment transaction sizes,
pinning is possible but is restricted by 100x, as claimed.

Best,
Gloria

On Wed, Dec 20, 2023 at 9:11=E2=80=AFPM Peter Todd <pete@petertodd.org> wro=
te:

> On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote:
> > Hi Peter,
> >
> > Thanks for taking the time to understand the proposal and give thoughtf=
ul
> > 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.
>
> Why would you need so many inputs to do a CPFP if they all have to be
> confirmed? The purpose of doing a CPFP is to pay fees to get another
> transaction mined. Unless you're in some degenerate, unusual, situation
> where
> you've somehow ended up with just some dust left in your wallet, dust tha=
t
> is
> barely worth its own fees to spend, one or maybe two UTXOs are going to b=
e
> sufficient for a fee payment.
>
> I had incorrectly thought that V3 transctions allowed for a single up-to
> 1000vB
> transaction to pay for multiple parents at once. But if you can't do that=
,
> due
> to the restriction on unconfirmed inputs, I can't see any reason to have
> such a
> large limit.
>
> > 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 siz=
e,
> > and not
> > only the maximum child size, but also the "honest" child size. If the
> honest
> > user does relatively poor utxo management, or the commitment transactio=
n
> > 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.
>
> Which is the situation you would expect in the vast majority of cases.
>
> > > 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 stat=
us
> > quo which is ~500-1000x+.
>
> No, the status quo is signed anchors, like Lightning already has with
> anchor
> channels. Those anchors could still be zero-valued. But as long as there
> is a
> signature associated with them, pinning isn't a problem as only the
> intended
> party can spend them.
>
> Note BTW that existing Lightning anchor channels inefficiently use two
> anchor
> outputs when just one is sufficient:
>
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/0=
04246.html
>     [Lightning-dev] The remote anchor of anchor channels is redundant
>     Peter Todd, Dec 13th, 2023
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

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

<div dir=3D"ltr"><div>Hi Peter,</div><div><br></div><div>&gt; You make a go=
od point that the commitment transaction also needs to be included<br>
&gt; in my calculations. But you are incorrect about the size of them.<br>
<br>
&gt; With taproot and ephemeral anchors, a typical commitment transaction w=
ould have<br>
&gt; a single-sig input (musig), two taproot outputs, and an ephemeral anch=
or<br>
&gt; output.=C2=A0 Such a transaction is only 162vB, much less than 1000vB.=
</div><div><br></div><div>Note that these scenarios are much less interesti=
ng for commitment transactions with no HTLC outputs, so 162 isn&#39;t what =
I would use for the minimum.</div><div><br></div><div>Looking at expected w=
eights in bolt 3 (<a href=3D"https://github.com/lightning/bolts/blob/master=
/03-transactions.md#expected-weight-of-the-commitment-transaction">https://=
github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-o=
f-the-commitment-transaction</a>) with 1 HTLC and anchors, we get (900 + 17=
2 * num-htlc-outputs + 224 weight)/4 =3D 324vB.</div><div><br></div><div>So=
, I apologize for not using a more accurate minimum, though I think this he=
lps illustrate the 100x reduction of v3 a lot better.<br></div><div>While I=
 think the true minimum is higher, let&#39;s go ahead and use your number N=
=3D162vB.<br></div><div>- Alice is happy to pay 162sat/vB * (162 + 152vB) =
=3D <span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos">50,868sat</span></div><d=
iv>- 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 succeeds,=
 forcing Alice to pay 80,152 - 50,868 =3D <span class=3D"gmail-qv3Wpe" id=
=3D"gmail-cwos"><b>29,284sat</b> more<br></span></div><div>- In a non-v3 wo=
rld, 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 succeeds, forc=
ing Alice to pay 8,000,152 - 50,868 =3D <span class=3D"gmail-qv3Wpe" id=3D"=
gmail-cwos"><b>7,949,284sat </b>more (maxed out by the HTLC amount)<br></sp=
an></div><div><span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos"><br></span></d=
iv><div><span class=3D"gmail-qv3Wpe" id=3D"gmail-cwos">As framed above, wha=
t we&#39;ve done here is quantify</span> the severity of the pinning damage=
 in the v3 and non-v3 world by calculating the additional fees Mallory can =
force Alice to pay using Rule 3. To summarize this discussion, at the lower=
 end of possible commitment transaction sizes, pinning is possible but is r=
estricted by 100x, as claimed.<br></div><div><br></div><div>Best,</div><div=
>Gloria<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Wed, Dec 20, 2023 at 9:11=E2=80=AFPM Peter Todd &lt;<a =
href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Dec 20, 2023 a=
t 03:16:25PM -0500, Greg Sanders wrote:<br>
&gt; Hi Peter,<br>
&gt; <br>
&gt; Thanks for taking the time to understand the proposal and give thought=
ful<br>
&gt; feedback.<br>
&gt; <br>
&gt; With this kind of &quot;static&quot; approach I think there are fundam=
ental<br>
&gt; limitations because<br>
&gt; the user has to commit &quot;up front&quot; how large the CPFP later w=
ill have to be.<br>
&gt; 1kvB<br>
&gt; is an arbitrary value that is two orders of magnitude less than the<br=
>
&gt; possible package<br>
&gt; size, and allows fairly flexible amounts of inputs(~14 taproot inputs<=
br>
&gt; IIRC?) to effectuate a CPFP.<br>
<br>
Why would you need so many inputs to do a CPFP if they all have to be<br>
confirmed? The purpose of doing a CPFP is to pay fees to get another<br>
transaction mined. Unless you&#39;re in some degenerate, unusual, situation=
 where<br>
you&#39;ve somehow ended up with just some dust left in your wallet, dust t=
hat is<br>
barely worth its own fees to spend, one or maybe two UTXOs are going to be<=
br>
sufficient for a fee payment.<br>
<br>
I had incorrectly thought that V3 transctions allowed for a single up-to 10=
00vB<br>
transaction to pay for multiple parents at once. But if you can&#39;t do th=
at, due<br>
to the restriction on unconfirmed inputs, I can&#39;t see any reason to hav=
e such a<br>
large limit.<br>
<br>
&gt; I&#39;d like something much more flexible, but we&#39;re barely at whi=
teboard stage<br>
&gt; for alternatives and<br>
&gt; they probably require more fundamental work. So within these limits, w=
e<br>
&gt; have to pick some number,<br>
&gt; and it&#39;ll have tradeoffs.<br>
&gt; <br>
&gt; When I think of &quot;pinning potential&quot;, I consider not only the=
 parent size,<br>
&gt; and not<br>
&gt; only the maximum child size, but also the &quot;honest&quot; child siz=
e. If the honest<br>
&gt; user does relatively poor utxo management, or the commitment transacti=
on<br>
&gt; is of very high value(e.g., lots of high value HTLCs), the pin is<br>
&gt; essentially zero.<br>
&gt; If the honest user ever only have one utxo, then the &quot;max pin&quo=
t; is effective<br>
&gt; indeed.<br>
<br>
Which is the situation you would expect in the vast majority of cases.<br>
<br>
&gt; &gt; Alice would have had to pay a 2.6x higher fee than<br>
&gt; expected.<br>
&gt; <br>
&gt; I think that&#39;s an acceptable worst case starting point, versus the=
 status<br>
&gt; quo which is ~500-1000x+.<br>
<br>
No, the status quo is signed anchors, like Lightning already has with ancho=
r<br>
channels. Those anchors could still be zero-valued. But as long as there is=
 a<br>
signature associated with them, pinning isn&#39;t a problem as only the int=
ended<br>
party can spend them.<br>
<br>
Note BTW that existing Lightning anchor channels inefficiently use two anch=
or<br>
outputs when just one is sufficient:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/pipermail/lightn=
ing-dev/2023-December/004246.html" rel=3D"noreferrer" target=3D"_blank">htt=
ps://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246=
.html</a><br>
=C2=A0 =C2=A0 [Lightning-dev] The remote anchor of anchor channels is redun=
dant<br>
=C2=A0 =C2=A0 Peter Todd, Dec 13th, 2023<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>
</blockquote></div>

--0000000000004f1eaf060df49246--