-
Notifications
You must be signed in to change notification settings - Fork 371
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
Channel Graph Fetching from newer lightning nodes #615
Comments
Related to #57, but seems more up-to-date. |
I'm planning to pick this up. To be clear, the plan is to use |
Yep, gossip_queries kinda suck, but if we have to use then just to get the graph, we have to... still, ideally we don't implement more of the complexity than we have to. |
I would like to help if you all want the assistance. I have experience implementing |
Cool! I don't believe @naumenkogs is working on this, at least based on his PR's, but I'll let him correct me if not. As for where, you should check out peer_handler.rs, at least where it handles initial_routing_sync on the init message (https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning/src/ln/peer_handler.rs#L589 and https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning/src/ln/peer_handler.rs#L717). If you need to interface with the network graph to get information, do so through the RoutingMessageHandler trait (https://github.com/rust-bitcoin/rust-lightning/blob/master/lightning/src/ln/msgs.rs#L600-L622). |
I was planning, but haven't started working on this issue yet, so please go ahead :) |
I'm still getting familiar with the codebase but wanted to share some thoughts and experiences on how we might tackle this. At a high level, a minimalist implementation should only support To keep things simple with When using Prior to a clarifications of the spec, Not supporting zlib presents a challenge in that there is no way to dictate the encoding sent in
If we connect to c-lightning or eclair node, we are out of luck and will need to fail the sync and try with a different peer. It might be best to push for a new feature flag in the spec to signal zlib support. In my implementation, I blackboxed the sync process. The two main benefits are:
I'll send a follow up with some thoughts on actual implementation as I get more familiar with the code. Thanks! |
Definitely. Am I correct, then, in my understanding that there is no reliable way to fetch the routing table from both an lnd node and a c-lightning node without taking a zlib dependency or without playing some game where we guess the remote node type and reconnect with different flags until things work?
Regarding using block filters, does this imply that we would miss any channel announcements which were only broadcast a while (eg lets say a day) after the block where the channel was opened if we set anything other than a "give me everything" filter? Its totally reasonable for nodes to be offline when their commitment transaction confirms and only broadcast the channel announcement much later, which seems to imply other nodes would miss it due to requesting a filter of "all the stuff since I was last online, as determined by when the channel confirmed, not when the channel_announcement was broadcast"?
I'm not sure what you mean by this - are you implying that the |
That is my understanding as well.
You are correct, if your time horizon prior to your last known block is too short you may miss a
Bob believes he has a complete view until he went offline at 400, but if his time horizon is short (say 1 days worth), he will construct his query for block 256+ and miss Alice's channel that is attached to block 100. This might not be that common an issue since Alice's counterparty may fail the channel if she fails to send her In can also be resolved if Alice is active and sends periodic Another reason I've been fetching the full range is a related problem. Because
Doing a full sync is expensive, but it at least guarantees that we have all information that the peer has.
Sorry for the confusion, sort of a aside on the implementation side of things. I was referring to the implementation in node-lightning which has a different architecture. |
RIght, sounds like we pretty much need to request a full sync always until we get a set-reconciliation protocol to replace the existing sync stuff.
Ah, ok, looking forward to seeing your work here :) |
BTW, I created this issue in the lightning-rfc requesting zlib support negotiation: lightning/bolts#811 |
I believe #1015 is the only thing left here. |
Compression got yanked from the spec, this is now complete. |
Newer versions of some lightning nodes (at least lnd, but not c-lightning) don't bother supporting sending the full routing table anymore in response to the initial_routing_sync bit. We should figure out what the minimal set of channel queries is to be able to tell such nodes to send us the full routing table at startup without taking zlib dependency. Long-term I'd probably prefer that we help get the sync stuff to a more robust redesign (see eg lightning/bolts#584 (comment) ) but certainly in the mean time we should at least be able to fetch the db.
The text was updated successfully, but these errors were encountered: