Re: [Lightning-dev] General question on routing difficulties

Hi Laolu, Thanks for your detailed and interesting reply. Please see below some points I would like to make in some of your comments and the answers to your questions in the last email. And of course, I would be happy to further discuss with you. On 11/25/17 2:16 PM, Olaoluwa Osuntokun wrote: >

Re: [Lightning-dev] General question on routing difficulties

Olaoluwa Osuntokun writes: > (re-sending as doesn't look like my original mail went through to the list?) I increased the limit to 80k now. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] General question on routing difficulties

Hi Pedro, I came across this paper a few weeks ago, skimmed it lightly, and noted a few interesting aspects I wanted to dig into later. Your email reminded me to re-read the paper, so thanks for that! Before reading the paper, I wasn't aware of the concept of coordinate embedding, nor how that

Re: [Lightning-dev] General question on routing difficulties

Hello, I am in the process of studying your routing approach and a doubt arised related to the privacy of payments. The current LN accomplishes payments thorugh onion-like packets which do not reveil the path, but just previous and next hops. Your approach also aims at obfuscating the path. What

Re: [Lightning-dev] General question on routing difficulties

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 >

Re: [Lightning-dev] General question on routing difficulties

Hello Giovanni, thanks for you interest in our work. 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

Re: [Lightning-dev] General question on routing difficulties

Hello, my name is Pedro Moreno-Sanchez and I am a PhD student at the computer science department at Purdue. I would like to bring to your attention a novel routing algorithm suitable for the Lightning Network (LN) that I have been working on with my supervisor Prof. Aniket Kate (Purdue

Re: [Lightning-dev] General question on routing difficulties

Hi Christian, Are there any open source simulators available for trying different routing strategies? Or even a simulator for the Lightning network as a whole? Regards sarva On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker < decker.christ...@gmail.com> wrote: > Oh yeah, my mail tool

Re: [Lightning-dev] General question on routing difficulties

Thanks for the links! And just to clarify, my other comments relate to cryptographic conservatism in general, and not specifically to routing. I switched topics, sorry for the confusion. On Nov 17, 2017 9:30 AM, "Christian Decker" wrote: > Oh yeah, my mail tool

Re: [Lightning-dev] General question on routing difficulties

Oh yeah, my mail tool destroyed that mail quite expertly :-) The footnotes were [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/07-routing-gossip.md [2] https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad [3]

Re: [Lightning-dev] General question on routing difficulties

"I think this is exactly the right venue to discuss these kinds of issue..." - you are probably right! My bad. Christian, thank you for your knowledgable reply. The footnotes did not come through on my end, I am especially interested in [3]. Do you have a link? I am thrilled to hear of a

[Lightning-dev] General question on routing difficulties

I came across a thread discussing lightning network on reddit. A comment was stating there is an unresolvable issue with the concept of lightning network, related to routing. Quoting the comment: "The problem is, actually scaling and preventing decentralization requires far more than a nice UX