Matt Corallo f0de37ae1f 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 51bf78d604, 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.		2024-08-27 16:36:54 +00:00
..
src	Add a new ConfirmationTarget::MaximumFeeEstimate	2024-08-27 16:36:54 +00:00
Cargo.toml	Bump version numbers to 0.0.124-beta/invoice 0.32-beta	2024-08-20 00:29:12 +00:00