Delivery-date: Tue, 30 Jul 2024 12:58:14 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of pete@petertodd.org designates 103.168.172.148 as permitted sender) client-ip=103.168.172.148;
Feedback-ID: i525146e8:Fastmail
Date: Tue, 30 Jul 2024 19:38:17 +0000
From: Peter Todd <pete@petertodd.org>
To: "David A. Harding" <dave@dtrt.org>
Cc: Antoine Riard <antoine.riard@gmail.com>,
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
Message-ID: <ZqlBKVXBKKIurBPk@petertodd.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n@googlegroups.com>
 <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="n+bJ/YzemJOvNThF"
Content-Disposition: inline
In-Reply-To: <4e959cdbe70b1a3b9f1adb37fe3b986e@dtrt.org>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com


--n+bJ/YzemJOvNThF
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline

On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote:
> Given the first point and the last point, I'm not sure how viable the
> attack is (but, as I said, I'm not sure I understand it).  Estimating or
> manipulating feerates correctly for over 144 blocks in a row sounds
> difficult.  Counterparties being able to deprive Mallory of profit seems
> like a major weakness.

It is not.

I've actually *accidentally* exploited this type of pinning vector a few times
in Lighting channels by simply force closing them at times when fee-rates were
high. I've even twice managed to delay the force close of a channel by testing
out justice transactions by broadcasting a low fee-rate, revoked commitment,
which the counterparty node did not notice.  Instead, the channel just stayed
in limbo for a few days until the node finally got in a normal force-close
using the non-revoked state after fees reduced. In both cases, both endpoints
were LND using compact block filters (I was running both nodes in these tests).
IIUC the LND compat block filter implementation does not track mempool
transactions, so it only notices revoked commitment transactions when they
appear in blocks (notice how this means that the lack of package relay will
render LND's fee-bumping code potentially useless if the conflicting commitment
transaction is equal or greater fee/fee-rate).

I haven't tried fully exploiting this particular scenario by maximizing the
number of HTLCs in flight; I was just trying out stuff manually. Someone
should.

It should be relatively easy to automate this class type of attack by simply
picking opportunities for it based on fee rates. It's quite common for fee
spikes to cause conditions where you can easily predict that fees won't go
below certain levels for many blocks in the future, multiple days even. Your
claim that "estimating feerates correctly for over 144 blocks in a row sounds
difficult" is very wrong.

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

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZqlBKVXBKKIurBPk%40petertodd.org.

--n+bJ/YzemJOvNThF
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmapQScACgkQLly11TVR
Lzdb7Q//WaAy9wiYZ7S1OM4miCe8t9ayrLO9IUI8XVYwNOjVINccp/KGVEv7WTqB
HMIRIafesOq3NnwLQU+BBqffCu9f5ZycW/8/YhEBz211KLQ2eFJBFVQQpPMOLZrM
gCCznyJQ/MpCWIZ+J7N7FY5xy8Qypgz1232/aHynFZEyMPZDIbrkJa4loixVklfH
0kY9ypvOwrhMpSZPFViKe6rtfXp/cW2S61jZ9+MkE2NxLzNbbk/4iWhvIIIiru0U
L0pml6E8A1vvUADMCnlC/Y3jjN71X4QtqjwcEylllNxU1fPMtYOl5UA0XvJ85+2J
KdontP7TXqZ/1lWjciOcxetnFugami03ug9B9VgJbLCB3I3mzLeMCT9Ap1Cs8ii7
YjUGcXWxvyWkiJ3EixfUnttyR7Oo++hn2Hd/5+96t3KXt3/bduTZkb/P/OgEiSjd
rBZTBypqJdCGOBBwUYyp3/C9Y8VLDXoHAfQt+XgkuRqGRkH0twy6jimGAL3RKpas
sr2f9UofaoSnew8wWxrocX7x0HOEoaVU5Lx+u9LtTbZHdpXYHcEOLoE3atsmMysr
9ZRbbOdGGFVScbqfSElDIffuke9Kw8s00o7tq6EhtK25M/F0JTrRn4ODy2NuebSt
GKqKgeR17aDnPCnq4i2Nd6ofNO2GZSuMPFU6giIwpOVmHp4v2i8=
=XlnP
-----END PGP SIGNATURE-----

--n+bJ/YzemJOvNThF--