Le mardi 30 juillet 2024 à 20:58:08 UTC+1, Peter Todd a écrit :
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