@@ -48,21 +48,86 @@ pub trait BroadcasterInterface {
4848/// estimation.
4949#[ derive( Clone , Copy , Debug , Hash , PartialEq , Eq ) ]
5050pub enum ConfirmationTarget {
51- /// We'd like a transaction to confirm in the future, but don't want to commit most of the fees
52- /// required to do so yet. The remaining fees will come via a Child-Pays-For-Parent (CPFP) fee
53- /// bump of the transaction.
54- ///
55- /// The feerate returned should be the absolute minimum feerate required to enter most node
56- /// mempools across the network. Note that if you are not able to obtain this feerate estimate,
57- /// you should likely use the furthest-out estimate allowed by your fee estimator.
58- MempoolMinimum ,
59- /// We are happy with a transaction confirming slowly, at least within a day or so worth of
60- /// blocks.
61- Background ,
62- /// We'd like a transaction to confirm without major delayed, i.e., within the next 12-24 blocks.
63- Normal ,
64- /// We'd like a transaction to confirm in the next few blocks.
65- HighPriority ,
51+ /// We have some funds available on chain which we need to spend prior to some expiry time at
52+ /// which point our counterparty may be able to steal them. Generally we have in the high tens to low hundreds of blocks
53+ /// to get our transaction on-chain, but we shouldn't risk too low a fee - this should be a relatively high priority
54+ /// feerate.
55+ OnChainSweep ,
56+ /// The highest fee rate we will allow our channel counterparty to have in a non-anchor channel.
57+ ///
58+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in order to
59+ /// close the channel if a channel party goes away. Because our counterparty must ensure they can
60+ /// always broadcast the latest state, this value being too low will cause immediate force-closures.
61+ ///
62+ /// Allowing this value to be too high can allow our counterparty to burn our HTLC outputs to dust, which
63+ /// can result in HTLCs failing or force-closures (when the dust HTLCs exceed
64+ /// [`ChannelConfig::max_dust_htlc_exposure`]).
65+ ///
66+ /// Because most nodes use a feerate estimate which is based on a relatively high priority transaction
67+ /// entering the current mempool, setting this to a small multiple of your current high priority feerate estimate
68+ /// should suffice.
69+ ///
70+ /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
71+ MaxAllowedNonAnchorChannelRemoteFee ,
72+ /// This needs to be sufficient to get into the mempool when the channel needs to
73+ /// be force-closed. Setting too low may result in force-closures. Because this is for anchor
74+ /// channels, we can always bump the fee rate later, the feerate here only needs to suffice to
75+ /// enter the mempool.
76+ ///
77+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in order to
78+ /// close the channel if a channel party goes away. Because our counterparty must ensure they can
79+ /// always broadcast the latest state, this value being too low will cause immediate force-closures.
80+ /// However this value being too high can allow our counterparty to burn our HTLC outputs to dust, which
81+ /// can result in a LDK force closing the channel to avoid losing money.
82+ ///
83+ /// A good estimate is the expected mempool minimum at the time of force-closure.
84+ MinAllowedAnchorChannelRemoteFee ,
85+ /// The lowest fee rate we will allow our channel counterparty to have in a non-anchor channel.
86+ /// This needs to be sufficient to get confirmed when the channel needs to be force-closed.
87+ /// Setting too low may result in force-closures.
88+ ///
89+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in order to
90+ /// close the channel if a channel party goes away. Because our counterparty must ensure they can
91+ /// always broadcast the latest state, this value being too low will cause immediate force-closures.
92+ /// However this value being too high can allow our counterparty to burn our HTLC outputs to dust, which
93+ /// can result in a LDK force closing the channel to avoid losing money.
94+ ///
95+ /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an arbitrary
96+ /// time in the future. Obviously this is not an estimate which is very easy to calculate. This
97+ /// can leave channels subject to being unable to close if feerates rise, and in general you
98+ /// should prefer anchor channels to ensure you can increase the feerate when the transactions
99+ /// need broadcasting.
100+ ///
101+ /// A good estimate is at least within a day (144) or so worth of blocks.
102+ MinAllowedNonAnchorChannelRemoteFee ,
103+ /// This needs to be sufficient to get into the mempool when the channel needs to
104+ /// be force-closed. Setting too low may result in force-closures. Because this is for anchor
105+ /// channels, it can be a low value as we can always bump the fee rate later.
106+ ///
107+ /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this is
108+ /// not an estimate which is very easy to calculate because we do not know the future. Using
109+ /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
110+ /// ensure you can always close the channel. A future change to Bitcoin's P2P network (package relay)
111+ /// may obviate the need for this entirely.
112+ AnchorChannelFee ,
113+ /// Lightning is built around the ability to broadcast a transaction in the future to close our channel
114+ /// and claim all pending funds. In order to do so, pre-anchor channels are built with transactions which
115+ /// we need to be able to broadcast at some point in the future.
116+ ///
117+ /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an arbitrary
118+ /// time in the future. Obviously this is not an estimate which is very easy to calculate, so most lightning
119+ /// nodes use some relatively high-priority feerate using the current mempool. This leaves channels
120+ /// subject to being unable to close if feerates rise, and in general you should prefer anchor channels to
121+ /// ensure you can increase the feerate when the transactions need broadcasting.
122+ NonAnchorChannelFee ,
123+ /// When cooperative closing channel, the minimum fee rate we will accept. Recommended at least
124+ /// within a day or so worth of blocks.
125+ ///
126+ /// This will also be used when initiating a cooperative close of a channel. When closing a channel
127+ /// you can override this fee by using [`ChannelManager::close_channel_with_feerate_and_script`].
128+ ///
129+ /// [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
130+ ChannelCloseMinimum ,
66131}
67132
68133/// A trait which should be implemented to provide feerate information on a number of time
@@ -135,7 +200,7 @@ mod tests {
135200 let test_fee_estimator = & TestFeeEstimator { sat_per_kw } ;
136201 let fee_estimator = LowerBoundedFeeEstimator :: new ( test_fee_estimator) ;
137202
138- assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: Background ) , FEERATE_FLOOR_SATS_PER_KW ) ;
203+ assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: AnchorChannelFee ) , FEERATE_FLOOR_SATS_PER_KW ) ;
139204 }
140205
141206 #[ test]
@@ -144,6 +209,6 @@ mod tests {
144209 let test_fee_estimator = & TestFeeEstimator { sat_per_kw } ;
145210 let fee_estimator = LowerBoundedFeeEstimator :: new ( test_fee_estimator) ;
146211
147- assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: Background ) , sat_per_kw) ;
212+ assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: AnchorChannelFee ) , sat_per_kw) ;
148213 }
149214}
0 commit comments