From bb0e33f383a99a0d2642b5bdae532e24cfdee1f5 Mon Sep 17 00:00:00 2001 From: Antoine Riard Date: Mon, 26 Apr 2021 18:22:53 -0400 Subject: [PATCH] Move get_height_timer out of OnchainTxHandler --- lightning/src/chain/onchaintx.rs | 16 +--------------- lightning/src/chain/package.rs | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 15 deletions(-) diff --git a/lightning/src/chain/onchaintx.rs b/lightning/src/chain/onchaintx.rs index 131caff7..ca86864e 100644 --- a/lightning/src/chain/onchaintx.rs +++ b/lightning/src/chain/onchaintx.rs @@ -332,20 +332,6 @@ impl OnchainTxHandler { } } - /// 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 - } else if timelock_expiration - current_height <= 15 { - return current_height + 3 - } - current_height + 15 - } - /// Lightning security model (i.e being able to redeem/timeout HTLC or penalize coutnerparty onchain) lays on the assumption of claim transactions getting confirmed before timelock expiration /// (CSV or CLTV following cases). In case of high-fee spikes, claim tx may stuck in the mempool, so you need to bump its feerate quickly using Replace-By-Fee or Child-Pay-For-Parent. /// Panics if there are signing errors, because signing operations in reaction to on-chain events @@ -358,7 +344,7 @@ 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 = Some(Self::get_height_timer(height, cached_request.timelock())); + let new_timer = Some(cached_request.get_height_timer(height)); let amt = cached_request.package_amount(); if cached_request.is_malleable() { let predicted_weight = cached_request.package_weight(&self.destination_script); diff --git a/lightning/src/chain/package.rs b/lightning/src/chain/package.rs index 49a01ebf..008da5d2 100644 --- a/lightning/src/chain/package.rs +++ b/lightning/src/chain/package.rs @@ -49,6 +49,13 @@ pub(crate) const WEIGHT_RECEIVED_HTLC: u64 = 1 + 1 + 73 + 1 + 1 + 1 + 139; // number_of_witness_elements + sig_length + revocation_sig + true_length + op_true + witness_script_length + witness_script pub(crate) const WEIGHT_REVOKED_OUTPUT: u64 = 1 + 1 + 73 + 1 + 1 + 1 + 77; +/// Height delay at which transactions are fee-bumped/rebroadcasted with a low priority. +const LOW_FREQUENCY_BUMP_INTERVAL: u32 = 15; +/// Height delay at which transactions are fee-bumped/rebroadcasted with a middle priority. +const MIDDLE_FREQUENCY_BUMP_INTERVAL: u32 = 3; +/// Height delay at which transactions are fee-bumped/rebroadcasted with a high priority. +const HIGH_FREQUENCY_BUMP_INTERVAL: u32 = 1; + /// A struct to describe a revoked output and corresponding information to generate a solving /// witness spending a commitment `to_local` output or a second-stage HTLC transaction output. /// @@ -634,6 +641,19 @@ impl PackageTemplate { }, } } + /// 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 that once reached we should generate a new bumped "version" of the claim tx to be sure that we safely claim outputs before + /// that our counterparty can do so. If timelock expires soon, height timer is going to be scaled down in consequence to increase + /// frequency of the bump and so increase our bets of success. + pub(crate) fn get_height_timer(&self, current_height: u32) -> u32 { + if self.soonest_conf_deadline <= current_height + MIDDLE_FREQUENCY_BUMP_INTERVAL { + return current_height + HIGH_FREQUENCY_BUMP_INTERVAL + } else if self.soonest_conf_deadline - current_height <= LOW_FREQUENCY_BUMP_INTERVAL { + return current_height + MIDDLE_FREQUENCY_BUMP_INTERVAL + } + current_height + LOW_FREQUENCY_BUMP_INTERVAL + } pub (crate) fn build_package(txid: Txid, vout: u32, input_solving_data: PackageSolvingData, soonest_conf_deadline: u32, aggregable: bool, height_original: u32) -> Self { let malleability = match input_solving_data { PackageSolvingData::RevokedOutput(..) => { PackageMalleability::Malleable }, @@ -810,3 +830,4 @@ pub(crate) fn compute_output_value(predicted_weight: usize, } None } + -- 2.30.2