Feedback-ID: i525146e8:Fastmail
Date: Tue, 2 Jan 2024 23:43:01 +0000
From: Peter Todd <pete@petertodd.org>
To: Gloria Zhao <gloriajzhao@gmail.com>
Message-ID: <ZZSfhQ3KD1uK8T45@petertodd.org>
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
 <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
 <ZYNFK5V5e9PnT9eL@petertodd.org>
 <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
 <ZYNYgBovvwodqSuZ@petertodd.org>
 <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="V/rGWnEjcmJbv4Cz"
Content-Disposition: inline
In-Reply-To: <CAFXO6=JuMwFjy-Q9h3U8dTr_4TvDjusFFX6orVhXvCG_G8WbOA@mail.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
Precedence: list


--V/rGWnEjcmJbv4Cz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jan 02, 2024 at 11:12:05AM +0000, Gloria Zhao wrote:
> Hi Peter,
>=20
> > 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.
>=20
> > 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.
>=20
> 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=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,284s=
at*
> 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,94=
9,284sat
> *more (maxed out by the HTLC amount)
>=20
> 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 par=
ties
with the right to spend the anchor channel can do that, and all other outpu=
ts
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 st=
atus
quo. So far, they look like the difference is marginal at best, quite possi=
bly
worse.

Now, with other protocols, maybe we could make an argument that V3 transact=
ions
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 y=
our
pull-req(s).

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

--V/rGWnEjcmJbv4Cz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWUn4MACgkQLly11TVR
LzfAoA//TVf7PNzDxhIYJpL5WefCbdR6/fGxs7qbRsjrnB8b5SMrJtZzcsJ8oW8H
t0d2h/en1n5H9ChtPlXyCNRjWsMAO757iWrt/e+ovN/u2G6/9mPmc/269p2OIXsb
9i5+Wqw9E55Fw2w321YmBBILni/bcFkNDOB/bvzlQD9UC7ccjqs/cdFSty9DWD7d
0rTIt3DqiM8on7DZRSUeVe4n+4F6fj5ZkMrIL89ynGc0G9GYzkW/KaQZbWiWD9uQ
u9TLB/B5bERv6muuhyDBUXledx59+bAAU6wv5K8nj2BANryaBEnuzu0bBQeNcDhl
hklLbajMMZ7SA6p4RNyPmysftELss0HnEEm4xvtmtpLpeCfNR7JBO6pjUhgTyC2A
Wi3jno+mlst2cGdHl3cCHzf7to6UtoK891U15bQdHMtuKg/FLAJchbTa+210gjAE
5LDdOJ6MqgU0DZLWE/riRVP79FBBzNIkcz9WKxKPYBe7n6XOobV8QzhrqEWb0med
HJWxCz6hGrTBn5uzjF/UbqvrEK4xrhdG9RT3VYSCJbWDrTUvqbT2L+3ljcD7Sw2s
PCDnUCNrZaRibpTbiJ583V/8VBd+P2pcT0NOp9hOvRHzye/HCCHe6aLH50G5Upg8
O3Wts2tIwGY9Z8zE26kB/pm4q1a5OKiJSwEMYckEAy2d0argxZE=
=65O9
-----END PGP SIGNATURE-----

--V/rGWnEjcmJbv4Cz--