mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 10:00:04 +01:00
f6312d9a70
[ This was a joint effort by many people, with iterations not indicated in this final commit: thanks to all who reviewed and polished! Particularly: @jimpo @cdecker @sstone @ZmnSCPxj ] This enables three new functions: 1. query_short_channel_ids: they will send channel_announcement / channel_update / node_announcement followed by reply_short_channel_ids_done. 2. query_channel_range: they will send one or more reply_channel_range with the short_channel_ids in these blocks. 3. gossip_timestamp_filter: filters what gossip they send. It also changes behavior: we no longer send a `channel_announcement` until we have at least one `channel_update`. The announcement is fairly useless without an update already, but this in particular enables reasonable timestamp filtering (channel_announcement does not have an explicit timestamp). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
49 lines
2.6 KiB
Markdown
49 lines
2.6 KiB
Markdown
# BOLT #9: Assigned Feature Flags
|
|
|
|
This document tracks the assignment of `localfeatures` and `globalfeatures`
|
|
flags in the `init` message ([BOLT #1](01-messaging.md)) along with the
|
|
`features` flag fields in the `channel_announcement` and `node_announcement`
|
|
messages ([BOLT #7](07-routing-gossip.md)).
|
|
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](01-messaging.md#the-init-message).
|
|
|
|
## Assigned `localfeatures` flags
|
|
|
|
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](02-peer-protocol.md#message-retransmission) |
|
|
| 3 | `initial_routing_sync` | Indicates that the sending node needs a complete routing information dump | [BOLT #7](07-routing-gossip.md#initial-sync) |
|
|
| 4/5 | `option_upfront_shutdown_script` | Commits to a shutdown scriptpubkey when opening channel | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
|
|
| 6/7 | `gossip_queries` | More sophisticated gossip control | [BOLT #7](07-routing-gossip.md#query-messages) |
|
|
|
|
## Assigned `globalfeatures` flags
|
|
|
|
There are currently no `globalfeatures` flags.
|
|
|
|
## Requirements
|
|
|
|
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](01-messaging.md#the-init-message).
|
|
|
|
## Rationale
|
|
|
|
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.
|
|
|
|
|
|
<br>
|
|
This work is licensed under a [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/).
|