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

lnutil.ChannelType: rm "discard unknown" part from discard_unknown_and_check

Public commit record

What the developer wrote

Authored by SomberNight

81/100 · Strong
lnutil.ChannelType: rm "discard unknown" part from discard_unknown_and_check

This looks more dangerous than useful.
Added in [0], unclear what the original motivation was. Perhaps it was trying to discard the "variation flags" (46/50), which were already being discussed in a BOLTS PR [1] though not yet fully spec-ced out.

from https://github.com/lightning/bolts/blob/a3772650d8ebc06acf457fcadf97968ebfc4dfff/02-peer-protocol.md?plain=1#L811 :

> The sending node:
> - MUST set `channel_type`:
> - SHOULD NOT set it to a type containing a feature which was not negotiated.

[0]: https://github.com/spesmilo/electrum/commit/401a429080ec46960cb73e31f093f3970cc17683
[1]: https://github.com/lightning/bolts/pull/910
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit removes a helper that silently stripped unknown bits from Lightning channel-type flags during channel setup. Previously, if a peer sent a channel type containing an unrecognized flag, Electrum would drop that flag and continue. Now it keeps the full value and enforces that the peer's channel type exactly matches what Electrum expects and supports. This is a hardening change: it closes a path where a malicious or buggy peer could trick Electrum into accepting a channel type it did not actually agree to.

Recommended action

Treat as a security-hardening fix and include in release notes. Users running Lightning nodes should upgrade to a version containing this commit to avoid the risk of accepting a manipulated channel type. No immediate incident response is indicated absent evidence of active exploitation.

Security signals we found

01

Removed silent stripping of unknown channel_type bits

02

Added explicit equality check between local and remote channel_type

03

Added assertion that local channel_type complies with local features before sending

04

complies_with_features now validates flag combinations

05

Commit message describes prior behavior as 'more dangerous than useful'

Risk score

Why this scored 57/100

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