This document tracks the assignment of localfeatures and globalfeatures
flags in the init message (BOLT #1) along with the
features flag fields in the channel_announcement and node_announcement
messages (BOLT #7).
The flags are tracked separately, since new flags will likely be added over time.
The features flags in the routing messages are a subset of the
globalfeatures flags, as localfeatures, by definition, are only of interest
to direct peers.
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 init Message.
These flags may only be used in the init message:
| Bits | Name | Description | Link |
|---|---|---|---|
| 0/1 | option_data_loss_protect |
Requires or supports extra channel_reestablish fields |
BOLT #2 |
| 3 | initial_routing_sync |
Indicates that the sending node needs a complete routing information dump | BOLT #7 |
| 4/5 | option_upfront_shutdown_script |
Commits to a shutdown scriptpubkey when opening channel | BOLT #2 |
| 6/7 | gossip_queries |
More sophisticated gossip control | BOLT #7 |
The following globalfeatures bits are currently assigned by this specification:
| Bits | Name | Description | Link |
|---|---|---|---|
| 8/9 | var_onion_optin |
This node requires/supports variable-length routing onion payloads | Routing Onion Specification |
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 init Message.
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.
This work is licensed under a Creative Commons Attribution 4.0 International License.