[Lightning-dev] Peer Selection

Christian Decker decker.christian at gmail.com
Fri Dec 15 21:13:37 UTC 2017


For one thing having a single connection means that the peer you're
connecting to can see all your payment amounts and their timings, and
they can be sure that they are from you since you don't have any other
channel. Opening more channels gives you plausible deniability. Also
it'd make your single peer a single point of failure, meaning that if it
goes down you're dead in the water.

And then on the other end, we have no interest in running a large hub in
the first place. They're expensive to run, since we'd have to allocate
enough funds to cover the sum of payments you might receive over time
(which is already hard to know, so we'd have to over-provision). That'd
also make the hub an attractive target for an attack, since it'd have a
lot of funds sitting in hot wallets. Furthermore the utility the hub
gets from the funds it allocates to the channels going to endpoints,
such as your node, is very minimal, since it can only earn fees on
payments that are either initiated by you or received by you, meaning
the funds mostly sit idle. Compare that to a channel that is very active
because it bridges two large clusters in the network. The low
utilization of the funds in the channel also means that hubs will have
to charge large fees for the few times the channels are actually used,
which again is an incentive for you to create bypasses.

I think these arguments alone are probably sufficient to discourage the
formation of large hubs, and should incentivize even end-users to create
at least 2 channels. Remember that this is all taken care of in the
background by the client, users don't actually have to think about
opening/closing/maintaining channels, or how to allocate funds to the
channels. Our goal in the end is to create clients that show a single
balance, allow users to make both off-chain or on-chain payments from
that balance, and not require people to ever think about the details in
the background.

I appreciate your trust in Blockstream, but as our informal motto says
"don't trust, verify!" :-)

Cheers,
Christian

Stan Kladko <stan.kladko at galacticexchange.io> writes:
> Hi Cristian,
>
> If there is such a great company, BlockStream. and Blockstream runs a
> fantastic high quality node, then as a user why should I connect to
> any node other than Blockstream?
> In this case I dont need to be online all the time and dont need to
> monitor the blockchain for anything. I will just believe that
> Blockstream will do no bad to me.
>
> Why do I need to drink unnamed cola if there is Pepsi?))  People used
> to run emails servers, it is all Gmail now, much more secure and
> reliable!
>
>
>
>
> On Fri, Dec 15, 2017 at 9:06 PM, Christian Decker
> <decker.christian at gmail.com> wrote:
>> Let me add some more color to the discussion.
>>
>> If you do not announce the existence of the channel to the wider network
>> you can still receive incoming payments, by simply telling the payment
>> sender about the channel. This is what is being done in the payment
>> request by adding the `r` parameter to the request. You are selectively
>> informing the sender about the channel, which can then use that
>> information to construct the route (and onion packet) and initiate the
>> payment.
>>
>> Even though you have only one channel, and announce it, people might
>> still want to route through you, by using the channel twice: once to
>> route to you and then back out from you. While this may seem wasteful,
>> it may be useful to hide the real origin/destination of the
>> payment. Another scenario for which this is useful is that you are an
>> auditor that witnesses the payment while it is being processed, for book
>> keeping or similar cases. This would also work for unannounced channels.
>>
>> So the decision whether to announce a channel is exactly what you're
>> looking for. It allows you to do bidirectional payments, and does not
>> allow random people to route through you. Implementations might
>> eventually add an "endpoint mode" that rejects any HTLC for which the
>> node is not the origin or the destination, which would further enforce
>> this.
>>
>> Cheers,
>> Christian


More information about the Lightning-dev mailing list