AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 29 Bitcoin

Combine claimable HTLCs with purposes in ChannelManagerData

Public commit record

What the developer wrote

Authored by Joost Jager

83/100 · Strong
Combine claimable HTLCs with purposes in ChannelManagerData

Move the reconstruction of claimable_payments from the main
ChannelManager::read into ChannelManagerData::read. This removes
the separate claimable_htlc_purposes and claimable_htlc_onion_fields
fields from ChannelManagerData, replacing them with the combined
claimable_payments HashMap.

This requires adding a node_signer parameter to ChannelManagerDataReadArgs
to support verification of legacy hop data when reconstructing payment
purposes for very old serialized data (pre-0.0.107).

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a code-cleanup refactor that moves the reconstruction of claimable payment data from one deserialization function to another. It does not change the underlying security logic but reorganizes how legacy payment records are verified when loading old wallet state. There is no direct evidence in the commit that this fixes an active security vulnerability.

Recommended action

Treat as a normal maintenance refactor. Reviewers should verify that the moved duplicate-payment-hash and empty-HTLC-list checks remain intact, and that the new `node_signer` lifetime does not introduce borrow issues. No urgent security response is indicated by the diff alone.

Security signals we found

01

Refactor of deserialization path for claimable HTLCs/payments

02

Addition of node_signer to ChannelManagerDataReadArgs to verify legacy hop data during read

03

Preservation of existing inbound_payment::verify checks for pre-0.0.107 serialized data

04

No new cryptographic operations or trust assumptions introduced in the diff

Risk score

Why this scored 29/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 5/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.