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