/// be sure to manage both cases correctly.
///
/// Bitcoin transaction packages are defined in BIP 331 and here:
- /// https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md
+ /// <https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md>
fn broadcast_transactions(&self, txs: &[&Transaction]);
}
/// 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. Because our counterparty
- /// must ensure they can always broadcast the latest state, this value being too high will cause
- /// immediate force-closures.
+ /// 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 low may result in force-closures. Because this is for anchor
- /// channels, we can always bump the feerate later, the feerate here only needs to suffice to
- /// enter the mempool.
+ /// 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
/// (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 needs to be sufficient to get confirmed when the channel needs to be force-closed.
- /// Setting too low may result in force-closures.
///
/// 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. Because our counterparty must
- /// ensure they can always broadcast the latest state, this value being too high will cause
- /// immediate force-closures.
+ /// 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