mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-23 06:35:18 +01:00
Code Issues Projects Releases Wiki Activity

BOLT-09 Edits (#321)

Browse source 
I regularized the descriptions in the localfeatures table, so keep a careful eye on the accuracy of those. Otherwise, fairly standard editing in this very short section.

Added text for lack of globalfeatures flags.
This commit is contained in:
Shannon Appelcline 2017-12-13 18:08:43 -08:00 • committed by Rusty Russell
parent 6586287d88
commit c7c8691d30
1 changed files with 15 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

28
09-features.md
View file

@ -5,34 +5,36 @@ They 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, since the `localfeatures` are by definition only of interest to direct peers.
Flags are numbered from the least-significant bit at bit 0 (ie. 0x1,
an even bit). They are generally assigned in pairs, so that features
can be introduced as optional (odd bits), and later upgraded to refuse
old nodes (even bits). See [BOLT #1: The `init` message](01-messaging.md#the-init-message).
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, refusing
old nodes (even bits). 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/supports extra `channel_reestablish` fields | [BOLT #2](02-peer-protocol.md#message-retransmission) |
| 3 | `initial_routing_sync` | The sending node needs a complete routing information dump | [BOLT #7](07-routing-gossip.md#initial-sync) |
| 4/5 | `option_upfront_shutdown_script` | Commit to a shutdown scriptpubkey when opening | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
| 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 | [BOLT #2](02-peer-protocol.md#the-open_channel-message) |
## Assigned `globalfeatures` flags
There are currently no `globalfeatures` flags.
## Requirements
(Note that the requirements for feature bits which are not defined
above, can be found in [BOLT #1: The `init` message](01-messaging.md#the-init-message)). The requirements when receiving set bits are defined in the linked section in the table above).
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's little point insisting on an `initial_routing_sync` (you can't
tell if the remote node complies, and it has to know what it means as
it's defined in the initial spec) so there's no even bit for that.
There's little point in insisting on an `initial_routing_sync`. You can't
tell if the remote node complies, and it has to know what the flag means as
it's defined in the initial spec. So, there's no even bit for this.
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>