[Lightning-dev] Testing a Flare-like routing implementation on 2500 AWS nodes
Viacheslav Zhygulin
viacheslav.zhygulin at bitfury.com
Fri Sep 23 14:10:19 UTC 2016
Hey Pierre,
I have a question regarding your tests.
You said:
"The main difference between our implementation and the original paper
is in
the way nodes communicate with each other. In the paper, an assumption
is
made that "there exists a way for any two nodes in LN to communicate
with
each other, perhaps with some prior setup (such as a distributed
hashtable
overlay maintained among LN nodes that would store mapping of node
identifiers to their current IP addresses)". In our implementation there
is
no DHT: inter-nodes communication only occurs on existing open channels,
and all routing-related messages are onion-encrypted and routed
themselves,
just like htlc messages. So a node can't talk directly to a node it
doesn't
already have a route to"
On the other hand, you said:
"The route selection has also been simplified. Whereas Flare proposed a
3
steps process:
(a) sender uses its own routing table
(b) sender requests receiver's table and uses a combination of the two
tables
(c) sender iterates over nodes it knows that are close to the receiver,
and
request their tables
in our test we only did (b), 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."
So, my question is: how sender requests receiver's routing table, if
sender cannot communicate to receiver?
Thank you for the answer in advance!
Best,
--
Viacheslav Zhygulin
--
THIS COMMUNICATION AND ANY ATTACHMENTS MAY CONTAIN CONFIDENTIAL INFORMATION OF THE SENDER. ALL UNAUTHORIZED USE, DISCLOSURE OR DISTRIBUTION IS PROHIBITED. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE NOTIFY THE SENDER IMMEDIATELY AND DESTROY ALL COPIES OF THIS COMMUNICATION. THANK YOU.
More information about the Lightning-dev
mailing list