lightningd: make option_channel_type compulsory.
What the developer wrote
Authored by Rusty Russell
lightningd: make option_channel_type compulsory.
As per BOLT recommendation https://github.com/lightning/bolts/pull/1232, this means
we will insist on this being available.
For CLN, 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.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Closes: https://github.com/ElementsProject/lightning/issues/8152
Changelog-Changed: Protocol: We now insist that peers support `option_channel_type` (in CLN since 0.12.0 in late 2022, similar for other implementations).
What changed, and why it matters
This change makes a Lightning protocol feature called 'option_channel_type' mandatory instead of optional. It tells peers that Core Lightning will now require them to support this feature, which has been widely available since 2022. This is a protocol compatibility change, not a fix for an active security flaw, but it removes a path where older or non-standard peers could negotiate channels without this feature.
No immediate action required. Operators should ensure peers run implementations supporting option_channel_type (available since CLN 0.12.0 and comparable versions in other implementations). Review compatibility impact if connecting to very old nodes.
Security signals we found
Protocol hardening: makes option_channel_type mandatory per BOLT recommendation
Feature bit changed from odd/optional to even/compulsory
Removes support for peers that do not implement option_channel_type
No vulnerability, crash, or memory safety fix present in diff
Evidence from the diff
The commit changes OPT_CHANNEL_TYPE from OPTIONAL_FEATURE to COMPULSORY_FEATURE in default_features(). This flips the feature bit from odd (43) to even (44), signaling that peers must support option_channel_type. Test expectations are updated accordingly. The change follows BOLT PR 1232 and is intended to harden channel negotiation by requiring explicit channel type agreement.
Changed components
lightningd/lightningd.c default_features()tests/test_misc.pytests/utils.pyInspect captured patch +4 / −4
diff --git a/lightningd/lightningd.c b/lightningd/lightningd.c
index b75a3087..0d7faa0d 100644
--- a/lightningd/lightningd.c
+++ b/lightningd/lightningd.c
@@ -926,7 +926,7 @@ static struct feature_set *default_features(const tal_t *ctx)
OPTIONAL_FEATURE(OPT_ZEROCONF),
OPTIONAL_FEATURE(OPT_QUIESCE),
OPTIONAL_FEATURE(OPT_ONION_MESSAGES),
- OPTIONAL_FEATURE(OPT_CHANNEL_TYPE),
+ COMPULSORY_FEATURE(OPT_CHANNEL_TYPE),
OPTIONAL_FEATURE(OPT_ROUTE_BLINDING),
OPTIONAL_FEATURE(OPT_PROVIDE_STORAGE),
/* Removed later for elements */
diff --git a/tests/test_misc.py b/tests/test_misc.py
index ed6ff389..5f2ffb39 100644
--- a/tests/test_misc.py
+++ b/tests/test_misc.py
@@ -2405,7 +2405,7 @@ def test_list_features_only(node_factory):
'option_quiesce/odd',
'option_onion_messages/odd',
'option_provide_storage/odd',
- 'option_channel_type/odd',
+ 'option_channel_type/even',
'option_scid_alias/odd',
'option_zeroconf/odd']
expected += ['supports_open_accept_channel_type']
diff --git a/tests/utils.py b/tests/utils.py
index 5b682c6c..ed1e12a7 100644
--- a/tests/utils.py
+++ b/tests/utils.py
@@ -41,7 +41,7 @@ def hex_bits(features):
def expected_peer_features(extra=[]):
"""Return the expected peer features hexstring for this configuration"""
- features = [0, 5, 7, 8, 11, 12, 14, 17, 19, 25, 27, 35, 39, 43, 45, 47, 51]
+ features = [0, 5, 7, 8, 11, 12, 14, 17, 19, 25, 27, 35, 39, 43, 44, 47, 51]
if EXPERIMENTAL_DUAL_FUND:
# option_dual_fund
features += [29]
@@ -57,7 +57,7 @@ def expected_peer_features(extra=[]):
# features for the 'node' and the 'peer' feature sets
def expected_node_features(extra=[]):
"""Return the expected node features hexstring for this configuration"""
- features = [0, 5, 7, 8, 11, 12, 14, 17, 19, 25, 27, 35, 39, 43, 45, 47, 51, 55]
+ features = [0, 5, 7, 8, 11, 12, 14, 17, 19, 25, 27, 35, 39, 43, 44, 47, 51, 55]
if EXPERIMENTAL_DUAL_FUND:
# option_dual_fund
features += [29]
Why this scored 29/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.