Update OnchainTxHandler channel parameters on renegotiated funding locked
What the developer wrote
Authored by Wilmer Paulino
Update OnchainTxHandler channel parameters on renegotiated funding locked
The `ChannelMonitor` now tracks its own set of channel parameters, but
in the event they change after a splice, we want to ensure they are
updated accordingly at the `OnchainTxHandler` level as well in case the
user downgrades after a locked splice has already occurred.
What changed, and why it matters
This commit fixes an internal bookkeeping issue in a Bitcoin Lightning Network library. After a channel is resized via 'splicing,' the on-chain emergency transaction handler was not being told about the new channel's size and parameters. If a user later ran older software that relied on that handler, it could operate with stale information, potentially creating invalid or uneconomic rescue transactions. There is no direct evidence this is remotely exploitable by an attacker.
Treat as a correctness fix worth including in the next maintenance release, especially for users experimenting with splicing. No urgent hotfix is indicated absent a demonstrated exploit path.
Security signals we found
Stale channel parameters after splice could lead to incorrect on-chain transaction construction
Downgrade scenario explicitly mentioned by commit author
Fix is a data-flow completeness patch rather than a memory-safety or cryptographic bug
Evidence from the diff
ChannelMonitorImpl now passes its own copy of ChannelTransactionParameters into OnchainTxHandler::update_after_renegotiated_funding_locked() after a renegotiated funding transaction is locked (e.g., post-splice). The handler then updates channel_value_satoshis and channel_transaction_parameters in addition to the holder commitment transactions. Previously only the commitment transactions were refreshed, so a downgrade or code path that used the handler’s cached parameters could use pre-splice values.
Changed components
lightning/src/chain/channelmonitor.rslightning/src/chain/onchaintx.rsOnchainTxHandler::update_after_renegotiated_funding_lockedInspect captured patch +7 / −3
diff --git a/lightning/src/chain/channelmonitor.rs b/lightning/src/chain/channelmonitor.rs
index d0aa0ee..863439b 100644
--- a/lightning/src/chain/channelmonitor.rs
+++ b/lightning/src/chain/channelmonitor.rs
@@ -4049,6 +4049,7 @@ impl<Signer: EcdsaChannelSigner> ChannelMonitorImpl<Signer> {
mem::swap(&mut self.funding, &mut new_funding);
self.onchain_tx_handler.update_after_renegotiated_funding_locked(
+ self.funding.channel_parameters.clone(),
self.funding.current_holder_commitment_tx.clone(),
self.funding.prev_holder_commitment_tx.clone(),
);
diff --git a/lightning/src/chain/onchaintx.rs b/lightning/src/chain/onchaintx.rs
index 4a35c7b..f7f9abf 100644
--- a/lightning/src/chain/onchaintx.rs
+++ b/lightning/src/chain/onchaintx.rs
@@ -1236,11 +1236,14 @@ impl<ChannelSigner: EcdsaChannelSigner> OnchainTxHandler<ChannelSigner> {
self.prev_holder_commitment = Some(replace(&mut self.holder_commitment, tx));
}
- /// Replaces the current/prev holder commitment transactions spending the currently confirmed
- /// funding outpoint with those spending the new funding outpoint.
+ /// Replaces all the data pertaining to the currently locked funding transaction after a new
+ /// funding transaction has been renegotiated and locked.
pub(crate) fn update_after_renegotiated_funding_locked(
- &mut self, current: HolderCommitmentTransaction, prev: Option<HolderCommitmentTransaction>,
+ &mut self, channel_parameters: ChannelTransactionParameters,
+ current: HolderCommitmentTransaction, prev: Option<HolderCommitmentTransaction>,
) {
+ self.channel_value_satoshis = channel_parameters.channel_value_satoshis;
+ self.channel_transaction_parameters = channel_parameters;
self.holder_commitment = current;
self.prev_holder_commitment = prev;
}
Why this scored 41/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.