From decker.christian at gmail.com Sat Nov 25 19:33:07 2017 From: decker.christian at gmail.com (Christian Decker) Date: Sat, 25 Nov 2017 20:33:07 +0100 Subject: [Lightning-dev] General question on routing difficulties In-Reply-To: <CAO3Pvs-qbkPByrSr0wR0uC_QQ2QjfuTgVq8_ar5Hw8qW=MaH8A@mail.gmail.com> References: <CAEbFcLv_Eye-Z9mHCEuRt70mWMFL9a_659cFJ0DwuJjvOYE7yQ@mail.gmail.com> <CANVuFb3bL9v2Cs8-jPqFXAZ-=sr2F5d8oXZwaQaxa-nyVB55Kw@mail.gmail.com> <CALxbBHWJk+VY8LtJNQ5PVcByXabx5YkxdcH+Vg9o8sCyNgoUBg@mail.gmail.com> <CANVuFb1Fm21R48KOunAqRopSLYFqYfMndy9fzjzZVL7U+wXPPA@mail.gmail.com> <CALxbBHXQaenE36zgwiWv1ntQHk+Y=f5MqcZ0A06n3REEYaWcnA@mail.gmail.com> <CACHbmQ3DdFHj5qFShZ6cO0UBRf8hHMFGUnawfvgSiYZkO+NPmw@mail.gmail.com> <49e10ec4-83ef-df0e-ae87-598bbf7e0784@purdue.edu> <CAMeU5JrO-iwkTAarsVdZrFVFz3fzcmqw0QF6X_Zof5GpXUnO0Q@mail.gmail.com> <7460ab71-480b-8257-c901-d958990ae6d9@purdue.edu> <CALxbBHUie=AaMrTAZ8xmtkViQAEf5V=_PE1m+ak5Z-YAmDEjxw@mail.gmail.com> <15b5026a-a718-eeff-4751-c79c5d30dc93@purdue.edu> <CAO3Pvs-qbkPByrSr0wR0uC_QQ2QjfuTgVq8_ar5Hw8qW=MaH8A@mail.gmail.com> Message-ID: <87lgiunogc.fsf@gmail.com> Olaoluwa Osuntokun <laolu32 at gmail.com> writes: > On Sat, Nov 25, 2017 at 11:13 AM Pedro Moreno Sanchez <pmorenos at purdue.edu> > 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. Exactly, that's the first instance, but there may be others in the future. Collaboratively constructing the route is necessary in cases in which parts of the network are not public (private channels), and helpful in the case of landmark based routing algorithms. >> > 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? It's a separation of concerns: the base routing layer does not include any privacy whatsoever, and takes care of routing a payment from any point to any other point in the network (think IP). Once we have that base routing layer, we can then simply pick a number of nodes in the network that are used for the onion protocol. Since we have the guarantee from the base layer that we can reach any node in the network, we can actually select random nodes. This is similar to how TOR makes use of the underlying IP protocol in order not to be constricted to physically connected machines, but circuits are built by randomly selecting nodes in the public network. Conflating base layer and OR is what gets us the routing problem in the first place. If I could be reasonably sure that the network takes care of connecting my onion hops somehow I wouldn't need to know about the entire network, just a few nodes. I should also point out that the current system was chosen in order to have privacy by default, and not just have it an opt-in option, which people might disable to "optimize". >> 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. BOLT03 [1] specifies the exact P2WSH committed script. The channel announcement specifies which public keys were used in order to establish the channel. So a verifying node can look up the transaction, specified by the channel ID, and verify that it really creates a channel between the two parties, without the funding transaction itself being identifiable as such. With a cooperative close all the network will ever see is a 2-of-2 multisig, wrapped in a P2WSH, being spent. [1] https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#funding-transaction-output