Skip to content

funding: require explicit channel type in all negotiations - #11064

Open
NishantBansal2003 wants to merge 1 commit into
lightningnetwork:masterfrom
NishantBansal2003:explicit-chan-type
Open

funding: require explicit channel type in all negotiations #11064
NishantBansal2003 wants to merge 1 commit into
lightningnetwork:masterfrom
NishantBansal2003:explicit-chan-type

Conversation

@NishantBansal2003

Copy link
Copy Markdown
Contributor

Currently, BOLT assumes ExplicitChannelType, and LND sends it as required (#9637). However, when receiving an OpenChannel from peer, LND doesn’t enforce an explicit ChannelType and falls back to implicit negotiation, even though both peers have negotiated ExplicitChannelType. According to BOLT 2, I think we should fail the funding flow if ChannelType is omitted when both peers have negotiated ExplicitChannelType.

This bug was discovered while fuzzing the funding flow using the smite

@github-actions github-actions Bot added the severity-critical Requires expert review - security/consensus critical label Aug 12, 2026
@github-actions

Copy link
Copy Markdown

🔴 PR Severity: CRITICAL

gh pr view | 2 files | 126 lines changed

🔴 Critical (1 file)
  • funding/manager.go - modifies channel funding workflow coordination (enforces explicit channel type negotiation per BOLT 2)
🟢 Low (1 file)
  • funding/manager_test.go - test-only change, excluded from severity calculation

Analysis

This PR changes funding/manager.go, which coordinates the channel funding workflow — a category that always requires expert review due to its direct impact on channel open/funding correctness and security. The change enforces that ChannelType must be explicitly set when both peers have negotiated ExplicitChannelType, closing a gap where LND would otherwise silently fall back to implicit channel type negotiation. The change is small (15 non-test lines) and scoped to a single file, so no severity bump was applied beyond the inherent CRITICAL classification of the funding/* package.


To override, add a severity-override-{critical,high,medium,low} label.

@ziggie1984

Copy link
Copy Markdown
Collaborator

We should remove implicit channel-type negotiation instead of gating this validation on option_channel_type. The feature is now ASSUMED, and BOLT 2 unconditionally requires channel_type in both open_channel and accept_channel. Implementations may therefore stop advertising bits 44/45, causing this condition to evaluate to false and incorrectly re-enable the obsolete implicit fallback.

Please require msg.ChannelType unconditionally here and remove the implicit wire-negotiation paths. LND may retain a local default-selection helper when the RPC caller does not request a specific type, but the selected type must always be sent explicitly and echoed by the peer.

@ziggie1984

Copy link
Copy Markdown
Collaborator

When removing the implicit negotiation paths, we should keep the backward-compatibility implications in mind. In particular, removing implicit negotiation should be separate from removing the option_channel_type advertisement.

Continuing to advertise bit 44 allows older LND versions that understand explicit channel types to enter their explicit path and send/echo channel_type. If we stop advertising the bit at the same time, those versions may fall back to implicit behavior: an older funder may omit channel_type, while an older fundee may not echo the type sent by the new node. Both flows would then fail against the new strict validation.

I suggest always requiring, sending, and echoing channel_type, while temporarily retaining ExplicitChannelTypeRequired in our feature set for compatibility. The remaining implicit helper can be converted into a local default-type selector rather than used as wire-level negotiation. Existing channels are unaffected because their commitment type is persisted and not renegotiated.

Move from optional implicit negotiation to mandatory explicit
channel type in OpenChannel and AcceptChannel. The returned
ChannelType is now always non-nil.

Channel type is required in all negotiations now. We only
fallback to a default channel type when the RPC caller does
not explicitly specify one.

Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
@NishantBansal2003 NishantBansal2003 changed the title funding: enforce explicit channel type when negotiated funding: require explicit channel type in all negotiations Aug 13, 2026
@NishantBansal2003

Copy link
Copy Markdown
Contributor Author

We should remove implicit channel-type negotiation instead of gating this validation on option_channel_type. The feature is now ASSUMED, and BOLT 2 unconditionally requires channel_type in both open_channel and accept_channel. Implementations may therefore stop advertising bits 44/45, causing this condition to evaluate to false and incorrectly re-enable the obsolete implicit fallback.

Wanted to do that in the first place, since all the other implementations currently do this, but I was unsure why it wasn’t done in: #9637. Anyway, in the latest commit, I did the following:

  • Removed all implicit channel type negotiation paths and made the channel type required in both open_channel and accept_channel
  • If the RPC caller does not specify a channel type, we fall back to the default channel type, which is how the implicit negotiation worked previously.
  • The channel type in our reservation should always be present, so I removed all other implicit or nil channel type paths.

NishantBansal2003 added a commit to NishantBansal2003/smite that referenced this pull request Aug 13, 2026
LND allows `open_channel` with an omitted `channel_type`,
violating BOLT 2 even though it signals the required
`option_channel_type` feature bit. This will be tracked
upstream and will be suppressed until fixed.

see: lightningnetwork/lnd#11064

Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
NishantBansal2003 added a commit to NishantBansal2003/smite that referenced this pull request Aug 13, 2026
LND allows `open_channel` with an omitted `channel_type`,
violating BOLT 2 even though it signals the required
`option_channel_type` feature bit. This will be tracked
upstream and will be suppressed until fixed.

see: lightningnetwork/lnd#11064

Signed-off-by: Nishant Bansal <nishant.bansal.282003@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

channels severity-critical Requires expert review - security/consensus critical

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants