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:18:11 +0000 [thread overview]
Message-ID: <ZZSZs16f1q6i3oLV@petertodd.org> (raw)
In-Reply-To: <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1752 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.
What scenarios you consider "interesting" is not relevant. You can't pick an
arbitrary minimum based on an interesting scenario. You should pick an actual
relevant minimum.
So with that in mind, let's ask the question: Do we think it's common for
channels to be force closed without HTLCs pending? I believe the answer is
likely to be yes, because channels are only used some of the time.
Can we verify that? Well, I just checked my node, and out of the past 15 force
closes, 12 had no HTLCs outstanding. 2 had one HTLC outstanding, and 1 had 2
HTLCs.
I also checked a big node I'm connected to, fixedfloat. Again, out of the past
15 force closes, 11 had no HTLCs outstanding, with 4 having 1 HTLC
outstanding... but of those only 2 HTLCs were profitable to collect. The other
half cost more money in fees than the HTLC value.
Looks to me like the supermajority of force closes are the most boring type.
And those numbers would be even more tilted in that direction if Lightning
implementations had better economics management.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-01-02 23:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-20 17:14 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 [this message]
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=ZZSZs16f1q6i3oLV@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gloriajzhao@gmail$(echo .)com \
--cc=gsanders87@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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