public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Greg Sanders <gsanders87@gmail.com>
To: Peter Todd <pete@petertodd.org>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks
Date: Wed, 20 Dec 2023 15:16:25 -0500	[thread overview]
Message-ID: <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com> (raw)
In-Reply-To: <ZYNFK5V5e9PnT9eL@petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 3493 bytes --]

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 honest
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 PM 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 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.
>
> In my experience, only a minority of commitment transactions that get mined
> 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 attacking
> > 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
>

[-- Attachment #2: Type: text/html, Size: 4602 bytes --]

  reply	other threads:[~2023-12-20 20:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-20 17:14 [bitcoin-dev] V3 Transactions are still vulnerable to significant tx pinning griefing attacks Peter Todd
2023-12-20 19:13 ` Gloria Zhao
2023-12-20 19:48   ` Peter Todd
2023-12-20 20:16     ` Greg Sanders [this message]
2023-12-20 21:11       ` Peter Todd
2024-01-02 11:12         ` Gloria Zhao
2024-01-02 23:18           ` Peter Todd
2024-01-02 23:43           ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com \
    --to=gsanders87@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox