Testing a Flare-like routing implementation on 2500 AWS nodes

Sep 23 - Sep 23, 2016

  • The author of this email is asking Pierre about their implementation in tests and the difference between it and the original paper.

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.

Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback