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.