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 from the received OpenChannel message and echo the same channel type (if valid) in AcceptChannel.

So, we should remove implicit negotiation entirely. If the RPC caller doesn’t request a channel type, a default should be derived from both peers' features and signaled explicitly.

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.

[NishantBansal2003]

Thanks, good point, I added those keys in the latest push

[MPins]

I've been building a coverage-guided fuzz harness for the funding manager, and added oracles for BOLT 2's channel_type requirements — checking what lnd emits against the spec text, rather than against what the lnd on the other end expects. Against master it reaches three divergences, all fixed by this PR:

1. Peer omits channel_type while option_channel_type is negotiated. BOLT 2 says the receiver must fail the channel. Master instead falls back to its default selection and puts that invented type in accept_channel — which a conforming funder must reject, the echo having to match what it sent.

2. Peer advertises neither bit 44 nor 45 but sends channel_type, as current BOLT 2 requires of it, the field no longer being feature-gated. Master accepts the channel and omits the echo entirely.

3. Same peer, lnd funding. Master's own open_channel goes out with no channel_type.

For now these are logged rather than fatal, so the fuzzer can keep running against master — it otherwise stops within seconds and reaches nothing else. The must-reject check for case 1 is commented out as well; the case still surfaces,
but through the echo oracle, as the invented type in accept_channel. Each spot carries a TODO to restore the hard assertion once this lands. The remaining channel_type oracles stay armed — master already enforces the funder-side
checks on accept_channel, and those pass.

All three pass with this branch applied.

[MPins]

LGTM 🎉

Verified the test fix does what it was meant to: with the check removed, the package now fails as expected, instead of panicking in copyPubKey and taking the binary down.

Two non-code leftovers before this lands: missing the release notes and the PR description, which still describe the conditional design "I think we should fail the funding flow if ChannelType is omitted when both peers have negotiated ExplicitChannelType".