From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id D4994C0037 for ; 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 ; 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 ; 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 ; 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 ; 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: In-Reply-To: From: Gloria Zhao Date: Tue, 2 Jan 2024 11:12:05 +0000 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="0000000000004f1eaf060df49246" X-Mailman-Approved-At: Tue, 02 Jan 2024 11:37:12 +0000 Cc: Bitcoin Protocol Discussion , Greg Sanders 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi Peter,

> You make a go= od 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 w= ould have
> a single-sig input (musig), two taproot outputs, and an ephemeral anch= or
> output.=C2=A0 Such a transaction is only 162vB, much less than 1000vB.=

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

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

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.
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= )=C2=A0+ 152 =3D 80,152sat
=C2=A0=C2=A0=C2=A0 - Mallory succeeds,= forcing Alice to pay 80,152 - 50,868 =3D 29,284sat more
- In a non-v3 wo= rld, Mallory can make the cost to replace 80sat/vB * (100,000vB)=C2=A0+ 152= =3D 8,000,152sat
=C2=A0=C2=A0=C2=A0 - Mallory succeeds, forc= ing Alice to pay 8,000,152 - 50,868 =3D 7,949,284sat more (maxed out by the HTLC amount)

As framed above, wha= t 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 r= estricted by 100x, as claimed.

Best,
Gloria

On Wed, Dec 20, 2023 at 9:11=E2=80=AFPM Peter Todd <pete@petertodd.org> wrote:
On Wed, Dec 20, 2023 a= t 03:16:25PM -0500, Greg Sanders wrote:
> Hi Peter,
>
> Thanks for taking the time to understand the proposal and give thought= ful
> feedback.
>
> With this kind of "static" approach I think there are fundam= ental
> limitations because
> the user has to commit "up front" how large the CPFP later w= ill 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<= br> > 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 t= hat is
barely worth its own fees to spend, one or maybe two UTXOs are going to be<= br> sufficient for a fee payment.

I had incorrectly thought that V3 transctions allowed for a single up-to 10= 00vB
transaction to pay for multiple parents at once. But if you can't do th= at, due
to the restriction on unconfirmed inputs, I can't see any reason to hav= e such a
large limit.

> I'd like something much more flexible, but we're barely at whi= teboard stage
> for alternatives and
> they probably require more fundamental work. So within these limits, w= e
> 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 siz= e. If the honest
> user does relatively poor utxo management, or the commitment transacti= on
> 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&quo= t; 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= status
> quo which is ~500-1000x+.

No, the status quo is signed anchors, like Lightning already has with ancho= r
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 int= ended
party can spend them.

Note BTW that existing Lightning anchor channels inefficiently use two anch= or
outputs when just one is sufficient:

=C2=A0 =C2=A0 htt= ps://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246= .html
=C2=A0 =C2=A0 [Lightning-dev] The remote anchor of anchor channels is redun= dant
=C2=A0 =C2=A0 Peter Todd, Dec 13th, 2023

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--0000000000004f1eaf060df49246--