From c7c8691d3080655289dc9899aa261d8d36fcc5f9 Mon Sep 17 00:00:00 2001 From: Shannon Appelcline Date: Wed, 13 Dec 2017 18:08:43 -0800 Subject: [PATCH] BOLT-09 Edits (#321) 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. --- 09-features.md | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/09-features.md b/09-features.md index 88727cb..3226c41 100644 --- a/09-features.md +++ b/09-features.md @@ -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")