1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-02-22 22:25:42 +01:00

routing gossip: fixup final/endpoint nomenclature weirdness

'final' and 'endpoint' node don't make much sense out of
context of a payment (in the former case) or when referring to
a non-channel party node. this fixes this
This commit is contained in:
lisa neigut 2018-09-14 11:02:15 -07:00 committed by Rusty Russell
parent b4be990550
commit 5a1dafb67f

View file

@ -146,7 +146,7 @@ The origin node:
- SHOULD set `len` to the minimum length required to hold the `features` bits
it sets.
The final node:
The receiving node:
- MUST verify the integrity AND authenticity of the message by verifying the
signatures.
- if there is an unknown even bit in the `features` field:
@ -277,7 +277,7 @@ The origin node:
- SHOULD set `flen` to the minimum length required to hold the `features`
bits it sets.
The final node:
The receiving node:
- if `node_id` is NOT a valid compressed public key:
- SHOULD fail the connection.
- MUST NOT process the message further.
@ -404,7 +404,7 @@ or `node_id_2` otherwise.
The origin node:
- MAY create a `channel_update` to communicate the channel parameters to the
final node, even though the channel has not yet been announced (i.e. the
channel peer, even though the channel has not yet been announced (i.e. the
`announce_channel` bit was not set).
- MUST NOT forward such a `channel_update` to other peers, for privacy
reasons.
@ -440,14 +440,14 @@ The origin node:
- MUST set `cltv_expiry_delta` to the number of blocks it will subtract from
an incoming HTLC's `cltv_expiry`.
- MUST set `htlc_minimum_msat` to the minimum HTLC value (in millisatoshi)
that the final node will accept.
that the channel peer will accept.
- MUST set `fee_base_msat` to the base fee (in millisatoshi) it will charge
for any HTLC.
- MUST set `fee_proportional_millionths` to the amount (in millionths of a
satoshi) it will charge per transferred satoshi.
- SHOULD NOT create redundant `channel_update`s
The final node:
The receiving node:
- if the `short_channel_id` does NOT match a previous `channel_announcement`,
OR if the channel has been closed in the meantime:
- MUST ignore `channel_update`s that do NOT correspond to one of its own
@ -706,11 +706,11 @@ interactions with them.
### Requirements
An endpoint node:
A node:
- if the `gossip_queries` feature is negotiated:
- MUST NOT relay any gossip messages unless explicitly requested.
- otherwise:
- if it requires a full copy of the other endpoint's routing state:
- if it requires a full copy of the peer's routing state:
- SHOULD set the `initial_routing_sync` flag to 1.
- upon receiving an `init` message with the `initial_routing_sync` flag set to
1:
@ -725,7 +725,7 @@ An endpoint node:
### Requirements
A message receiving node:
A receiving node:
- upon receiving a new `channel_announcement` or a `channel_update` or
`node_announcement` with an updated `timestamp`:
- SHOULD update its local view of the network's topology accordingly.
@ -735,7 +735,7 @@ A message receiving node:
- otherwise:
- SHOULD update the appropriate metadata AND store the signature
associated with the announcement.
- Note: this will later allow the final node to rebuild the announcement
- Note: this will later allow the node to rebuild the announcement
for its peers.
A node:
@ -795,12 +795,12 @@ A node:
#### Requirements
An endpoint node:
A node:
- if a channel's latest `channel_update`s `timestamp` is older than two weeks
(1209600 seconds):
- MAY prune the channel.
- MAY ignore the channel.
- Note: this is an endpoint node policy and MUST NOT be enforced by
- Note: this is an individual node policy and MUST NOT be enforced by
forwarding peers, e.g. by closing channels when receiving outdated gossip
messages. [ FIXME: is this intended meaning? ]