@@ -48,21 +48,105 @@ 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
53+ /// to low hundreds of blocks to get our transaction on-chain, but we shouldn't risk too low a
54+ /// fee - this should be a relatively high priority feerate.
55+ OnChainSweep ,
56+ /// The highest feerate 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
59+ /// order to close the channel unilaterally. Because our counterparty must ensure they can
60+ /// always broadcast the latest state, this value being too low will cause immediate
61+ /// force-closures.
62+ ///
63+ /// Allowing this value to be too high can allow our counterparty to burn our HTLC outputs to
64+ /// dust, which can result in HTLCs failing or force-closures (when the dust HTLCs exceed
65+ /// [`ChannelConfig::max_dust_htlc_exposure`]).
66+ ///
67+ /// Because most nodes use a feerate estimate which is based on a relatively high priority
68+ /// transaction entering the current mempool, setting this to a small multiple of your current
69+ /// high priority feerate estimate should suffice.
70+ ///
71+ /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
72+ MaxAllowedNonAnchorChannelRemoteFee ,
73+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
74+ /// order to close the channel if a channel party goes away. Because our counterparty must
75+ /// ensure they can always broadcast the latest state, this value being too low will cause
76+ /// immediate force-closures.
77+ ///
78+ /// This needs to be sufficient to get into the mempool when the channel needs to
79+ /// be force-closed. Setting too low may result in force-closures. Because this is for anchor
80+ /// channels, we can always bump the feerate later, the feerate here only needs to suffice to
81+ /// enter the mempool.
82+ ///
83+ /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
84+ /// is not an estimate which is very easy to calculate because we do not know the future. Using
85+ /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
86+ /// ensure you can always close the channel. A future change to Bitcoin's P2P network
87+ /// (package relay) may obviate the need for this entirely.
88+ MinAllowedAnchorChannelRemoteFee ,
89+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
90+ /// order to close the channel if a channel party goes away. Because our counterparty must
91+ /// ensure they can always broadcast the latest state, this value being too low will cause
92+ /// immediate force-closures.
93+ ///
94+ /// The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
95+ /// This needs to be sufficient to get confirmed when the channel needs to be force-closed.
96+ /// Setting too low may result in force-closures.
97+ ///
98+ /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an
99+ /// arbitrary time in the future. Obviously this is not an estimate which is very easy to
100+ /// calculate. This can leave channels subject to being unable to close if feerates rise, and in
101+ /// general you should prefer anchor channels to ensure you can increase the feerate when the
102+ /// transactions need broadcasting.
103+ ///
104+ /// Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
105+ /// causing occasional issues with feerate disagreements between an initiator that wants a
106+ /// feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. Adding 250 to your
107+ /// desired feerate here can help avoid this issue.
108+ ///
109+ /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
110+ MinAllowedNonAnchorChannelRemoteFee ,
111+ /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
112+ /// order to close the channel if a channel party goes away. Because our counterparty must does
113+ /// not want to burn all their funds to fees, this value being too high can cause
114+ /// force-closures.
115+ ///
116+ /// This needs to be sufficient to get into the mempool when the channel needs to
117+ /// be force-closed. Setting too low may result in force-closures. Because this is for anchor
118+ /// channels, it can be a low value as we can always bump the feerate later.
119+ ///
120+ /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
121+ /// is not an estimate which is very easy to calculate because we do not know the future. Using
122+ /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
123+ /// ensure you can always close the channel. A future change to Bitcoin's P2P network
124+ /// (package relay) may obviate the need for this entirely.
125+ AnchorChannelFee ,
126+ /// Lightning is built around the ability to broadcast a transaction in the future to close our
127+ /// channel and claim all pending funds. In order to do so, non-anchor channels are built with
128+ /// transactions which we need to be able to broadcast at some point in the future.
129+ ///
130+ /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an
131+ /// arbitrary time in the future. Obviously this is not an estimate which is very easy to
132+ /// calculate, so most lightning nodes use some relatively high-priority feerate using the
133+ /// current mempool. This leaves channels subject to being unable to close if feerates rise, and
134+ /// in general you should prefer anchor channels to ensure you can increase the feerate when the
135+ /// transactions need broadcasting.
136+ ///
137+ /// Since this is a should represent the feerate of a channel close that does not need fee
138+ /// bumping. This is also used as an upperbound for our attempted feerate when doing cooperative
139+ /// closure of any channel.
140+ NonAnchorChannelFee ,
141+ /// When cooperatively closing a channel, this is the minimum feerate we will accept.
142+ /// Recommended at least within a day or so worth of blocks.
143+ ///
144+ /// This will also be used when initiating a cooperative close of a channel. When closing a
145+ /// channel you can override this fee by using
146+ /// [`ChannelManager::close_channel_with_feerate_and_script`].
147+ ///
148+ /// [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
149+ ChannelCloseMinimum ,
66150}
67151
68152/// A trait which should be implemented to provide feerate information on a number of time
@@ -135,7 +219,7 @@ mod tests {
135219 let test_fee_estimator = & TestFeeEstimator { sat_per_kw } ;
136220 let fee_estimator = LowerBoundedFeeEstimator :: new ( test_fee_estimator) ;
137221
138- assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: Background ) , FEERATE_FLOOR_SATS_PER_KW ) ;
222+ assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: AnchorChannelFee ) , FEERATE_FLOOR_SATS_PER_KW ) ;
139223 }
140224
141225 #[ test]
@@ -144,6 +228,6 @@ mod tests {
144228 let test_fee_estimator = & TestFeeEstimator { sat_per_kw } ;
145229 let fee_estimator = LowerBoundedFeeEstimator :: new ( test_fee_estimator) ;
146230
147- assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: Background ) , sat_per_kw) ;
231+ assert_eq ! ( fee_estimator. bounded_sat_per_1000_weight( ConfirmationTarget :: AnchorChannelFee ) , sat_per_kw) ;
148232 }
149233}
0 commit comments