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

BOLT 7: channel_update timestamp must be a UNIX timestamp.

Browse source 
As agreed at the previous meeting, we use the timestamp to prune,
so it does have to be a valid timestamp.  We also suggest ignoring
if it's in the far future, too.

The minutes suggest we can prune for any reason, and that's really
true anyway; the requirements to keep it around are only SHOULD.

Note that this only applies to channel_update: node_announces
are not pruned (except, perhaps, by implication when all channels
are pruned)

Closes: #302
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2018-01-08 14:01:12 +10:30 • committed by Christian Decker
parent 47b8851037
commit 64cf99d854
1 changed files with 11 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
07-routing-gossip.md
View file

@ -359,7 +359,7 @@ Bits which are not assigned a meaning must be set to 0.
A node MAY create and send a `channel_update` with the `disable` bit set to signal the temporary unavailability of a channel, e.g., due to loss of connectivity, or the permanent unavailability, e.g., ahead of an on-chain settlement. A node MAY create and send a `channel_update` with the `disable` bit set to signal the temporary unavailability of a channel, e.g., due to loss of connectivity, or the permanent unavailability, e.g., ahead of an on-chain settlement.
A subsequent `channel_update` with the `disable` bit unset MAY re-enable the channel. A subsequent `channel_update` with the `disable` bit unset MAY re-enable the channel.
The creating node MUST set `timestamp` to greater than zero, and MUST set it to greater than any previously-sent `channel_update` for this `short_channel_id`. The creating node MUST set `timestamp` to greater than zero, and MUST set it to greater than any previously-sent `channel_update` for this `short_channel_id`, and SHOULD base it on a UNIX timestamp.
It MUST set `cltv_expiry_delta` to the number of blocks it will subtract from an incoming HTLCs `cltv_expiry`. It MUST set `htlc_minimum_msat` to the minimum HTLC value the other end of the channel will accept, in millisatoshi. It MUST set `fee_base_msat` to the base fee it will charge for any HTLC, in millisatoshi, and `fee_proportional_millionths` to the amount it will charge per transferred satoshi in millionths of a satoshi. It MUST set `cltv_expiry_delta` to the number of blocks it will subtract from an incoming HTLCs `cltv_expiry`. It MUST set `htlc_minimum_msat` to the minimum HTLC value the other end of the channel will accept, in millisatoshi. It MUST set `fee_base_msat` to the base fee it will charge for any HTLC, in millisatoshi, and `fee_proportional_millionths` to the amount it will charge per transferred satoshi in millionths of a satoshi.
The receiving nodes MUST ignore the `channel_update` if it does not correspond to one of its own channels, if the `short_channel_id` does not match a previous `channel_announcement`, or if the channel has been closed in the meantime. The receiving nodes MUST ignore the `channel_update` if it does not correspond to one of its own channels, if the `short_channel_id` does not match a previous `channel_announcement`, or if the channel has been closed in the meantime.
@ -380,10 +380,19 @@ is not greater than that of the last-received `channel_announcement` for
this `short_channel_id` and `node_id`. Otherwise, if the `timestamp` is equal to this `short_channel_id` and `node_id`. Otherwise, if the `timestamp` is equal to
the last-received `channel_announcement` and the fields other than the last-received `channel_announcement` and the fields other than
`signature` differ, the node MAY blacklist this `node_id` and forget all `signature` differ, the node MAY blacklist this `node_id` and forget all
channels associated with it. Otherwise the receiving node SHOULD channels associated with it. The receiving node MAY discard the `channel_announcement` if the `timestamp` is far in the future.
Otherwise the receiving node SHOULD
queue the message for rebroadcasting, but MAY choose not to for queue the message for rebroadcasting, but MAY choose not to for
messages longer than the minimum expected length. messages longer than the minimum expected length.
### Rationale
The `timestamp` field is used by nodes for pruning (either if it's too
far in the future, or if it's been two weeks with no update), so it
makes sense to have it be a UNIX timestamp (ie. seconds since UTC
1970-01-01). It can't be a hard requirement, however, given the possible case
of two `channel_update`s within a second.
## Initial Sync ## Initial Sync
Upon establishing a connection, the two endpoints negotiate whether to perform an initial sync by setting the `initial_routing_sync` flags in the `init` message. Upon establishing a connection, the two endpoints negotiate whether to perform an initial sync by setting the `initial_routing_sync` flags in the `init` message.