Merge pull request #1401 from TheBlueMatt/2022-02-0conf-round-two

[rust-lightning] / lightning / src / util / config.rs

diff --git a/lightning/src/util/config.rs b/lightning/src/util/config.rs
index 3868d29aab49f66789c49c970a662cba19000e2e..bdd222e31c58f0ab921ae2f3f057d8264b68b560 100644 (file)
--- a/lightning/src/util/config.rs
+++ b/lightning/src/util/config.rs
@@ -22,7 +22,15 @@ pub struct ChannelHandshakeConfig {
        /// Applied only for inbound channels (see ChannelHandshakeLimits::max_minimum_depth for the
        /// equivalent limit applied to outbound channels).
        ///
+       /// A lower-bound of 1 is applied, requiring all channels to have a confirmed commitment
+       /// transaction before operation. If you wish to accept channels with zero confirmations, see
+       /// [`UserConfig::manually_accept_inbound_channels`] and
+       /// [`ChannelManager::accept_inbound_channel_from_trusted_peer_0conf`].
+       ///
        /// Default value: 6.
+       ///
+       /// [`ChannelManager::accept_inbound_channel`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel
+       /// [`ChannelManager::accept_inbound_channel_from_trusted_peer_0conf`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel_from_trusted_peer_0conf
        pub minimum_depth: u32,
        /// Set to the number of blocks we require our counterparty to wait to claim their money (ie
        /// the number of blocks we have to punish our counterparty if they broadcast a revoked
@@ -159,6 +167,24 @@ pub struct ChannelHandshakeLimits {
        ///
        /// Default value: 144, or roughly one day and only applies to outbound channels.
        pub max_minimum_depth: u32,
+       /// Whether we implicitly trust funding transactions generated by us for our own outbound
+       /// channels to not be double-spent.
+       ///
+       /// If this is set, we assume that our own funding transactions are *never* double-spent, and
+       /// thus we can trust them without any confirmations. This is generally a reasonable
+       /// assumption, given we're the only ones who could ever double-spend it (assuming we have sole
+       /// control of the signing keys).
+       ///
+       /// You may wish to un-set this if you allow the user to (or do in an automated fashion)
+       /// double-spend the funding transaction to RBF with an alternative channel open.
+       ///
+       /// This only applies if our counterparty set their confirmations-required value to 0, and we
+       /// always trust our own funding transaction at 1 confirmation irrespective of this value.
+       /// Thus, this effectively acts as a `min_minimum_depth`, with the only possible values being
+       /// `true` (0) and `false` (1).
+       ///
+       /// Default value: true
+       pub trust_own_funding_0conf: bool,
        /// Set to force an incoming channel to match our announced channel preference in
        /// [`ChannelConfig::announced_channel`].
        ///
@@ -187,6 +213,7 @@ impl Default for ChannelHandshakeLimits {
                        min_max_htlc_value_in_flight_msat: 0,
                        max_channel_reserve_satoshis: <u64>::max_value(),
                        min_max_accepted_htlcs: 0,
+                       trust_own_funding_0conf: true,
                        max_minimum_depth: 144,
                        force_announced_channel_preference: true,
                        their_to_self_delay: MAX_LOCAL_BREAKDOWN_TIMEOUT,