Taking 10m LN users network design challenge myself

In http://bit.ly/2tFiFYx Diane took a challenge to design LN for 10m users. I'm going to take that challenge today myself because I didn't like the result that much. It seems to me that achieving such a topology in real world would be hard. My goal is to propose a slightly more realistic topology, but at the same time, not spending too much time on it by coding the simulations. If anyone is happy to expand on the following idea, feel free to do so, if someone is able to provide exact numbers in the parts where I'm missing them, I'd appreciate that. And of course, please excuse any errors, feel free to point them out – consider this as very first and quick draft.

The Diane's topology is nice theoretically, but for me, it is hard to imagine that it would be useful in the real world. The important parameters in her topology were

  • 14 open channels per user;
  • 0.01 BTC per user/direction in each channel (i.e. 0.02 BTC per channel in total);
  • total of 1.4m BTC locked in all channels;
  • 70m open channels;
  • 17.5 hops on avg, 35 hops max to reach anyone.

Let me start with 0.01 BTC per user per channel. For me, that does not make any sense if we are talking about 10m LN users. This makes sense to day, with BTC price of $2500, so the user's 0.14 BTC in all their channels is worth $350. But you do not expect 10m LN users today (or the next day after SW activates). You would expect some small thousands to be on LN within first couple of months. 10m LN users for me is a lot and a great success of BTC in general. That would have to be hugely reflected in the price. So for me, 10m LN users would mean the price of BTC should be somewhere in $50k-$100k range. For simplicity I'm expecting 1 BTC to serve at least 100 users (with $350 locked per user, this would require the price of $35k). If you don't think this is realistic then consider that $40b market cap is not exactly nothing, but for some real scenarios (like buying 10 A350 airplanes for your airline) is completely unusable.

Then 14 open channels per user – this is little too much for me, it simply requires too many on-chain transactions. It also limits the maximal transaction the user can do.

Total of 1.4m BTC locked in all channels – I'm OK with this one. If LN is a huge part of BTC ecosystem, then having cca 10 % of all available BTC in LN is not a problem for me.

Then we have 70m open channels – I'm OK with this one, but if we can lower that, it would be great.

Up to 35 hops to reach anyone – quite a lot for my taste, but not impossible.

Now let me suggest a different network topology that, for me, is closer to the real world scenario. For simplicity, I'll be talking about average nodes and average users, but you can imagine all different kinds of nodes and users within reasonable ranges around the given average numbers.

In my network (on average!):

  • say we want a user's budget (locked) to be $350 (0.01 BTC per assumption) in LN;
  • each node has 1 BTC for node-to-node communication and if it wants, it can have another 1 BTC for its merchant users (see below);
  • each node serves 100 end users (see the above assumption of 1 BTC serving at least 100 users) and connects to 10 other nodes;
    • each node-to-node channel has 0.1 BTC in each direction;
    • each node-to-user channel has up to 0.01 BTC (deposited by the user, not the node!) in one direction (see below) and most users will use just 1/3 of this max capacity (see below again), for merchants this will be bidirectional with whatever the parties are happy, up to the total of 1 BTC per node for all merchants;
  • users are allowed to be offline without facing a security risk;
  • users mostly have unidirectional channels, but there can be special types of users having bidirectional channels;
  • merchants are considered as special users (with bidirectional channels), they are expected to be mostly online, but getting offline would not be risky;
  • there is a default fee setting in the node software of 0.5% fee for node-to-user and 0.001-0.01 % fee per transaction for node-to-node transaction;
    • since the fees for node-to-user are way higher than node-to-node, nodes are incentivized to have users and not only node-to-node connections;
    • there might be different fee plans for different types of merchants;
  • user's LN wallet software is expected to randomly choose 3 nodes to open channels with, each giving 1/3 of the allocated $350 budget;
    • there might be some prefiltering of unreliable nodes (think of third party monitoring services that exist today for websites, measuring the uptime of each node), in order to avoid creating channels with unreliable parties;
    • this is purely to provide availability to the user, should one of the nodes be unavailable;
  • there are 100,000 nodes (could be twice as much or 5x as much and it would not make any difference, market will decide how many);
  • for the transaction fees, nodes also provide third party monitoring, so that users can delegate blockchain monitoring of fraud transactions (fraud channel closing) to their nodes;
    • obviously you won't delegate watching your channel with the node to that node, but you have 2 other nodes for that …;
    • this is mostly important for merchants, because unidirectional users don't have this risk (AFAIK -> correct me if I'm wrong here);
  • each node is connected to 10 random nodes;
    • there may be some prefiltering, trying not to connect to direct neighbors of my direct neighbors or alike;
  • nodes are allowed to have additional hosting fees;
    • for example, a node may say that it will accept the user for 1 month for free and if the user does not make transactions of at least X BTC over the channel then it would have to pay Y for next month otherwise the channel will be closed (but this is very wild idea I just thought of, not sure if it makes sense, maybe we would need upfront payment for the first month instead).

We have 100k nodes, each serving 100 users, that makes it 10m end users. For each node there are (up to) 2 BTCs locked and each user also locks 0.01 BTC on its own – so we have up to 200k BTCs locked by nodes and 100k BTCs locked by their users and something by merchants, let's say another 100k BTCs locked (to make node-merchant channels in 50/50 balance). Each node has 110 open channels, the total of 11m open channels. On one hop, a node will be able to reach 10 nodes. On two hops, it will be cca 100 nodes, on three hops, it will be less than 1000, but not so much. Not doing math properly (sorry), but after 8 hops, you should be able to reach any other node. So a user to merchant use case should not require more than user -> 8 nodes -> merchant (i.e. 10 network members at max, but usually much less, fix my math again here).

So we have:

  • 400k BTC locked in LN;
  • $350 in 3 buckets for end user
  • 0.5 % fees for end user (+ epsilon for node-to-node to reach the destination)
  • 100k nodes
  • 3 open channels per user
  • less than 10 hops max
  • 11m channels in total
  • assumption of $35k per BTC price (but this is ONLY to achieve 10m LN users, remember we won't have 10m LN users any time soon, so current price of $2500 is very usable for 700k LN users)

Is this the terribly evel centralized hub LN that opponents are worried about? I don't think so. The user is not forced to select specific node or even from any specific minor subset of nodes in the network. The only thing that can happen is that the node says that it can not accept more users (does not have funds for example, or its policy says that certain number of users is its max). The model is still trustless (the user does not give its keys to anyone and can not lose money by fraud). Having e.g. 3 nodes per user means that there is a solid availability – the chance of all 3 nodes (if chosen randomly) go all offline at once is very small. There is no central node or a minor set of nodes that if they all go offline at once that it would hurt the network. So the system is decentralized. There is no central authority and you are free to run your node and join the network. No one even forces you to have the same settings as other have. You still can run node that won't accept any users and the network will run just fine.

Submitted July 10, 2017 at 05:55PM by krazyest
via reddit http://bit.ly/2u9oEWA