eclair&lnd: Force-close due to feerate dispute with low on-chain fees

[C-Otto]

The ACINQ node at 03864ef025fde8fb587d989186ce6a4a186895ee44a926bfc370e2c366597a3f8f force-closed a channel after the following interaction happened. Note that the force-close transaction 84047f4dca33f7c383a576ac1792633e824c3414790a01a4fb33ad4c71fb8453 was sent with a fee rate of 4.2 sat/vByte (confirmed in the next block).

2021-05-30 09:51:13.452 [ERR] HSWC: ChannelLink(680882:1249:0): failing link: ChannelPoint(998fd99b0b7646a6479adecc8b38b043774fd6a22dd45dfe1c26edf3ef1de750:0): received error from peer: chan_id=50e71deff3ed261cfe5dd42da2d64f7743b0388bccde9a47a646760b9bd98f99, err=local/remote feerates are too different: remoteFeeratePerKw=1050 localFeeratePerKw=16413 with error: remote error

My node is running lnd 0.12.1, and I guess ACINQ is running eclair. My node suggested a fee rate of 1050 (4.2 sat/vByte), while Eclair suggested 16413 (65 sat/vByte).

I believe that 1050 (4.2 sat/vByte) is very reasonable, especially if you consider that the ACINQ node created a close transaction with exactly this fee rate. Furthermore, I think that 16413 (65 sat/vByte) is quite a lot in a low-fee situation where several 1 sat/vByte transactions are confirmed in the next block.

I'd like to figure out how the nodes disagreed on this, and what can be done in lnd / my configuration, or in the eclair codebase to avoid this in the future. Furthermore, I'd like eclair to be a bit more relaxed: instead of force-closing the channel, it could be good enough to wait a couple of minutes/blocks, or just attempt a cooperative close.

[pm47]

I'd like to figure out how the nodes disagreed on this, and what can be done in lnd / my configuration, or in the eclair codebase to avoid this in the future.

Short answer: in this case it was probably due to the -16% diff adjustement. The quick diminution of the size of the mempool must have temporarily created widely different fee estimates.

Longer answer: nodes will disagree, not because they have bugs or are misconfigured, but because due to the decentralized nature of bitcoin it is impossible to agree on what the appropriate feerate is. This is precisely the reason why the new anchor_outputs commitment format was introduced. It basically allows to not have to agree.

Furthermore, I'd like eclair to be a bit more relaxed: instead of force-closing the channel, it could be good enough to wait a couple of minutes/blocks, or just attempt a cooperative close.

In case of a disagreement, we already delay the force close as long as possible; in your case until an htlc was proposed. Only then did we force close. Technically I guess we could accept the htlc, then not forward it and cancel it right away. I don't think any implementation has implemented this mechanism though, and since anchor outputs is being rolled out, it makes less sense to work on that kind of things.

Also, the fee of the commitment tx is absolutely critical from a security perspective, and due to the size of our nodes, we have to be on the conservative side (even if it causes annoying false positive force closes), because significant amounts are at stake.

I believe that 1050 (4.2 sat/vByte) is very reasonable, especially if you consider that the ACINQ node created a close transaction with exactly this fee rate.

This is no coincidence: in a force close, we publish the last commitment transaction, which was signed by your node. Indeed, retrospectively it was a perfectly reasonable feerate, but our bitcoind thought otherwise at the time.

[C-Otto]

Thank you for the explanation. It's quite annoying to suffer from issues like this and be pointed to some future improvements (this isn't the first time, I've been around...), but at least there's progress.

[t-bast]

Closing this issue as we can't change this behavior in the short term.
The fix is to migrate to anchor outputs, which we're actively working on.