Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard <antoine.riard@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 5602 bytes --]

Hi Peter,

> 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.

After reading Dave description of the "loophole pinning" attack, which is a
re-formalization of my gitub comment on one of the TRUC PR, I'm not entirely
sure, we're describing the same exploitation scenario. Finely evaluating the
viability of an attack, before the attack scheme and attacker capabilities 
are
fleshed out is a bit premature...

Especially, when you're saying few more lines after that you have tried to
fully exploit this scenario with HTLCs in flights, and all other attempts
were more accidental and without being sure the LND software correctly
implements RBF, including the rule 5 penalty computation at all time (you're
observing yourself the limitations of LND's fee-bumping code).

If there is a lightning node on mainnet of yours that your formally 
authorize
me to test some pinning attacks, I could try a demo. Alternatively, I can
setup a LN node + full-node on some long-running infrastructure, if you wish
to try the scenario on your side. Though, as observed by Dave there is no
lightning code written yet to opt-in into TRUC transactions.

On the last observation, I agree with you that is a class type of attack 
that
one could automate by leveraging fee-estimation algorithms.

Best,
Antoine
ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621cfecc9b1478075a0da4d8c5c0a5

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
>

-- 
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/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6889 bytes --]