[Lightning-dev] Opening channels with neighbors for cost/connectivity benefit

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Mar 28 05:41:10 UTC 2018


Good morning Karan,

Channel direction cannot be determined publicly, as sharing that information would be equivalent to broadcasting how much you own on a channel to everyone, and updating everyone about each transaction made on that channel.  This hurts privacy.

I believe lnd implements the Barabasi-Albert model which tries to look for hub nodes and preferentially attaches to those, but I worry that this would cause effective centralization of the network, which will hurt privacy and possibly network availability.

See also my recent pointless rants about cyclic superhubs.  These encourage a gridlike network with good alternative routes, but is not implemented by anyone at all yet, making it pointless to implement in the first place, since they would work only if everybody strongly prefers them.  It also does not handle very well when a good number of nodes are shut down regularly, or are buggy, and you would strongly want to have atomic multipath payments in order to be able to spread out your counterparty risk to more nodes.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On March 27, 2018 11:57 AM, Karan Verma <karanverma at alumni.stanford.edu> wrote:

> Hello,
>
> The sender node doesn’t always have a route to the receiving node accepting lightning payments and since opening new channels is costly - I was wondering if there was a smarter way to open channels such that it increases the connectedness of the sender node with other nodes in the network and also possibly save money in the intended transaction.
>
> To clarify, if Bob wants to send money to Alice but doesn’t have a route to her. He would need to open a new channel with Alice and send the money. This is costly for Bob if that was the only transaction he ever wanted to do with Alice. However, if Alice was connected to Charlie and Dave (Unidirectional: Charlie -> Alice & Dave -> Alice due to the amount being sent). He could instead connect with Charlie/Dave or nodes connected with them which have a route to Alice through Charlie/Dave such that it minimizes the transaction cost to reaching Alice (some routes might have negative fee) and maximizes the number of nodes Bob can now reach through this channel. Lets say if Bob chose Charlie's neighbor, then he can now reach at-least three nodes - Charlie's neighbor, Charlie and Alice and end up paying less.
>
> Essentially we're sorting choice of the nodes to open a channel with by transaction fee and connectedness it brings to the origin node. This would benefit Bob in the long term and also maybe lightning network as a whole. I'm new to lightning and would appreciate feedback on this idea. Thanks.
>
> -Karan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180328/9f24d0ac/attachment.html>


More information about the Lightning-dev mailing list