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

LNWallet: set OPT_ANCHOR_REQ for peer, rm config.ENABLE_ANCHOR_CHANNELS

Public commit record

What the developer wrote

Authored by SomberNight

95/100 · Strong
LNWallet: set OPT_ANCHOR_REQ for peer, rm config.ENABLE_ANCHOR_CHANNELS

- require the OPTION_ANCHORS peer feature
- rm the config.ENABLE_ANCHOR_CHANNELS config var, which some users might have set (maybe even forgot they did)
- instead add a new config.TEST_LN_OPEN_SRK_CHANNELS, explicitly for testing

---

As @f321x said, the intention is:
> This will prevent opening new outgoing and incoming SRK channels.
> It will also prevent connecting to peers that don't signal anchor support at all (INIT features), so existing channels to them would need to get force closed or the peer needs to be bullied into updating their node software.
> Existing SRK channels with peers that signal anchor support (e.g. SRK channel opened to Electrum Trampoline) remain usable.

However the part re preventing new incoming SRK channels is not correct AFAICT. I am fixing that in a later commit in the branch.
This is because, AFAIU BOLT-02, just because we negotiated OPTION_ANCHORS as a peer feature, setting channel_type to an SRK channel in open_channel is still technically valid.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit changes Electrum's Lightning wallet so it now requires anchor-style channels by default and removes the old user-facing setting that let people opt out. It replaces the opt-out with a hidden testing-only flag for older channel types. The change is a deliberate protocol hardening step, not a fix for an active exploit, though the commit message notes a follow-up is needed to fully block incoming old-style channels.

Recommended action

Review the follow-up commit that addresses the incoming channel_type check noted in the commit message, and ensure the new TEST_LN_OPEN_SRK_CHANNELS flag is not exposed in normal user interfaces. Consider documenting the rationale for deprecating static-remotekey-only channels.

Security signals we found

01

Removes a user-configurable setting that could downgrade channel security to pre-anchor (static-remotekey-only) channels

02

Makes anchor channel support mandatory in advertised LN features

03

Adds assertions that peers support anchor features before opening channels

04

Leaves a TODO about rejecting incoming non-anchor channel_type, indicating the change is partial

Risk score

Why this scored 34/100

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