Assume option_channel_type

[t-bast]

This feature has become more and more useful as we've introduced various channel commitment formats, and has been introduced more than 3 years ago in #880. It should be safe to assume that every implementation sets this TLV fields?

We also add a new context type T for features that can be included in the channel_type field when opening channels in the second commit.

[TheBlueMatt]

Hell yea

[morehouse]

There's a bunch of "default channel type" logic that we should also remove from the funding_signed requirements.

[t-bast]

There's a bunch of "default channel type" logic that we should also remove from the funding_signed requirements.

Indeed, I missed a lot of places where channel_type is mentioned, I'll add more changes!

[Roasbeef]

Wouldn't the first step here be for everyone to first start to set the required feature bit? That's the existing mechanism we have in the protocol to change something from optional to mandatory. Compared to this PR, it's explicit and unambiguous.

[t-bast]

Wouldn't the first step here be for everyone to first start to set the required feature bit? That's the existing mechanism we have in the protocol to change something from optional to mandatory. Compared to this PR, it's explicit and unambiguous.

Opening this PR is the first step to get the discussion started! So yes, we should definitely start setting it as mandatory. But it's also trivial to look at the network's data and see if there are nodes that don't set it yet: if everyone already sets this, we know we can start assuming it. I'll collect that data today and will report back.

[t-bast]

There is only one node with a node_announcement generated in 2025 that doesn't support option_channel_type: https://mempool.space/lightning/node/03f7cc801b3ddfc1ad5b445f084ffd61fb0605a7465fcf50b6ccb389e50b32262a

Since this node has only 1 small channel, I think we can safely ignore this and consider that every active node on the network does support option_channel_type.

[rustyrussell]

I'm happy to set it as compulsory in the CLN 25.05 release. We added this in 0.12.0 (2022-08-23), though there were fixes as late as 24.02. Either way that's well outside our support window.

[rustyrussell]

However, there are about 2600 nodes which still don't advertize support. Those versions are all well out-of-date though, so those results may be false. Further analysis required.

For example, some nodes haven't sent out a channel update in years. Their channels are kept alive by their peers retransmitting (in some cases, with the disabled flag set). CLN has logic to not create refresh channel_update messages for disabled channels, maybe this should be in the spec? That would allow these channels (and thus nodes) to vanish from the graph naturally.

Though really, closing uncontactable channels after a year would also be a decent spec update!

Consider:

https://mempool.space/lightning/node/03c918ba3e2fd8207bf4c54a546e5b7e60bd4148a805905e7f701b1095318def0c

It seems like its peers are keeping it alive by refreshing the channel_update. But I'd guess they haven't heard from it in months / years, so they shouldn't?

[t-bast]

What I find surprising is why those channels aren't closed: if your peer has been unavailable for months, you should close channels with them to claim your funds back and reallocate them? If implementations aggressively prompted node operators to do so (or automated that task) that would fix the issue entirely.

[TheBlueMatt]

You assume a lot about how actively most nodes are maintained...

[Roasbeef]

LGTM 🏷️