-
Notifications
You must be signed in to change notification settings - Fork 406
Handle initial_routing_sync requests from peers in their Init messages #148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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. |
Bolt 7 specifies : But I cant seem to find that we store bitcoin_key_1 or bitcoin_key_2 anywhere. Am I missing this? |
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. |
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? |
ah sorry, stupid answer. Regarding the second,
Also, TheBlueMatt says |
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. |
thats the route I currently followed The node announcements message is also confusing me, as spec says: 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: