Sep 23 - Sep 23, 2016
The main difference is in the way nodes communicate with each other, where there is no DHT in their implementation as inter-nodes communication only occurs on existing open channels and all routing-related messages are onion-encrypted and routed themselves. This means that a node cannot talk directly to a node it doesn't already have a route to. Regarding route selection, the Flare paper proposed a 3-step process which includes sender using its own routing table, requesting receiver's table and using a combination of both tables, and iterating over nodes close to the receiver to request their tables. However, in their test, they only did the second step which is a strong tradeoff. It means that the time allowed to find a route is short and predictable, but it is very suboptimal in terms of probability of finding a route. The author's question is how the sender requests the receiver's routing table if the sender cannot communicate with the receiver. The email ends with a confidentiality notice.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback