Feedback-ID: i525146e8:Fastmail
Date: Wed, 20 Dec 2023 21:11:28 +0000
From: Peter Todd <pete@petertodd.org>
To: Greg Sanders <gsanders87@gmail.com>
Message-ID: <ZYNYgBovvwodqSuZ@petertodd.org>
References: <ZYMhEJ3y11tnDOAx@petertodd.org>
 <CAFXO6=KS05So_5FizLJxCLEPwBxNPV9Wrgi=9sjzmrZ+PLpLOQ@mail.gmail.com>
 <ZYNFK5V5e9PnT9eL@petertodd.org>
 <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="q0iLX+HWYyGFjg7I"
Content-Disposition: inline
In-Reply-To: <CAB3F3DuKxw_osQcW++GeasGVEedcZ16inqrQPoAWQiF4HsGbdw@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] V3 Transactions are still vulnerable to
 significant tx pinning griefing attacks
Precedence: list


--q0iLX+HWYyGFjg7I
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 20, 2023 at 03:16:25PM -0500, Greg Sanders wrote:
> Hi Peter,
>=20
> Thanks for taking the time to understand the proposal and give thoughtful
> feedback.
>=20
> 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 b=
e.
> 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 whe=
re
you've somehow ended up with just some dust left in your wallet, dust that =
is
barely worth its own fees to spend, one or maybe two UTXOs are going to be
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 that, =
due
to the restriction on unconfirmed inputs, I can't see any reason to have su=
ch a
large limit.

> I'd like something much more flexible, but we're barely at whiteboard sta=
ge
> for alternatives and
> they probably require more fundamental work. So within these limits, we
> have to pick some number,
> and it'll have tradeoffs.
>=20
> 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 hon=
est
> 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 effecti=
ve
> 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.
>=20
> 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 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 anch=
or
outputs when just one is sufficient:

    https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December=
/004246.html
    [Lightning-dev] The remote anchor of anchor channels is redundant
    Peter Todd, Dec 13th, 2023

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

--q0iLX+HWYyGFjg7I
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmWDWH4ACgkQLly11TVR
Lzec0g/6AxYkVbsqn4ggDFJaf9cjNDMK0CSImUbZGis+enzrLEOSOzXQanW4Z3xG
A5oMLhXiDdZEiBDLbppbRwhahLMZ2OFkZ4ZQtsSIO0hgzYeljz4vbuKC3i5jtu84
OBz3m+TqvuIiPUwVmB7pKd77okPsDMdy8EN5f10rr+YT7RZgiYiOr8IRQiKL+EVg
O8Po0ms7WrLz6W0C8s0zNDGgOEeKVUjPhSEWracaHCASioptvTeH8UWnMsxwqlin
2YNKSp5DFvokLPNWpCU9uOCmuQPk6pc8Hn/CpPOuz18qPouoIUjkpyF3Erx+kFaD
ryIl4rjzSIWJuTxPGrXlMoxEG88SZboLKDmHTBOBwYh1OykpXzgjJG+hLsSkH9gG
mgjMdal4eFOQiqQQObEnu0mhQQl44hkqOtsD5JFHT53ruY/4bbV/kL9CEyghVwGC
mx+Gn4D55k8zgvF1ACwtTZLI63McAI9IT8Tn3F6IkvTsCLIFOhVMA+HwEx4WMpy4
/+f5Oi+xAzpCfUltTyZhEyHp+G5+g/5xffrrgD4mBpgaML6i7lZkIYVfmipCNO8z
4ljZnCCme/xXF0GZUV2l3wdbXVXL/ioCUunlj+SAciT9KRzsWpvhKCJHUkng418R
OJaiDG3+IwYSSvYgNRGJbZjtwuNf48h6bzkGuH4SQcImZZ6hcEc=
=Yt7F
-----END PGP SIGNATURE-----

--q0iLX+HWYyGFjg7I--