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.
let should_broadcast = self.would_broadcast_at_height(self.best_block.height(), logger);
2030
2039
if should_broadcast {
2031
2040
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);
2041
+
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