From laolu32 at gmail.com Sat Nov 25 19:09:15 2017 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Sat, 25 Nov 2017 19:09:15 +0000 Subject: [Lightning-dev] General question on routing difficulties In-Reply-To: <15b5026a-a718-eeff-4751-c79c5d30dc93@purdue.edu> References: <49e10ec4-83ef-df0e-ae87-598bbf7e0784@purdue.edu> <7460ab71-480b-8257-c901-d958990ae6d9@purdue.edu> <15b5026a-a718-eeff-4751-c79c5d30dc93@purdue.edu> Message-ID: On Sat, Nov 25, 2017 at 11:13 AM Pedro Moreno Sanchez wrote: > When you say "we have mechanisms in place", you refer to the > descriptions available in > https://github.com/lightningnetwork/lightning-rfc? > I think he's referring to the ability to add "routing" hints to the BOLT 11 payment requests. > > > 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. > > Not quite sure what y'all mean by this. If there doesn't exist a direct path, then how can one use onion routing to complete the transfer? > > 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. > > At my talk at Scaling Bitcoin, I outlined two possible paths: 1. Assuming a schnorr-like signature protocol eventually gets into Bitcoin, nodes would use a cooperative signature in lieu of mulit-sig. 2. Or today, use a 2-party ECDSA protocol to generate a joint key, and sign using that to update the channel. -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: