mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 7: add explicit feature bits to channel_announce and node_announce.

Browse source 
We're going to want these eventually, so let's add them now.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-12-12 11:41:25 +10:30
parent 397a27f1b4
commit 83d918a4a1
1 changed files with 26 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
07-routing-gossip.md
View file

@ -32,6 +32,8 @@ its fee levels and expiry using `channel_update`.
* [33:node-id-2]
* [33:bitcoin-key-1]
* [33:bitcoin-key-2]
* [2:len]
* [len:features]
### Requirements
@ -55,6 +57,9 @@ The creating node MUST set `node-signature-1` and `node-signature-2`
to the signature of the double-SHA256 of the message after the end of
`node-signature-2`, using `node-id-1` and `node-id-2` as keys respectively.
The creating node SHOULD set `len` to the minimum length required to
hold the `features` bits it sets.
The receiving node MUST ignore the message if the output specified
by `channel-id` does not
correspond to a P2WSH using `bitcoin-key-1` and `bitcoin-key-2` as
@ -77,6 +82,9 @@ previous message's `node-id-1` and `node-id-2` as well as this
`node-id-1` and `node-id-2` and forget channels connected to them,
otherwise it SHOULD store this `channel_announcement`.
The receiving node SHOULD NOT route through a channel which has an
unknown `feature` bit set which is even.
The receiving node SHOULD forget a channel once its funding output has
been spent or reorganized out.
@ -94,6 +102,11 @@ While channels shouldn't be advertised before they are sufficiently
deep, the requirement against rebroadcasting only applies if the
transaction hasn't moved to a different block.
New channel features are possible in future; backwards compatible (or
optional) ones will have odd feature bits, incompatible ones will have
even feature bits. These will be propagated by nodes even if they
can't use the announcements themselves.
## The `node_announcement` message
This allows a node to indicate extra data associated with it, in
@ -109,6 +122,8 @@ nodes for which a channel is not already known are ignored.
* [33:node-id]
* [3:rgb-color]
* [32:alias]
* [2:len]
* [len:features]
The `timestamp` allows ordering in the case of multiple announcements;
the `ipv6` and `port` allow the node to announce its willingness to
@ -125,6 +140,9 @@ a non-zero `port` and `ipv6` set to a valid IPv6 address or an IPv4-Mapped IPv6
the double-SHA256 of the entire remaining packet after `signature` using the
key given by `node-id`. It MAY set `alias` and `rgb-color` to customize their node's appearance in maps and graphs, where the first byte of `rgb` is the red value, the second byte is the green value and the last byte is the blue value. It MUST set `alias` to a valid UTF-8 string of up to 21 bytes in length, with all `alias` bytes following equal to zero.
The creating node SHOULD set `len` to the minimum length required to
hold the `features` bits it sets.
The receiving node SHOULD fail the connection if `node-id` is not a valid
compressed public key, and MUST NOT further process the message.
@ -144,10 +162,18 @@ previously known from a `channel_announcement` message, or if
this `node-id` the receiving node SHOULD queue the message for
rebroadcasting.
The receiving node SHOULD NOT connect to a node which has an unknown
`feature` bit set in the `node_announcement` which is even.
The receiving node MAY use `rgb` and `alias` to reference nodes in interfaces, but SHOULD insinuate their self-signed origin.
### Rationale
New node features are possible in future; backwards compatible (or
optional) ones will have odd feature bits, incompatible ones will have
even feature bits. These will be propagated by nodes even if they
can't use the announcements themselves.
RFC 4291 section 2.5.5.2 described IPv4 addresses like so:
```