You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create SpendableOutputs events no matter the chain::Confirm order
We had a user who pointed out that we weren't creating
`SpendableOutputs` events when we should have been after they
called `ChannelMonitor::best_block_updated` with a block well
after a CSV locktime and then called
`ChannelMonitor::transactions_confirmed` with the transaction which
we should have been spending (with a block height/hash a ways in
the past).
This was due to `ChannelMonitor::transactions_confirmed` only
calling `ChannelMonitor::block_confirmed` with the height at which
the transactions were confirmed, resulting in all checks being done
against that, not the current height.
Further, in the same scenario, we also would not fail-back and HTLC
where the HTLC-Timeout transaction was confirmed more than
ANTI_REORG_DELAY blocks ago.
To address this, we use the best block height for confirmation
threshold checks in `ChannelMonitor::block_confirmed` and pass both
the confirmation and current heights through to
`OnchainTx::update_claims_view`, using each as appropriate.
Fixes#962.
/// Update state for new block(s)/transaction(s) confirmed. Note that the caller *must* update
2015
+
/// self.best_block before calling, and set `conf_height` to the height at which any new
2016
+
/// transaction(s)/block(s) were confirmed at, even if it is not the current best height
2017
+
/// (assuming we are being called with new transaction(s) confirmed).
2014
2018
fnblock_confirmed<B:Deref,F:Deref,L:Deref>(
2015
2019
&mutself,
2016
-
height:u32,
2020
+
conf_height:u32,
2017
2021
txn_matched:Vec<&Transaction>,
2018
2022
mutwatch_outputs:Vec<TransactionOutputs>,
2019
2023
mutclaimable_outpoints:Vec<PackageTemplate>,
2020
-
broadcaster:B,
2021
-
fee_estimator:F,
2022
-
logger:L,
2024
+
broadcaster:&B,
2025
+
fee_estimator:&F,
2026
+
logger:&L,
2023
2027
) -> Vec<TransactionOutputs>
2024
2028
where
2025
2029
B::Target:BroadcasterInterface,
2026
2030
F::Target:FeeEstimator,
2027
2031
L::Target:Logger,
2028
2032
{
2029
-
let should_broadcast = self.would_broadcast_at_height(height,&logger);
2033
+
let should_broadcast = self.would_broadcast_at_height(self.best_block.height(),logger);
2030
2034
if should_broadcast {
2031
2035
let funding_outp = HolderFundingOutput::build(self.funding_redeemscript.clone());
2032
-
let commitment_package = PackageTemplate::build_package(self.funding_info.0.txid.clone(),self.funding_info.0.indexasu32,PackageSolvingData::HolderFundingOutput(funding_outp), height,false, height);
2036
+
let commitment_package = PackageTemplate::build_package(self.funding_info.0.txid.clone(),self.funding_info.0.indexasu32,PackageSolvingData::HolderFundingOutput(funding_outp),self.best_block.height(),false,self.best_block.height());
/// (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.
344
344
/// Panics if there are signing errors, because signing operations in reaction to on-chain events
345
345
/// are not expected to fail, and if they do, we may lose funds.
log_debug!(logger,"Updating claims view at height {} with {} matched transactions and {} claim requests",height, txn_matched.len(), requests.len());
388
+
log_debug!(logger,"Updating claims view at height {} with {} matched transactions in block {} and {} claim requests",cur_height, txn_matched.len(), conf_height, requests.len());
log_info!(logger,"Delaying claim of package until its timelock at {} (current height {}), the following outpoints are spent:", req.package_timelock(),height);
407
+
if req.package_timelock() > cur_height + 1{
408
+
log_info!(logger,"Delaying claim of package until its timelock at {} (current height {}), the following outpoints are spent:", req.package_timelock(),cur_height);
0 commit comments