public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Gloria Zhao <gloriajzhao@gmail.com>
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
Date: Tue, 2 Jan 2024 23:43:01 +0000	[thread overview]
Message-ID: <ZZSfhQ3KD1uK8T45@petertodd.org> (raw)
In-Reply-To: <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>

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

On Tue, Jan 02, 2024 at 11:12:05AM +0000, Gloria Zhao wrote:
> 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.

<snip, replied to in another email>

> 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=162vB.
> - Alice is happy to pay 162sat/vB * (162 + 152vB) = 50,868sat
> - In a v3 world, Mallory can make the cost to replace 80sat/vB * (1000vB) +
> 152 = 80,152sat
>     - Mallory succeeds, forcing Alice to pay 80,152 - 50,868 = *29,284sat*
> more
> - In a non-v3 world, Mallory can make the cost to replace 80sat/vB *
> (100,000vB) + 152 = 8,000,152sat
>     - Mallory succeeds, forcing Alice to pay 8,000,152 - 50,868 = *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.

Also, you're writeup is still missing a very important point: existing
Lightning anchor channels solved pinning by having a CHECKSIG. Only the parties
with the right to spend the anchor channel can do that, and all other outputs
are unspendable until the commitment transaction confirms.

So the question is not whether or not V3 transactions can improve pinning
compared to a hypothetical protocol with vulnerabilities. The question, for
Lightning, is how much better or worse V3 transactions would be than the status
quo. So far, they look like the difference is marginal at best, quite possibly
worse.

Now, with other protocols, maybe we could make an argument that V3 transactions
is worthwhile and for those protocols no other solution is possible. But you
have not attempted to make that argument in the documentation provided in your
pull-req(s).

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      parent reply	other threads:[~2024-01-02 23:43 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
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 [this message]

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=ZZSfhQ3KD1uK8T45@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gloriajzhao@gmail.com \
    --cc=gsanders87@gmail.com \
    /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