Hello Christian, Thanks for your prompt reply. Please, see my minor comments and questions below.
On 11/23/17 7:50 AM, Christian Decker wrote: > Thanks Pedro for the paper, I'll read through it as soon as possible and > add more feedback :-) I just have some minor points to add regarding > your last mail. > >> The onion-like packets used for *payments* in the current LN >> implementations inevitably assume that the sender knows the complete >> path from the sender to the intended receiver. The question/challenge >> that we are solving in this work is: how does the sender gets to know >> such path in the first place? > > The current implementation requires the node to compute the entire > route, yes. However we have mechanisms in place for the two endpoints of a > route to collaboratively find such a route. This includes telling the > recipient ginving the sender hints as how best to reach the recipient, > e.g., adding channel information in the invoice. In the long-term we > also plan to add landmarks. When you say "we have mechanisms in place", you refer to the descriptions available in https://github.com/lightningnetwork/lightning-rfc? Interesting to know that you have landmark-based routing in your plans. Given the time, I would be obviously interested to talk to you more about it and possibly collaborate on that if you find it suitable. > > Personally I'd like to separate the base routing layer and the onion > routing layer eventually. The base layer would provide end-to-end > connectivity between any two nodes and the onion layer would then simply > chose some random nodes in the network and not be bound to the networks > topology. The same way IP and TOR are not mixed. Yes, I totally agree. I also think that this separation would help us to better understand what are the necessary and/or sufficient guarantees required in both layers for the LN to work. > >> One approach is that each user in the LN locally stores the complete set >> of opened channels either by looking at open channel transactions in the >> blockchain or by a gossip protocol. However, this approach has trivial >> privacy issues and it is not scalable for a growing number of users and >> channels between them. Moreover, this approach is no longer possible if >> open channel transactions can be modified such that they are >> indistinguishable from other Bitcoin transactions. > > The funding transactions are currently indistinguishable from any other > P2SH transaction. We currently only rely on being able to reveal the > script behind the P2SH hash in order to prove that indeed the two > endpoints have setup a channel. The gossip protocol does not require the > information to be identifiable on-chain, only that we can verify some > commitment to what we are claiming. Could you please point me to where this mechanism is described? I have been thinking about this, but the solution is not completely clear in my mind yet. > > Cheers, > Christian Thanks again, Pedro.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
