Handle initial_routing_sync requests from peers in their Init messages

[TheBlueMatt]

The gossip_queries stuff is overcomplicated, requires zlib, and is hopefully gonna be replaced sooner or later, so probably dont want to bother implementing that, but we should at least support the initial-connection routing table dump in initial_routing_sync.

[TheBlueMatt]

Tagging good first issue in case someone new comes around - you just need to check for the initial_routing_sync flag in the first Init message we receive from a peer in peer_handler.rs, then get a list of channels/nodes/channel_updates out of the Router (via some new API), then dump those into the socket. For now dont worry about filling up the socket's outbound buffer which is a potential DoS issue but not much we can do about that right now.

[SWvheerden]

Bolt 7 specifies :
Proving the existence of a channel between node_1 and node_2 requires:
proving that the funding transaction pays to bitcoin_key_1 and bitcoin_key_2
proving that node_1 owns bitcoin_key_1
proving that node_2 owns bitcoin_key_2

But I cant seem to find that we store bitcoin_key_1 or bitcoin_key_2 anywhere. Am I missing this?

[yuntai]

As my understanding, from the following paragraph in the spec, the receiver of the message locate the transaction output on the blockchain using short_channel_id and parse P2WSH to extract pubkey1 and pubkey2.

[SWvheerden]

As far as l have it you still need to know them as you need to fill in the message, the receiver then verifies that they exist?

But I have seen that channel already has a function to calculate this, but do you have to send only your channels, or all known channels?

[yuntai]

ah sorry, stupid answer.

Regarding the second,

upon receiving an init message with the initial_routing_sync flag set to 1:
SHOULD send gossip messages for all known channels and nodes, as if they were just received.

Also, TheBlueMatt says
... routing table dump in initial_routing_sync ...

[yuntai]

Ah, you are right. it may be better to keep bitcoin_keys in channel_announcemnet msg to easily re-construct messages later during initial_routing_sync.

[SWvheerden]

thats the route I currently followed

The node announcements message is also confusing me, as spec says:
MUST set signature to the signature of the double-SHA256 of the entire remaining packet after signature (using the key given by node_id).

But we dont have their private key? Either we must save those messages we receive or we should only send out a node announcement for ourself?

The same problem is with channel_annoucment messages., we need both to parties to sign a channel message, we cant send out channel announcements for channels we dont own, even if we are part of a channel we need the other party to sign as well. . We need the secret keys.

Currently I am leaning towards just "caching" all node and channel announcement messages so we can just send them out again.

[yuntai]

Think we can keep their - (not our or our peers') signatures?

For our channels, announcement_signatures to get peers'.

Regarding caching the messages themselves, I'm not so sure. If we cache them, we will have an extra burden to keep them synchronized with our internal network map Instead of having a single state repository and generating messages at will -- just a knee-jerk reaction, though.

[TheBlueMatt]

Oops, think this was resolved by #202/#247.