X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning%2Fsrc%2Futil%2Fconfig.rs;h=4a66fa37a8cd7334058042e30a6d0922eef42d93;hb=2eb7db9ace08b57bfedbdac2b26961897b032e0b;hp=a288caf460b943e3f45de1ee8a41bfd7161df442;hpb=c8d4536b3e4baa94590ca43bc39cff2cc85e96e1;p=rust-lightning diff --git a/lightning/src/util/config.rs b/lightning/src/util/config.rs index a288caf46..4a66fa37a 100644 --- a/lightning/src/util/config.rs +++ b/lightning/src/util/config.rs @@ -23,18 +23,21 @@ pub struct ChannelHandshakeConfig { /// /// Default value: 6. pub minimum_depth: u32, - /// Set to the amount of time we require our counterparty to wait to claim their money. + /// 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 + /// transaction). /// - /// It's one of the main parameter of our security model. We (or one of our watchtowers) MUST - /// be online to check for peer having broadcast a revoked transaction to steal our funds - /// at least once every our_to_self_delay blocks. + /// This is one of the main parameters of our security model. We (or one of our watchtowers) MUST + /// be online to check for revoked transactions on-chain at least once every our_to_self_delay + /// blocks (minus some margin to allow us enough time to broadcast and confirm a transaction, + /// possibly with time in between to RBF the spending transaction). /// /// Meanwhile, asking for a too high delay, we bother peer to freeze funds for nothing in /// case of an honest unilateral channel close, which implicitly decrease the economic value of /// our channel. /// - /// Default value: [`BREAKDOWN_TIMEOUT`] (currently 144), we enforce it as a minimum at channel - /// opening so you can tweak config to ask for more security, not less. + /// Default value: [`BREAKDOWN_TIMEOUT`], we enforce it as a minimum at channel opening so you + /// can tweak config to ask for more security, not less. pub our_to_self_delay: u16, /// Set to the smallest value HTLC we will accept to process. /// @@ -95,22 +98,6 @@ pub struct ChannelHandshakeLimits { /// /// Default value: 0. pub min_max_accepted_htlcs: u16, - /// Outputs below a certain value will not be added to on-chain transactions. The dust value is - /// required to always be higher than this value so this only applies to HTLC outputs (and - /// potentially to-self outputs before any payments have been made). - /// Thus, HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain. - /// This setting allows you to set a minimum dust limit for their commitment transactions, - /// reflecting the reality that tiny outputs are not considered standard transactions and will - /// not propagate through the Bitcoin network. - /// - /// Default value: 546, the current dust limit on the Bitcoin network. - pub min_dust_limit_satoshis: u64, - /// Maximum allowed threshold above which outputs will not be generated in their commitment - /// transactions. - /// HTLCs below this amount plus HTLC transaction fees are not enforceable on-chain. - /// - /// Default value: u64::max_value. - pub max_dust_limit_satoshis: u64, /// Before a channel is usable the funding transaction will need to be confirmed by at least a /// certain number of blocks, specified by the node which is not the funder (as the funder can /// assume they aren't going to double-spend themselves). @@ -142,8 +129,6 @@ impl Default for ChannelHandshakeLimits { min_max_htlc_value_in_flight_msat: 0, max_channel_reserve_satoshis: ::max_value(), min_max_accepted_htlcs: 0, - min_dust_limit_satoshis: 546, - max_dust_limit_satoshis: ::max_value(), max_minimum_depth: 144, force_announced_channel_preference: true, their_to_self_delay: MAX_LOCAL_BREAKDOWN_TIMEOUT, @@ -220,7 +205,7 @@ impl Default for ChannelConfig { } //Add write and readable traits to channelconfig -impl_writeable!(ChannelConfig, 8+2+1+1, { +impl_writeable!(ChannelConfig, 4+2+1+1, { fee_proportional_millionths, cltv_expiry_delta, announced_channel,