From: Antoine Riard Date: Tue, 18 Feb 2020 18:11:56 +0000 (-0500) Subject: Comment better get_height_timer logic. X-Git-Tag: v0.0.12~110^2~1 X-Git-Url: http://git.bitcoin.ninja/?a=commitdiff_plain;h=e8cb0762679e239cfbb9678223ad57257f5b5c01;p=rust-lightning Comment better get_height_timer logic. Height timer as an important component of a more-secure, fee-sensitive claiming of time-constrained LN outputs, therefore document assumptions. --- diff --git a/lightning/src/ln/onchaintx.rs b/lightning/src/ln/onchaintx.rs index 1166696f9..bbab04ac8 100644 --- a/lightning/src/ln/onchaintx.rs +++ b/lightning/src/ln/onchaintx.rs @@ -316,6 +316,11 @@ impl OnchainTxHandler { tx_weight } + /// In LN, output claimed are time-sensitive, which means we have to spend them before reaching some timelock expiration. At in-channel + /// output detection, we generate a first version of a claim tx and associate to it a height timer. A height timer is an absolute block + /// height than once reached we should generate a new bumped "version" of the claim tx to be sure than we safely claim outputs before + /// than our counterparty can do it too. If timelock expires soon, height timer is going to be scale down in consequence to increase + /// frequency of the bump and so increase our bets of success. fn get_height_timer(current_height: u32, timelock_expiration: u32) -> u32 { if timelock_expiration <= current_height + 3 { return current_height + 1 @@ -390,6 +395,8 @@ impl OnchainTxHandler { } } + // Compute new height timer to decide when we need to regenerate a new bumped version of the claim tx (if we + // didn't receive confirmation of it before, or not enough reorg-safe depth on top of it). let new_timer = Self::get_height_timer(height, cached_claim_datas.soonest_timelock); let mut inputs_witnesses_weight = 0; let mut amt = 0;