+ /// We have some funds available on chain which we need to spend prior to some expiry time at
+ /// which point our counterparty may be able to steal them. Generally we have in the high tens
+ /// to low hundreds of blocks to get our transaction on-chain, but we shouldn't risk too low a
+ /// fee - this should be a relatively high priority feerate.
+ OnChainSweep,
+ /// The highest feerate we will allow our channel counterparty to have in a non-anchor channel.
+ ///
+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
+ /// order to close the channel unilaterally. Because our counterparty must ensure they can
+ /// always broadcast the latest state, this value being too low will cause immediate
+ /// force-closures.
+ ///
+ /// Allowing this value to be too high can allow our counterparty to burn our HTLC outputs to
+ /// dust, which can result in HTLCs failing or force-closures (when the dust HTLCs exceed
+ /// [`ChannelConfig::max_dust_htlc_exposure`]).
+ ///
+ /// Because most nodes use a feerate estimate which is based on a relatively high priority
+ /// transaction entering the current mempool, setting this to a small multiple of your current
+ /// high priority feerate estimate should suffice.
+ ///
+ /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
+ MaxAllowedNonAnchorChannelRemoteFee,
+ /// This is the lowest feerate we will allow our channel counterparty to have in an anchor
+ /// channel in order to close the channel if a channel party goes away.
+ ///
+ /// This needs to be sufficient to get into the mempool when the channel needs to
+ /// be force-closed. Setting too high may result in force-closures if our counterparty attempts
+ /// to use a lower feerate. Because this is for anchor channels, we can always bump the feerate
+ /// later; the feerate here only needs to be sufficient to enter the mempool.
+ ///
+ /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
+ /// is not an estimate which is very easy to calculate because we do not know the future. Using
+ /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
+ /// ensure you can always close the channel. A future change to Bitcoin's P2P network
+ /// (package relay) may obviate the need for this entirely.
+ MinAllowedAnchorChannelRemoteFee,
+ /// The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
+ ///
+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
+ /// order to close the channel if a channel party goes away. Setting this value too high will
+ /// cause immediate force-closures in order to avoid having an unbroadcastable state.
+ ///
+ /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an
+ /// arbitrary time in the future. Obviously this is not an estimate which is very easy to
+ /// calculate. This can leave channels subject to being unable to close if feerates rise, and in
+ /// general you should prefer anchor channels to ensure you can increase the feerate when the
+ /// transactions need broadcasting.
+ ///
+ /// Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
+ /// causing occasional issues with feerate disagreements between an initiator that wants a
+ /// feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. If your fee
+ /// estimator rounds subtracting 250 to your desired feerate here can help avoid this issue.
+ ///
+ /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
+ MinAllowedNonAnchorChannelRemoteFee,
+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
+ /// order to close the channel if a channel party goes away.