Add `ConfirmationTarget::OutputSpendingFee`

[rust-lightning] / lightning / src / chain / chaininterface.rs

diff --git a/lightning/src/chain/chaininterface.rs b/lightning/src/chain/chaininterface.rs
index dfb90135c88de84b2d9fe962c9e05d354cbab86b..68dea58dc0080d1fce61685d6d3d19c8d2b56efc 100644 (file)
--- a/lightning/src/chain/chaininterface.rs
+++ b/lightning/src/chain/chaininterface.rs
@@ -14,7 +14,8 @@
 //! disconnections, transaction broadcasting, and feerate information requests.
 
 use core::{cmp, ops::Deref};
-use core::convert::TryInto;
+
+use crate::prelude::*;
 
 use bitcoin::blockdata::transaction::Transaction;
 
@@ -40,7 +41,7 @@ pub trait BroadcasterInterface {
        /// 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]);
 }
 
@@ -53,32 +54,13 @@ pub enum ConfirmationTarget {
        /// 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
@@ -87,13 +69,10 @@ pub enum ConfirmationTarget {
        /// (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
@@ -145,6 +124,8 @@ pub enum ConfirmationTarget {
        ///
        /// [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
        ChannelCloseMinimum,
+       /// XXX
+       OutputSpendingFee,
 }
 
 /// A trait which should be implemented to provide feerate information on a number of time