Do not reply with a node_announcement if the query includes an optional query flag that does not request it.
The current wording could be interpreted as "always follow with node announcements whenever
you reply with a channel announcements" which defeats the point of using query flags (if you want the node
announcements just set the corresponding bits).
We use the more tool-friendly `...*` description for TLV extensions.
Checksums are now serialized as raw arrays, as using zlib compression here would not help.
Since some can be zero (missing updates), it's probably worth
doing the compression thing optionally.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Formatting changes only.
This make tools/extract-formats.py work (well, it misses some stuff
until the tlv-testcases merge, but then it's OK).
We use `tlvs` (for tlv stream), and we refer to TLV records as "being
included" rather than re-using the TLV name.
We even use subtypes for the pairs of checksums and timestamps.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Nodes that support extended queries will append an additional extended query flag to
their `query_channel_range` queries. If the receiver supports extended queries and
understands this flag, it will append the required additional data to its
`reply_channel_range` message.
There is currently only one type of additional data: one timestamp and one checksum
per `channel_update`.
The checksum is a CRC32 checksum computed over the `channel_update`
with `timestamp` and `signature` omitted.
Along with query_short_channel_ids extension, this can be used to
avoid querying `channel_updates` that are older than the ones you
already have, or that are newer but don't include new information.
Nodes can append additional data to their `query_short_channel_ids`
messages, which consists in one flag per short channel id and
specifies what they would like to receive (`node_announcement`,
`channel_announcement`, or/and one `channel_update` or both).
If a node sends its own `channel_update` to a peer node before receiving a `funding_lock`, the peer node may discard because it has not `short_channel_id` yet.
It's trivial to make types->lengths, but not so much the other way.
The types I used here are the ones I found useful in implementation, and
I think add some clarity, though we can certainly argue about them.
There's no normative changes to the spec in here.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Technically this change may result in channels_announcements only
coming from one end. However, because c-lightning already implements
announcement_signatures in this way, in practice this will improve
reliability of channel_announcements.
[ After much bikeshedding, wording rewritten but same effect -- RR ]
Closes#468Closes: #474
'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
The Initial Sync section is hard to parse, as is, because it's presented
without context. This adds a small clarifying statement, in particular
highlighting where the mode is triggered from (init message features)
and what in particular is being synced (gossip messages)
This optional padding makes it very difficulty to deserialize
node_announcements into internal structs for storage and then
reconstruct the original node_announcement, plus are unused on the
network today and no known implementations construct
node_announcement messages with them.
The fee calculation in BOLT 7 appears to imply that proprtional
fees must be paid on the incoming amount, not the to_forward amount
This is inconsistent with what is actually implemented in the
field (which uses amount_to_forward) and also would make
pathfinding more complicated as the fee would depend on itself,
making calculation no longer simple.
This helps lite nodes a little, but also gives a way of advertising a
lesser capacity than implied onchain.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ Note: in retrospect, adding this in the initial draft without its
own feature bit was a mistake. It was a premature optimization,
adds complexity and removes the ability to disable it if a problem
is found without disabling gossip_queries entirely. However, it
is already deployed as-is. --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[ This was a joint effort by many people, with iterations not
indicated in this final commit: thanks to all who reviewed and
polished! Particularly: @jimpo @cdecker @sstone @ZmnSCPxj ]
This enables three new functions:
1. query_short_channel_ids: they will send channel_announcement /
channel_update / node_announcement followed by reply_short_channel_ids_done.
2. query_channel_range: they will send one or more reply_channel_range
with the short_channel_ids in these blocks.
3. gossip_timestamp_filter: filters what gossip they send.
It also changes behavior: we no longer send a `channel_announcement`
until we have at least one `channel_update`. The announcement is
fairly useless without an update already, but this in particular
enables reasonable timestamp filtering (channel_announcement does not
have an explicit timestamp).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
