Skip to content

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

Closed
TheBlueMatt opened this issue Sep 5, 2018 · 9 comments
Closed
Labels
good first issue Good for newcomers
Milestone

Comments

@TheBlueMatt
Copy link
Collaborator

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 TheBlueMatt added this to the 0.1 milestone Sep 5, 2018
@TheBlueMatt TheBlueMatt added the good first issue Good for newcomers label Sep 5, 2018
@TheBlueMatt
Copy link
Collaborator Author

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
Copy link
Contributor

SWvheerden commented Oct 4, 2018

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
Copy link
Contributor

yuntai commented Oct 4, 2018

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
Copy link
Contributor

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
Copy link
Contributor

yuntai commented Oct 4, 2018

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
Copy link
Contributor

yuntai commented Oct 4, 2018

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
Copy link
Contributor

SWvheerden commented Oct 5, 2018

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
Copy link
Contributor

yuntai commented Oct 5, 2018

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
Copy link
Collaborator Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

3 participants