Accept feerate increases even if they aren't high enough for us 2022-11-accept-bad-but-better-fee-updates
authorMatt Corallo <git@bluematt.me>
Tue, 15 Nov 2022 00:46:22 +0000 (00:46 +0000)
committerMatt Corallo <git@bluematt.me>
Wed, 16 Nov 2022 03:54:00 +0000 (03:54 +0000)
commita1404aac638b40e57443ae52bece5232fdf7db2a
tree9013c4bcdda42a5d6c4065b61a5e88e834bcfe75
parent838d48698384d41e8a9114f4f644dbb83ce5d6fa
Accept feerate increases even if they aren't high enough for us

LND nodes have very broken fee estimators, causing them to suggest
feerates that don't even meet a current mempool minimum feerate
when fees go up over the course of hours. This can cause us to
reject their feerate estimates as they're not high enough, even
though their new feerate is higher than what we had already (which
is the feerate we'll use to broadcast a closing transaction). This
implies we force-close the channel and broadcast something with a
feerate lower than our counterparty was offering.

Here we simply accept such feerates as they are better than what we
had. We really should also close the channel, but only after we
get their signature on the new feerate. That should happen by
checking channel feerates every time we see a new block so is
orthogonal to this code.

Ultimately the fix is anchor outputs plus package-based relay in
Bitcoin Core, however we're still quite some ways from that, so
worth needlessly closing channels for now.
lightning/src/ln/channel.rs
lightning/src/ln/channelmanager.rs
lightning/src/ln/functional_tests.rs