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

Correctly handle unknown flags in `channel_update` (#3341)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

98/100 · Strong
Correctly handle unknown flags in `channel_update` (#3341)

We previously ignored unknown `channel_flags` and `message_flags` in
the channel updates we received at decoding time, which means we would
always replace them by `0` when re-encoding the channel update before
forwarding it. If a flag that we don't understand was set to `1`, the
signature becomes invalid.

In order to be future-proof, we must preserve the values of unknown
flags during a codec round-trip: this way old eclair nodes will still
correctly relay future channel updates that contain flags that haven't
yet been specified.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a bug in how Eclair handled unknown flag bits in Lightning 'channel_update' messages. Previously, the software silently cleared any flag bits it did not recognize when re-encoding a message before forwarding it. Because those flag bits are part of the signed data, clearing them made the digital signature invalid. The fix now preserves all unknown flag bits through a decode-encode round trip, so older Eclair nodes can still correctly relay future channel updates that use newly defined flags.

Recommended action

Treat this as a protocol-forward-compatibility and denial-of-service-prevention fix. Nodes running the old code would drop or propagate invalid channel updates once future BOLT specifications define new flag bits, so upgrading is recommended. Review whether any persisted channel-update data decoded under the old codec lost unknown bits and may need re-validation from the network.

Security signals we found

01

Signature invalidation through lossy codec round-trip

02

Unknown protocol flag bits silently zeroed before forwarding

03

Future protocol compatibility / forward-compatibility fix

04

BOLT 7 channel_update message handling

05

Test added for unknown flags preserving signature validity

Risk score

Why this scored 64/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 12/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.