mirror of
https://github.com/ACINQ/eclair.git
synced 2025-02-24 14:50:46 +01:00
9f708acf04
* Implement new 'routing sync' messages * add a new feature bit for channel queries when we receive their init message and check their features: - if they set `initial_routing_sync` and `channel_range_queries` we do nothing, we should receive a range query shorly - if they support channel range queries we send a range query * Modify query_short_channel_id to ask for a range of ids And not just a single id * use `SortedMap` to store channel announcements * don't send prune channels with channel range queries * update range queries type to match BOLT PR * add timestamp-based filters for gossip messages each peer can speficy a `timestamp range` to filter gossip messages against. * don't preserve order in `decodeShortChannelIds` It is not needed and allows us to return a `Set`, which is better suited to how we use the result. * channel range queries: handle multi-message responses Handle case where there are too many short ids to fit in a single message. * channel range queries: use zlib instead of gzip but detect when a message was encoded with gzip and reply with gzip in that case. * router: add more channel range queries logs * Channel range queries: correctly set firstBlockNum and numberOfBlocks fields * channel range queries: properly handle case where there is no data we will just receive on byte (compression format) * channel range queries: use their compression format to query channels when we query channels with `query_short_channel_ids`, we now use the same compression format as in their `repy_channel_range` message. So we should be able to communicate with peers that have not implemented all compression formats. * router: make sure that channel ids are sorted For channel range queries to work properly, channel ids need to be sorted. It is then much more efficient to use a sorted map in our router state. * always use `keySet` instead of `keys` `SortedMap`.`keySet` returns a `SortedSet`, whereas `SortedMap`.`keys` returns an `Iterable`. This is a critical difference because channel range queries has requirements on ordering of channel ids. Using the former allows us to rely on type guarantees instead of on assumptions that the `Iterable` is sorted in `ChannelRangeQueries`. There is no cost difference as internally the `Iterator` is actually a `SortedSet`. Also, explicitely specified the type instead of relying on comments in `Router`. * publish channel update event on router startup * channel range queries: use uint32 for 4-byte integers (and not int32) * channel range queries: make sure we send at least one reply to `query_channel_range` reply to `query_channel_range` messages for which we have no matching channel ids with a single `reply_channel_range` that contains no channel ids. * channel range queries: handle `query_channel_range` cleanly add an explicit test when we have no matching channel ids and send back a reply with an empty (uncompressed) channel ids payload * channel range queries: rename GossipTimeRange to GossipTimestampFilter * channel range queries: add gossip filtering test * peer: forward all routing messages to the router and not just channel range queries. this should not break anything and if it does it would reveal a problem * peer: add remote node id to messages sent to the router this will improve logging and debugging and will help if we implement banning strategies for mis-behaving peers * router: filter messages with a wrong chainHash more cleanly * channel range queries: set a "pass-all" timestamp filter * router: remove useless pattern match ChannelUpdates are wapped in a PeerRoutingMessage now * Peer: fit typo in comment * Peer: optimize our timestamp filter * Router: use mdc to log remote node id when possible * fix typos and improve log message formatting * Peer: rephrase scala doc comment that breaks travis * Peer: improve timestamp filtering + minor fixes * Electrum tests: properly stop actor system at the end of the test * Peer: filter out node announcements against our peer's timestamp But we don't prune node annoucements for which we don't have a matching channel in the same "rebroadcast" message |
||
|---|---|---|
| .. | ||
| src | ||
| eclair-cli | ||
| pom.xml | ||