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

Require `RecipientOnionFields` in the claimable HTLC pipeline

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Require `RecipientOnionFields` in the claimable HTLC pipeline

We added `RecipientOnionFields` in the
`ClaimablePayment`/`ClaimingPayment` structs in 0.0.115/0.0.124,
always writing them for new HTLCs. As of 0.1, we do not support
upgrading from 0.0.123 or earlier with pending HTLCs to forward or
claim. Thus, we already don't support upgrading in cases where no
`RecipientOnionFields` is set and we can thus go ahead and mark it
as non-`Option`al.

Further, there's some super ancient upgrade logic in
`ChannelManager` deserialization we can remove at the same time.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit removes old backward-compatibility code in a Lightning network node library. It now requires a newer data field (RecipientOnionFields) when handling incoming payments and refuses to load very old saved state. The change is a cleanup that tightens data handling but does not by itself create a new security vulnerability.

Recommended action

Treat as a routine maintenance/cleanup commit. Reviewers should verify that the dropped upgrade paths are truly unsupported and that the new required field is always populated during deserialization and normal operation. No urgent security response is indicated by the diff alone.

Security signals we found

01

Removal of legacy deserialization paths reduces attack surface for malformed old-state serialization

02

Fixes initialization of ClaimablePayment.onion_fields from None to the real onion_fields value

03

Tightens TLV validation by requiring RecipientOnionFields instead of treating it as optional

04

No explicit security bug or CVE mentioned by the vendor

Risk score

Why this scored 26/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 2/15
Affected reach 4/15
Confidence 8/10
Evidence quality 4/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.