htlcswitch/[feature]: dynamically regulate the max anchor fee based on subjective min relay fee and peer's feefilter

[Roasbeef]

Is your feature request related to a problem? Please describe.

Today for anchor channels, we have a value max-commit-fee-rate-anchors that regulates the highest fee rate in sat/vbyte that we'll use for our commitment transaction. Under the hood, there's more logic here, but for the most part, users can set this value in order to ensure that their commitment transaction will properly propagate in the case of a force close.

This worked ok in prior times of a calm mempool, but these days, rapid spikes in the mempool can easily render the default of 10 sat/byte much too low to effectively propagate.

One other relevant interaction is that of the feefilter message, specified in BIP 133. Peers send this message to tell other peers that they shouldn't send transactions below a certain fee rate. This fee rate is a function of their current mempool size, and also their configured max mempool size.

Recently, I've seen an affect wherein the min mempool fee of my node is much lower than the fee rate advertised by many of my peers. As a result, even with the default of a 300 MB mempool, my node's mempool is well below that value as due to transitive propagation obstructions caused by the feefilter message, there's a class of transactions my node never actually sees.

This is where a key propagation issue can arise:

• Today we look at the min mempool fee of our node to determine what the absolute min we need to ensure relay is:

  • lnd/htlcswitch/link.go

    Line 1159 in 30348ba

    minRelayFee := l.cfg.FeeEstimator.RelayFeePerKW()

  • lnd/lnwallet/chainfee/estimator.go

    Line 364 in 30348ba

    func (b *BitcoindEstimator) fetchMinMempoolFee() (SatPerKWeight, error) {

• However, for a node with default, or even high mempool settings, that doesn't have tens of hundreds of connections, that reported value may actually be insufficient to effectively propagate. To see why, check out the feefilter value of a sample of peers:

/ # bitcoin-cli getpeerinfo | jq '.[].minfeefilter | ((. * 100000000) / 1024)'
0
0
22.0986328125
22.0986328125
22.0986328125
43.064453125
18.263671875
0.9765625000000001
22.0986328125
22.0986328125

Compare that to my min mempool fee: "mempoolminfee": 0.00001000.

Describe the solution you'd like

We should factor the minfeefilter value available in getpeerinfo into the algorithm we choose to set the current anchor commitment fee rate. In the case above, even with a default value of 10 sat/byte as the max, due to the current logic, we're able to get into our mempool, but not our peer's mempool, and therefore not their peer's peer's mempool and so on.

We shouldn't just take these values as is though, to protect against a degree of manipulation we may want to use some smoothing like a moving average sampled periodically.

We should also factor this into the sweeper as well, since any time sensitive sweeps need to be above this value in order to actually propagate.

With this in place, we should be able to get rid of the max-commit-fee-rate-anchors and take the guess work out of running a secure node.

[saubyk]

Concept Ack and always in favor of removing available configuration options (max-commit-fee-rate-anchors in this case) reducing the cognitive load on the users

[djkazic]

Bit of a mobile user edge case but probably worth mentioning: some users don't have a lot of onchain coins so it might make sense to have a configurable parameter that does a proportional padding of fees (working on the assumption that they don't fee bump the commit tx later).

Else the tx might still be too low in fees (not for propagation necessarily, more about time to conf).

[Crypt-iQ]

We shouldn't just take these values as is though, to protect against a degree of manipulation we may want to use some smoothing like a moving average sampled periodically.

This is a good point. I think that we could weight outbound connections' filters higher than inbound connections' as they are harder to manipulate. We should also ignore filter values of 0 (the peer hasn't sent fee_filter or are on an earlier protocol version) and MAX_MONEY (bitcoin core sends this during IBD).