funding: require explicit channel type in all negotiations

[NishantBansal2003]

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]

🔴 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]

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]

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.

[NishantBansal2003]

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.

[MPins]

Agreed with @ziggie1984 .

The flip side is that the advertisement is now a prerequisite of this change rather than an independent feature flag: dropping that line silently breaks the funding flow against older peers, so a short note there would be cheap insurance:

	// NOTE: Funding requires an explicit channel type, and older peers only
	// enter their explicit path when we advertise this. Removing this bit
	// breaks the funding flow against them until those versions age out.
	lnwire.ExplicitChannelTypeRequired: {
		SetInit:    {}, // I
		SetNodeAnn: {}, // N
	},

[MPins]

nit: the var block only existed because the assignment lived inside the chanType != nil guard.

[MPins]

nit: the var block only existed because the assignment lived inside the chanType != nil guard.

[MPins]

nit — about regression robustness, not the change itself.

The message omits all six pubkeys, so this check is the only thing preventing a nil deref further down. Removing it locally doesn't fail the test: it panics in copyPubKey and takes the binary down.