Set HolderCommitmentPoint::current_point on read
What the developer wrote
Authored by Jeffrey Czyz
Set HolderCommitmentPoint::current_point on read
When introducing HolderCommitmentPoint::current_point, the value was
mistakenly not set when read except in the legacy case where the next
point needed to be fetched. But in that case, it would have been read as
None given it is a new field.
What changed, and why it matters
This is a one-line bug fix in a Bitcoin Lightning Network library. A new field called `current_point` was added to track a cryptographic key for the current channel state, but when loading older saved channel data, the code accidentally left it blank (None) instead of restoring the saved value. This could cause the node to lose track of the correct key for the current commitment transaction, potentially leading to failures when signing or broadcasting channel state updates. It appears to be a data-corruption-on-upgrade bug rather than an obvious remote exploit.
Treat as a bug fix that should be included in any release containing the `HolderCommitmentPoint::current_point` field. Users running nodes with persisted channels should upgrade and monitor for channel-closure or signing errors. A security review should assess whether a missing `current_point` can be induced by an attacker or lead to loss of funds; the commit message does not frame this as a security issue.
Security signals we found
Incorrect deserialization of cryptographic key material
State mismatch between in-memory and on-disk channel state
Potential failure to sign or validate current commitment transactions
Upgrade/data-migration bug affecting persisted channels
Evidence from the diff
In lightning/src/ln/channel.rs, deserialization logic for HolderCommitmentPoint was setting current_point: None unconditionally when both legacy and new-format fields were present. The fix assigns holder_commitment_point_current_opt instead. current_point is used in commitment transaction key derivation; failing to restore it from disk means a loaded channel may have an inconsistent or missing current per-commitment point. This can break signing paths that expect current_point to match the actual current commitment number, especially after the field was introduced in a prior change.
Changed components
lightning/src/ln/channel.rsHolderCommitmentPoint deserializationChannel state persistence/read pathInspect captured patch +1 / −1
diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs
index 0328810..a30b3d5 100644
--- a/lightning/src/ln/channel.rs
+++ b/lightning/src/ln/channel.rs
@@ -13841,7 +13841,7 @@ where
match (holder_commitment_point_next_opt, holder_commitment_point_pending_next_opt) {
(Some(next_point), pending_next_point) => HolderCommitmentPoint {
next_transaction_number: holder_commitment_next_transaction_number,
- current_point: None,
+ current_point: holder_commitment_point_current_opt,
next_point,
pending_next_point,
},
Why this scored 52/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.