From rusty at rustcorp.com.au Thu Sep 17 21:30:17 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 18 Sep 2015 07:00:17 +0930 Subject: [Lightning-dev] network topology and routing In-Reply-To: References: <20150915131721.GA27909@navy> Message-ID: <87k2roiviu.fsf@rustcorp.com.au> Hi Pierre, Sorry for the delay; Blockstream had a big meeting after the Montreal Scaling Bitcoin workshop, so I've been distracted. Pierre 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.