This document tracks the assignment of
features flags in the
init message (BOLT #1), as well as
features fields in the
node_announcement messages ([BOLT
new flags will likely be added over time.
Flags are numbered from the least-significant bit, at bit 0 (i.e. 0x1, an even bit). They are generally assigned in pairs so that features can be introduced as optional (odd bits) and later upgraded to be compulsory (even bits), which will be refused by outdated nodes: see BOLT #1: The
Some features don't make sense on a per-channels or per-node basis, so each feature defines how it is presented in those contexts. Some features may be required for opening a channel, but not a requirement for use of the channel, so the presentation of those features depends on the feature itself.
The Context column decodes as follows:
I: presented in the
N: presented in the
C: presented in the
C-: presented in the
channel_announcement message, but always odd (optional).
C+: presented in the
channel_announcement message, but always even (required).
9: presented in BOLT 11 invoices.
Requires or supports extra
Sending node needs a complete routing information dump
Commits to a shutdown scriptpubkey when opening channel
More sophisticated gossip control
Requires/supports variable-length routing onion payloads
Gossip queries can include additional information
Static key for remote output
Node can receive basic multi-part payments
Can create large channels
The origin node:
If it supports a feature above, SHOULD set the corresponding odd
bit in all feature fields indicated by the Context column unless
indicated that it must set the even feature bit instead.
If it requires a feature above, MUST set the corresponding even
feature bit in all feature fields indicated by the Context column,
unless indicated that it must set the odd feature bit instead.
MUST NOT set feature bits it does not support.
MUST NOT set feature bits in fields not specified by the table above.
MUST set all transitive feature dependencies.
The requirements for receiving specific bits are defined in the linked sections in the table above. The requirements for feature bits that are not defined above can be found in BOLT #1: The
There is no even bit for
initial_routing_sync, as there would be little point: a local node can't determine if a remote node complies, and it must interpret the flag, as defined in the initial spec.
Note that for feature flags which are available in both the
node_announcement and BOLT 11 invoice contexts, the features as set in the BOLT 11 invoice should override those set in the
node_announcement. This keeps things consistent with the unknown features behavior as specified in BOLT 7.
The origin must set all transitive feature dependencies in order to create a well-formed feature vector. By validating all known dependencies up front, this simplifies logic gated on a single feature bit; the feature's dependencies are known to be set, and do not need to be validated at every feature gate.
This work is licensed under a Creative Commons Attribution 4.0 International License.