[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