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

lightningd: always tell openingd/dualopend what channel type we want.

Public commit record

What the developer wrote

Authored by Rusty Russell

73/100 · Adequate
lightningd: always tell openingd/dualopend what channel type we want.

Prior to it being compulsory, these daemons would need a default value. Now it's
always required, it's clearer if it's always told.

There's no "default_channel_type" now everyone has to specify channel_type either,
so rename it to "desired_channel_type" and put it in lightningd specifically.

Note that the channel_type can have options added: either option_scid_alias or option_zeroconf.

This results in a slight behavior change: we will get type zeroconf even if we didn't ask for it, if they gave it to us.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-Changed: JSON-RPC: fundchannel / fundchannel_start returned `channel_type` will include option_zeroconf if it was implied by a 0 minimum_depth, even if we didn't explicitly ask for a zero conf channel.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how Core Lightning decides what kind of channel to open with another node. Previously, the opening daemon could fall back to a default channel type if none was specified. Now, the main lightningd process always picks and sends a specific desired channel type. A side effect is that if the peer signals support for zero-confirmation channels (by setting minimum_depth to 0), the returned channel type will include the zeroconf feature even if the user did not ask for it. The commit is described as a behavior change, not a security fix, and there is no evidence of a disclosed vulnerability.

Recommended action

Treat as a normal feature/behavior change. Review whether automatically including option_zeroconf based on peer minimum_depth is acceptable for your deployment's trust model, as it changes user-visible RPC output and channel semantics. No urgent security patch appears warranted based on the supplied materials.

Security signals we found

01

Behavior change in channel type negotiation: zeroconf now implied by peer's minimum_depth=0 even if not explicitly requested

02

Channel type field made mandatory in inter-daemon wire messages, removing silent defaults

03

SCID_ALIAS now added based on feature negotiation plus unannounced flag, not only when default channel type was used

04

No bounds checks, memory safety fixes, or authentication changes visible in diff

Risk score

Why this scored 27/100

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