AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

Improve support for plugin-defined features (#3264)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Improve support for plugin-defined features (#3264)

We allow injecting non-official features via plugins, by extending the
`CustomFeaturePlugin` trait. However, we previously added those features
to a set of unknown features: we can do better and add them to the known
features map, which provides pretty-printing in logs and simplifies
debugging.

We also had an issue where `hasFeature` would always return `false` for
plugin features, even when they were supported by both nodes, because we
only looked at our `activated` features map which only contains official
features.

We get rid of the `UnknownFeature` class entirely and keep the encoded
feature bits after deserializing them. We take those feature bits into
account in `hasFeature`, which fixes the issue.

This creates a slightly weird asymmetry because our local features,
which are created based on our `eclair.conf`, will not have this field
set while features that are read from network messages or the DB will
have this field set. A better architecture would be to remove the
`activated` map entirely and directly wrap the feature bits, while
providing helper functions to interact with features without having
to directly read a `BitVector`. This is a larger refactoring though,
because we'd need to add support for filtering `init` / `node` features
using bitmasks, which isn't entirely trivial to handle and requires
careful management of plugin features.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug where Eclair did not correctly recognize custom features added by plugins when checking if another node supports them. Previously, plugin features were treated as 'unknown' and `hasFeature` always returned false for them, even when both nodes supported the same plugin feature. The change stores the raw feature bits after decoding and uses them in feature checks, while removing the old 'UnknownFeature' class. It is a correctness and compatibility improvement rather than a critical security patch, but it could affect whether nodes agree on required features during connection.

Recommended action

Review the updated feature-compatibility logic, especially the new `testSupported` encoded-bit loop, to ensure it does not accidentally accept unsupported mandatory features or reject valid optional ones. Run the updated test suites (FeaturesSpec, PeerConnectionSpec, Bolt11InvoiceSpec) and verify that plugin feature negotiation behaves as intended. Consider whether any downstream consumers depend on the removed `unknown` JSON field.

Security signals we found

01

Fixes feature-negotiation correctness for plugin-defined features

02

Changes how unknown/even feature bits are validated during compatibility checks

03

Removes UnknownFeature class and changes JSON serialization shape

04

Adds EncodedFeatures to preserve raw feature bits from wire/DB messages

05

Updates plugin trait to allow mandatory vs optional feature support

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.