git.bitcoin.ninja Git - rust-lightning/blob - lightning/src/chain/chaininterface.rs

   1 // This file is Copyright its original authors, visible in version control
   2 // history.
   3 //
   4 // This file is licensed under the Apache License, Version 2.0 <LICENSE-APACHE
   5 // or http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
   6 // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your option.
   7 // You may not use this file except in accordance with one or both of these
   8 // licenses.
   9
  10 //! Traits and utility impls which allow other parts of rust-lightning to interact with the
  11 //! blockchain.
  12 //!
  13 //! Includes traits for monitoring and receiving notifications of new blocks and block
  14 //! disconnections, transaction broadcasting, and feerate information requests.
  15
  16 use core::{cmp, ops::Deref};
  17
  18 use crate::prelude::*;
  19
  20 use bitcoin::blockdata::transaction::Transaction;
  21
  22 // TODO: Define typed abstraction over feerates to handle their conversions.
  23 pub(crate) fn compute_feerate_sat_per_1000_weight(fee_sat: u64, weight: u64) -> u32 {
  24         (fee_sat * 1000 / weight).try_into().unwrap_or(u32::max_value())
  25 }
  26 pub(crate) const fn fee_for_weight(feerate_sat_per_1000_weight: u32, weight: u64) -> u64 {
  27         ((feerate_sat_per_1000_weight as u64 * weight) + 1000 - 1) / 1000
  28 }
  29
  30 /// An interface to send a transaction to the Bitcoin network.
  31 pub trait BroadcasterInterface {
  32         /// Sends a list of transactions out to (hopefully) be mined.
  33         /// This only needs to handle the actual broadcasting of transactions, LDK will automatically
  34         /// rebroadcast transactions that haven't made it into a block.
  35         ///
  36         /// In some cases LDK may attempt to broadcast a transaction which double-spends another
  37         /// and this isn't a bug and can be safely ignored.
  38         ///
  39         /// If more than one transaction is given, these transactions should be considered to be a
  40         /// package and broadcast together. Some of the transactions may or may not depend on each other,
  41         /// be sure to manage both cases correctly.
  42         ///
  43         /// Bitcoin transaction packages are defined in BIP 331 and here:
  44         /// <https://github.com/bitcoin/bitcoin/blob/master/doc/policy/packages.md>
  45         fn broadcast_transactions(&self, txs: &[&Transaction]);
  46 }
  47
  48 /// An enum that represents the priority at which we want a transaction to confirm used for feerate
  49 /// estimation.
  50 #[derive(Clone, Copy, Debug, Hash, PartialEq, Eq)]
  51 pub enum ConfirmationTarget {
  52         /// We have some funds available on chain which we need to spend prior to some expiry time at
  53         /// which point our counterparty may be able to steal them. Generally we have in the high tens
  54         /// to low hundreds of blocks to get our transaction on-chain, but we shouldn't risk too low a
  55         /// fee - this should be a relatively high priority feerate.
  56         OnChainSweep,
  57         /// This is the lowest feerate we will allow our channel counterparty to have in an anchor
  58         /// channel in order to close the channel if a channel party goes away.
  59         ///
  60         /// This needs to be sufficient to get into the mempool when the channel needs to
  61         /// be force-closed. Setting too high may result in force-closures if our counterparty attempts
  62         /// to use a lower feerate. Because this is for anchor channels, we can always bump the feerate
  63         /// later; the feerate here only needs to be sufficient to enter the mempool.
  64         ///
  65         /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
  66         /// is not an estimate which is very easy to calculate because we do not know the future. Using
  67         /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
  68         /// ensure you can always close the channel. A future change to Bitcoin's P2P network
  69         /// (package relay) may obviate the need for this entirely.
  70         MinAllowedAnchorChannelRemoteFee,
  71         /// The lowest feerate we will allow our channel counterparty to have in a non-anchor channel.
  72         ///
  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. Setting this value too high will
  75         /// cause immediate force-closures in order to avoid having an unbroadcastable state.
  76         ///
  77         /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an
  78         /// arbitrary time in the future. Obviously this is not an estimate which is very easy to
  79         /// calculate. This can leave channels subject to being unable to close if feerates rise, and in
  80         /// general you should prefer anchor channels to ensure you can increase the feerate when the
  81         /// transactions need broadcasting.
  82         ///
  83         /// Do note some fee estimators round up to the next full sat/vbyte (ie 250 sats per kw),
  84         /// causing occasional issues with feerate disagreements between an initiator that wants a
  85         /// feerate of 1.1 sat/vbyte and a receiver that wants 1.1 rounded up to 2. If your fee
  86         /// estimator rounds subtracting 250 to your desired feerate here can help avoid this issue.
  87         ///
  88         /// [`ChannelConfig::max_dust_htlc_exposure`]: crate::util::config::ChannelConfig::max_dust_htlc_exposure
  89         MinAllowedNonAnchorChannelRemoteFee,
  90         /// This is the feerate on the transaction which we (or our counterparty) will broadcast in
  91         /// order to close the channel if a channel party goes away.
  92         ///
  93         /// This needs to be sufficient to get into the mempool when the channel needs to
  94         /// be force-closed. Setting too low may result in force-closures. Because this is for anchor
  95         /// channels, it can be a low value as we can always bump the feerate later.
  96         ///
  97         /// A good estimate is the expected mempool minimum at the time of force-closure. Obviously this
  98         /// is not an estimate which is very easy to calculate because we do not know the future. Using
  99         /// a simple long-term fee estimate or tracking of the mempool minimum is a good approach to
 100         /// ensure you can always close the channel. A future change to Bitcoin's P2P network
 101         /// (package relay) may obviate the need for this entirely.
 102         AnchorChannelFee,
 103         /// Lightning is built around the ability to broadcast a transaction in the future to close our
 104         /// channel and claim all pending funds. In order to do so, non-anchor channels are built with
 105         /// transactions which we need to be able to broadcast at some point in the future.
 106         ///
 107         /// This feerate represents the fee we pick now, which must be sufficient to enter a block at an
 108         /// arbitrary time in the future. Obviously this is not an estimate which is very easy to
 109         /// calculate, so most lightning nodes use some relatively high-priority feerate using the
 110         /// current mempool. This leaves channels subject to being unable to close if feerates rise, and
 111         /// in general you should prefer anchor channels to ensure you can increase the feerate when the
 112         /// transactions need broadcasting.
 113         ///
 114         /// Since this should represent the feerate of a channel close that does not need fee
 115         /// bumping, this is also used as an upper bound for our attempted feerate when doing cooperative
 116         /// closure of any channel.
 117         NonAnchorChannelFee,
 118         /// When cooperatively closing a channel, this is the minimum feerate we will accept.
 119         /// Recommended at least within a day or so worth of blocks.
 120         ///
 121         /// This will also be used when initiating a cooperative close of a channel. When closing a
 122         /// channel you can override this fee by using
 123         /// [`ChannelManager::close_channel_with_feerate_and_script`].
 124         ///
 125         /// [`ChannelManager::close_channel_with_feerate_and_script`]: crate::ln::channelmanager::ChannelManager::close_channel_with_feerate_and_script
 126         ChannelCloseMinimum,
 127         /// The feerate [`OutputSweeper`] will use on transactions spending
 128         /// [`SpendableOutputDescriptor`]s after a channel closure.
 129         ///
 130         /// Generally spending these outputs is safe as long as they eventually confirm, so a value
 131         /// (slightly above) the mempool minimum should suffice. However, as this value will influence
 132         /// how long funds will be unavailable after channel closure, [`FeeEstimator`] implementors
 133         /// might want to choose a higher feerate to regain control over funds faster.
 134         ///
 135         /// [`OutputSweeper`]: crate::util::sweep::OutputSweeper
 136         /// [`SpendableOutputDescriptor`]: crate::sign::SpendableOutputDescriptor
 137         OutputSpendingFee,
 138 }
 139
 140 /// A trait which should be implemented to provide feerate information on a number of time
 141 /// horizons.
 142 ///
 143 /// If access to a local mempool is not feasible, feerate estimates should be fetched from a set of
 144 /// third-parties hosting them. Note that this enables them to affect the propagation of your
 145 /// pre-signed transactions at any time and therefore endangers the safety of channels funds. It
 146 /// should be considered carefully as a deployment.
 147 ///
 148 /// Note that all of the functions implemented here *must* be reentrant-safe (obviously - they're
 149 /// called from inside the library in response to chain events, P2P events, or timer events).
 150 ///
 151 /// LDK may generate a substantial number of fee-estimation calls in some cases. You should
 152 /// pre-calculate and cache the fee estimate results to ensure you don't substantially slow HTLC
 153 /// handling.
 154 pub trait FeeEstimator {
 155         /// Gets estimated satoshis of fee required per 1000 Weight-Units.
 156         ///
 157         /// LDK will wrap this method and ensure that the value returned is no smaller than 253
 158         /// (ie 1 satoshi-per-byte rounded up to ensure later round-downs don't put us below 1 satoshi-per-byte).
 159         ///
 160         /// The following unit conversions can be used to convert to sats/KW:
 161         ///  * satoshis-per-byte * 250
 162         ///  * satoshis-per-kbyte / 4
 163         fn get_est_sat_per_1000_weight(&self, confirmation_target: ConfirmationTarget) -> u32;
 164 }
 165
 166 /// Minimum relay fee as required by bitcoin network mempool policy.
 167 pub const MIN_RELAY_FEE_SAT_PER_1000_WEIGHT: u64 = 4000;
 168 /// Minimum feerate that takes a sane approach to bitcoind weight-to-vbytes rounding.
 169 /// See the following Core Lightning commit for an explanation:
 170 /// <https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0>
 171 pub const FEERATE_FLOOR_SATS_PER_KW: u32 = 253;
 172
 173 /// Wraps a `Deref` to a `FeeEstimator` so that any fee estimations provided by it
 174 /// are bounded below by `FEERATE_FLOOR_SATS_PER_KW` (253 sats/KW).
 175 ///
 176 /// Note that this does *not* implement [`FeeEstimator`] to make it harder to accidentally mix the
 177 /// two.
 178 pub(crate) struct LowerBoundedFeeEstimator<F: Deref>(pub F) where F::Target: FeeEstimator;
 179
 180 impl<F: Deref> LowerBoundedFeeEstimator<F> where F::Target: FeeEstimator {
 181         /// Creates a new `LowerBoundedFeeEstimator` which wraps the provided fee_estimator
 182         pub fn new(fee_estimator: F) -> Self {
 183                 LowerBoundedFeeEstimator(fee_estimator)
 184         }
 185
 186         pub fn bounded_sat_per_1000_weight(&self, confirmation_target: ConfirmationTarget) -> u32 {
 187                 cmp::max(
 188                         self.0.get_est_sat_per_1000_weight(confirmation_target),
 189                         FEERATE_FLOOR_SATS_PER_KW,
 190                 )
 191         }
 192 }
 193
 194 #[cfg(test)]
 195 mod tests {
 196         use super::{FEERATE_FLOOR_SATS_PER_KW, LowerBoundedFeeEstimator, ConfirmationTarget, FeeEstimator};
 197
 198         struct TestFeeEstimator {
 199                 sat_per_kw: u32,
 200         }
 201
 202         impl FeeEstimator for TestFeeEstimator {
 203                 fn get_est_sat_per_1000_weight(&self, _: ConfirmationTarget) -> u32 {
 204                         self.sat_per_kw
 205                 }
 206         }
 207
 208         #[test]
 209         fn test_fee_estimator_less_than_floor() {
 210                 let sat_per_kw = FEERATE_FLOOR_SATS_PER_KW - 1;
 211                 let test_fee_estimator = &TestFeeEstimator { sat_per_kw };
 212                 let fee_estimator = LowerBoundedFeeEstimator::new(test_fee_estimator);
 213
 214                 assert_eq!(fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::AnchorChannelFee), FEERATE_FLOOR_SATS_PER_KW);
 215         }
 216
 217         #[test]
 218         fn test_fee_estimator_greater_than_floor() {
 219                 let sat_per_kw = FEERATE_FLOOR_SATS_PER_KW + 1;
 220                 let test_fee_estimator = &TestFeeEstimator { sat_per_kw };
 221                 let fee_estimator = LowerBoundedFeeEstimator::new(test_fee_estimator);
 222
 223                 assert_eq!(fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::AnchorChannelFee), sat_per_kw);
 224         }
 225 }