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: always propagate announcements with unknown features.

Browse source 
The feature fields refer to the properties of the channel/node, not the
message itself, so we can still propagate them (and should, to avoid
splitting the network).

If we want to make an incompatible announcement message, we'll use a
different type, or insert an even TLV type.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2019-09-17 14:55:10 +09:30
parent 206084c939
commit 6502e30e8f
1 changed files with 4 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
07-routing-gossip.md
View file

@ -188,9 +188,7 @@ The receiving node:
- MUST verify the integrity AND authenticity of the message by verifying the - MUST verify the integrity AND authenticity of the message by verifying the
signatures. signatures.
- if there is an unknown even bit in the `features` field: - if there is an unknown even bit in the `features` field:
- MUST NOT parse the remainder of the message. - MUST NOT attempt to route messages through the channel.
- MUST NOT add the channel to its local network view.
- SHOULD NOT forward the announcement.
- if the `short_channel_id`'s output does NOT correspond to a P2WSH (using - if the `short_channel_id`'s output does NOT correspond to a P2WSH (using
`bitcoin_key_1` and `bitcoin_key_2`, as specified in `bitcoin_key_1` and `bitcoin_key_2`, as specified in
[BOLT #3](03-transactions.md#funding-transaction-output)) OR the output is [BOLT #3](03-transactions.md#funding-transaction-output)) OR the output is
@ -244,8 +242,6 @@ New channel features are possible in the future: backwards compatible (or
optional) features will have _odd_ feature bits, while incompatible features optional) features will have _odd_ feature bits, while incompatible features
will have _even_ feature bits will have _even_ feature bits
(["It's OK to be odd!"](00-introduction.md#glossary-and-terminology-guide)). (["It's OK to be odd!"](00-introduction.md#glossary-and-terminology-guide)).
Incompatible features will result in the announcement not being forwarded by
nodes that do not understand them.
## The `node_announcement` Message ## The `node_announcement` Message
@ -326,11 +322,7 @@ any future fields appended to the end):
- SHOULD fail the connection. - SHOULD fail the connection.
- MUST NOT process the message further. - MUST NOT process the message further.
- if `features` field contains _unknown even bits_: - if `features` field contains _unknown even bits_:
- MUST NOT parse the remainder of the message.
- MAY discard the message altogether.
- SHOULD NOT connect to the node. - SHOULD NOT connect to the node.
- MAY forward `node_announcement`s that contain an _unknown_ `features` _bit_,
regardless of if it has parsed the announcement or not.
- SHOULD ignore the first `address descriptor` that does NOT match the types - SHOULD ignore the first `address descriptor` that does NOT match the types
defined above. defined above.
- if `addrlen` is insufficient to hold the address descriptors of the - if `addrlen` is insufficient to hold the address descriptors of the
@ -354,8 +346,9 @@ any future fields appended to the end):
New node features are possible in the future: backwards compatible (or New node features are possible in the future: backwards compatible (or
optional) ones will have _odd_ `feature` _bits_, incompatible ones will have optional) ones will have _odd_ `feature` _bits_, incompatible ones will have
_even_ `feature` _bits_. These may be propagated by nodes even if they _even_ `feature` _bits_. These will be propagated normally; incompatible
cannot process the announcements themselves. feature bits here refer to the nodes, not the `node_announcement` message
itself.
New address types may be added in the future; as address descriptors have New address types may be added in the future; as address descriptors have
to be ordered in ascending order, unknown ones can be safely ignored. to be ordered in ascending order, unknown ones can be safely ignored.