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 9: assign feature bits in pairs, give them names, clarify position.

Browse source 
Christian assumed first bit was 1, I assumed 0.  And we should generally
assign in pairs (so an optional understanding can later become compulsory),
though for the initial draft it's unnecessary.

By giving names we avoid smearing values over the spec, containing them in
BOLT 9.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-02-07 14:58:31 +10:30 • committed by Olaoluwa Osuntokun
parent 4e3ad54a90
commit fba22970c6
2 changed files with 10 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
07-routing-gossip.md
View file

@ -23,12 +23,12 @@ It contains the necessary signatures by the sender to construct the `channel_ann
* [64:node-signature]
* [64:bitcoin-signature]
The willingness of the endpoints to announce the channel is signaled during the connection setup by setting the first bit (`0x01`) in the `localfeatures` field.
Should both endpoints have signaled that they'd like to publish the channel (`localfeatures & 0x01 == 0x01`) then the `announcement_signatures` message MUST directly sent following the `funding_locked` message that established the corresponding channel.
The willingness of the endpoints to announce the channel is signaled during the connection setup by setting a `channel_public` bit in the `localfeatures` field.
Should both endpoints have signaled that they'd like to publish the channel then the `announcement_signatures` message MUST directly sent following the `funding_locked` message that established the corresponding channel.
The `announcement_signatures` message is created by constructing a `channel_announcement` message corresponding to the newly established channel, and sign it with the secrets matching their `node-id` and `bitcoin-key`, and send them using an `announcement_signatures`.
The recipient MAY fail the channel if the `node-signature` or `bitcoin-signature` is incorrect.
The recipient SHOULD queue the `channel_announcement` message for its peers if it has sent and received a valid `announcement_signatures` message.
If either endpoints does not signal (`localfeatures & 0x01 == 0x00`) then `announcement_signatures` MUST NOT be sent.
If either endpoints does not signal `channel_public` then `announcement_signatures` MUST NOT be sent.
## The `channel_announcement` message

11
09-features.md
View file

@ -7,10 +7,13 @@ The `features` flags in the routing messages are a subset of the `globalfeatures
## Assigned `localfeatures` flags
This flags may only be used in the `init` message.
These flags may only be used in the `init` message, and are generally assigned in pairs.
| Bits | Description | Link |
|------|-------------------------------------------------|---------------------------------------------------------------------|
| 1 | The sending node wishes to announce the channel | [BOLT #7](07-routing-gossip.md#the-announcement_signatures-message) |
Flags begin at bit 0 (ie. 0x1), and odd-numbered flags (eg. 0x2) are optional.
| Bits | Name |Description | Link |
|------|------------------|------------------------------------------------|---------------------------------------------------------------------|
| 0/1 | `channel_public` | The sending node wishes to announce the channel | [BOLT #7](07-routing-gossip.md#the-announcement_signatures-message) |
## Assigned `globalfeatures` flags