From pm+lists at acinq.fr Wed Sep 16 10:27:32 2015 From: pm+lists at acinq.fr (Pierre) Date: Wed, 16 Sep 2015 12:27:32 +0200 Subject: [Lightning-dev] network topology and routing In-Reply-To: <20150915131721.GA27909@navy> References: <20150915131721.GA27909@navy> Message-ID: > Both these indicate each wallet (end-user) is connected to just one node; > I'd expect the usual case to be two or three so you can more easily deal > with downtime by a node. Yes, I skipped that. > 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 ! > Also, if there's a lot of traffic from node A to node B, their channel > will become lopsided (B will own all the coins), if it turns out that > C has channels with both A and B, a circular transaction A -> C -> B -> > A would allow those channels to rebalance (and x->A->C->B->y would allow > x and y to continue to transact despite A->B being full). If that happens > a lot, it might be profitable for everyone concerned if "C" sets up a > node that only does that, and doesn't deal with end-users directly. This makes sense, although if I am not mistaken it can only be done once, because then C will own all the coins in the channel A-C, and if A-B becomes lopsided again A will need to find yet another circular route. I would think in that case B would be more likely to cash out as mentioned here : http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000185.html. In fact, I think that members of the lightning network will be "strongly typed": overall they will either mainly send or mainly receive money. > That's optimal for efficiency, but probably pessimal for privacy. If > lightning is fast and cheap enough, delaying things slightly for a > significant increase in privacy would be worthwhile. Agreed. > 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 ? >> 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 ? > > 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. > 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 ? Cheers, Pierre