]> git.bitcoin.ninja Git - rust-lightning/commit
Add a new `ConfirmationTarget::MaximumFeeEstimate`
authorMatt Corallo <git@bluematt.me>
Thu, 22 Aug 2024 15:25:56 +0000 (15:25 +0000)
committerMatt Corallo <git@bluematt.me>
Tue, 27 Aug 2024 16:36:54 +0000 (16:36 +0000)
commitf0de37ae1fb43587015959bb31961fe5a7f4d173
treebe804387792e6881d33bf6da75cd8321686a2717
parentdced69d02516f3afe26f0e6e25821e8aabfa5c85
Add a new `ConfirmationTarget::MaximumFeeEstimate`

When we broke `ConfirmationTarget` out into task-specific names, we
left `MaxDustHTLCExposure::FeeRateMultiplier` as using the "when we
broadcast feerate" as we were mostly concerned about the dust
thresholds on outbound channels where we pick the fee and drive our
own funds to dust.

In 51bf78d604b28fe189171e1b976fe87cbb2614b7, that changed to
include transaction fees on both inbound and outbound channels in
our dust exposure amount, but we continued to use
`ConfirmationTarget::OnChainSweep` for the fee estimator threshold.

While the `MaxDustHTLCExposure::FeeRateMultiplier` value is quite
conservative and shouldn't lead to force-closures unless feerate
estimates disagree by something like 500 sat/vB (with only one HTLC
active in a channel), this happened on Aug 22 when feerates spiked
from 4 sat/vB to over 1000 sat/vB in one block.

To avoid simple feerate estimate horizons causing this in the
future, here we add a new
`ConfirmationTarget::MaximumFeeEstimate` which is used for dust
calculations. This allows users to split out the estimates they use
for checking counterparty feerates from the estimates used for
actual broadcasting.
fuzz/src/chanmon_consistency.rs
lightning/src/chain/chaininterface.rs
lightning/src/ln/channel.rs
lightning/src/util/config.rs