[Lightning-dev] network topology and routing

Rusty Russell rusty at rustcorp.com.au
Thu Sep 17 21:30:17 UTC 2015


Hi Pierre,

        Sorry for the delay; Blockstream had a big meeting after the
Montreal Scaling Bitcoin workshop, so I've been distracted.

Pierre <pm+lists at acinq.fr> writes:
>> If I'm an end-user with a wallet with two channels; and I switch my
>> software to being a full lightning node with the same two channels, I'd
>> end up in this state. Likewise if I was a new node trying to establish
>> myself on the network.
> I understand the idea and advantages of everybody running a node, to
> be honest I implicitely discarded this possibility in favor of a
> limited (10s ? 100s ?) number of specialized supernodes. I feel like
> having a lot of small nodes that constantly appear and disappear is
> somewhat incompatible with a reliable and low latency (<1s ?) payment
> network, but I admit I am probably too pessimistic !

Me too.  Initially I was thinking of hub and spokes like this.  It's
certainly far simpler to organize routing among a few thousand
supernodes.

But the interests of robustness privacy, decentralization, and the
tantalizing possibility of negative fees all point to a flatter
design (though I expect some power law to emerge).

>> Setting up channels isn't free, though -- it costs a blockchain
>> transaction, and locks up bitcoins for no value if the channel's idle --
>> so you also want to minimise the number of channels, not just the number
>> of hops for a transaction.
> This actually leads me to the "supernode" conclusion. End user would
> only have a handful of channels set up with a few of those large,
> well-connected nodes.
> Just one remark on the fact that funds would be locked in a channel:
> if lightning is widely successful and becomes the primary way of doing
> payments, don't you think that this would change our perception of
> which funds (in a wallet or in an open channel) are actually more
> usable ?

Possibly.  But if it's the primary method of payments, you won't think
of them as "locked in a channel".

>>> Then we just agree on a standard port and that's it !
>>> Isn't it how the internet works already ? Why do we need an
>>> application-level routing on top of the IP routing ?

You still need non-IP routing, unfortunately.  It's an overlay network
of channels (probably across multiple networks, like TOR, UDP etc),
and there's no logical grouping to make routing tables smaller than
"every node".

>> 1) It'd be expensive to join the lightning network (if I wanted to be
>> able to send up to $5 to anyone, and there were 100 nodes on the
>> network, I'd need to commit $500 to lightning channels up front).
> In my view you would just be connected to a few nodes which would
> handle the rest.

Definitely.

>> 2) It'd be easy to block payments (USA bans anyone from setting up
>> channels with anyone in Cuba; Cubans can't run nodes)
> Good point...
>
>> 3) If there's a communications blockage, there's no ability to route
>> around it.
> True, but this is mitigated by the fact that every participant of the
> network would be connected to a few nodes, so we can imagine that a
> merchant would require to be paid at id1 at node1 or id2 at node2 ?

I started exactly where you are!  I was forced to throw it away to try
to make it as distributed-by-default as possible.  That all nodes are
equal to by design, and we try to be clever with routing.

I think I have a method, too.  It won't scale infinitely, but might work
for a few million nodes...

Cheers,
Rusty.


More information about the Lightning-dev mailing list