Lightning Network Skepticism

I like the idea of ​​Lightning. In my opinion, the developers behind Lightning are smart and are very smart in choosing to leverage the Bitcoin protocol. I believe that anything Lightning can do is good for the Bitcoin ecosystem. However, I disagree that it is too early to devalue Bitcoin Core (zero-configuration network transactions and low transaction fees) when it is still unknown whether Lightning can successfully replace Bitcoin. However, this seems to be what the core developers are determined to do.

We know that the Lightning Network is at least technically feasible. We just don’t know if it’s an economically viable, or even desirable, alternative. Will it become a decentralized peer-to-peer payment layer? Or will it end up being a quasi-centralized payment network like modern banks? We won’t know until we see it in practice, which is exactly why it’s irresponsible to bet everything on Lightning.

My main concern at first was that as a hub-and-spoke payment layer, it had very few hubs, a quasi-centralized network, and a vulnerable regulator. And it seems that I am not the only one who has such doubts, because the emergence of the latest pivot is different from other hub-and-spoke network topologies, it becomes a more organized, wallet-to-wallet path. This network structure can be imagined as a purer p2p payment layer without those large payment layers.

Of course, this development was not surprising to me, as it confirmed my initial doubts. Unfortunately, I think this view of the Lightning Network is too optimistic. Below I will give an overview of the Lightning Network and explain some reasons why I think this network structure is likely to end up in a hub-and-spoke topology.

How the Lightning Network works

The core concept of the Lightning Network is the payment channel. Using some complex Bitcoin scripts, two parties can establish a "channel" that, once opened, allows them to make countless trustless "off-chain" transactions.

In order to open this channel, both parties need to jointly establish a transaction, one or both parties in the transaction need to deposit bitcoins into the channel, and then the transaction is transferred to the Bitcoin blockchain. In the example shown above, Alice invested 0.5 bitcoins in the channel, and Bob invested 0.8 bitcoins in the channel.

When the channel is closed, each party has one second to react, and the Bitcoin network's on-chain transactions will pay for the transaction on both sides. However, when the channel is open, both parties can negotiate and modify the payment allocation at any time without on-chain transactions. For example, when Alice wants to pay Bob 0.1BTC, they can update the payment allocation, where Bob can get 0.9BTC and Alice will get 0.4BTC. As long as the channel remains open, they can trade without restrictions.

Channel Network

You can see how this scales to a payment network by considering:

As shown in the figure above, Alice wants to pay 0.5 BTC to Bob, but she does not have a channel to trade with him. Fortunately, she has a trading channel with Charlie, and Charlie happens to have a trading channel with Bob. In this way, Alice can use Charlie's trading channel to trade with Bob through the hashed timelock contract (HTLC).

To complete the transaction, Alice will text Bob and say, "Hey! I want to pay you a sum." Bob will then receive a random number (R), and then Bob will send a hashed number (H) back to Alice (you can think of the hashed number R as an encrypted form of the random number). Alice's wallet will then contact Charlie and say, "Hey, Charlie. If you give me the unencrypted value (R) that generates (H), then I will agree to update the payment allocation of our channel so that you can get a little more than 0.5BTC and I can get a little less than 0.5." Even though Charlie doesn't know R, he will agree. Charlie will then go to Bob and say, "Hey, Bob. If you give me the unencrypted value R that generates H, I will agree to update the payment allocation of our channel so that you can get a little more than 0.5BTC and I can get a little less than 0.5."

Because R was generated by Bob, he must know it. Then he immediately told Charlie R and updated the payment allocation of his channel. Charlie then told Alice R and also updated their channel. Finally, the transaction was completed and Alice paid Bob 0.5BTC in an off-chain manner.

The Lightning Network was originally conceived as a hub-and-spoke network.

Your wallet will be connected to a "payment hub", which is the role played by Charlie in the above example. Since the various payment channels are open to each other, Alice has a channel with hub A, and Bob has the same channel with hub B, so Alice can trade directly with Bob. Compared with before, the same method can now be completed with only one or two extra hops between them.

This network topology works perfectly if there are lots and lots of small payment hubs (hundreds or thousands). However, if there are only a few large hubs, this network topology fails completely. It's the next Visa, MasterCard or American Express.

How many transfer stations are needed?

It is impossible to accurately predict the number of payment gateways that will exist in the network equilibrium, but there are some reasons to believe that this number will gradually decrease rather than increase. However, it is undeniable that this is open source software, and anyone can run a payment gateway on it (at least until the government decides to regulate it), but the high cost of running a payment gateway is like a solid barrier to entry, thus creating centralization pressure.

What kind of costs am I talking about? Let's go back to the example of Charlie acting as a "transaction broker."

Recall that Alice needs to pay Bob (through Charlie) the bitcoins, so Charlie has to update his channel with Bob before updating his channel with Alice (paying more to Bob means getting less). In other words, Charlie has to pay Alice before he gets Bob's 0.5BTC (a short time later).

This means that if Charlie wants to be a payment hub, he must deposit enough bitcoins in the channels shared by his "clients" to facilitate off-chain transactions between these "clients". If Charlie does not deposit at least 0.5 BTC (which would be $420 today) into Bob's channel, then the transaction cannot be completed.

Now, this money will not constitute a loan in any way, and Charlie will retain 100% control of it. However, the money still needs to at least be in those channels in order to facilitate those off-chain payments. As we know, the time value of money is a thing, so there are some real costs to running a payment hub. Not to mention the need to come up with a large sum of money before you even start.

How much should a payment hub deposit per channel? I don't know, let's just say it's $500 worth of Bitcoin. If you want to run a payment hub that serves 100 people, you need $50,000 in assets to start it (more realistically, that number would be in the millions). Some people in the media I've met seem to think that people can run their payment hubs from their bedrooms, but I would like to say that this is not the case.

Therefore, if the Lightning Network eventually becomes a hub-and-spoke topology network, then centralization will be the biggest concern of the day.

Wallet-to-wallet path

Can we design a better model than the hub-and-spoke model? There has been a lot of talk about stopping payment hubs and trying to create more decentralized, organized wallet-to-wallet paths. But how does this work? Imagine if Alice wants to buy a cup of coffee. Before she can do so, her wallet will use the same technique to find a path through other nodes in the network to pay for the coffee. If the wallet can't find any nodes, it will open a new payment channel with the coffee shop to complete the transaction, and then keep the channel for later use. In theory, Alice's wallet can maintain dozens of open channels.

If someone fails to find a channel every time they try to pay, new channels will open up, and over time some organized channel paths between users will form, such as:

From the above figure we can see that Alice kept her payment channel open after leaving the coffee shop, Bob also kept his payment channel open after his recent visit to the coffee shop, and he also bought a new tie from the store, which is also in an open state.

In this example, not only can Alice pay Bob off-chain, she can also pay the store owner from the organized path that has been formed. This is awesome! It seems like we have solved the centralization problem in the Lightning Network. But we have to ask, is this type of path feasible? Personally, I certainly hope it is possible, because the Bitcoin Core developers have bet the house on it. But when you think about it, this approach is impractical. Here are some reasons why this approach is impractical.

When considering specific values, the routing path is difficult to find

In the above example, we can get a route from Alice to the store and through the coffee shop and Bob. In real life, it may be difficult to find an organized routing path with the values ​​we need. Let's add some concrete values ​​to our example to try it out:

Alice and Bob both spend $5 to buy a cup of coffee ($0.011 BTC), which is why the coffee shop has 0.011 BTC in both Alice and Bob's channels. For Alice, whether she wants to give the money to Bob or the store owner, the coffee shop owner needs to update his payment distribution channel with Bob, so that the coffee shop owner gets less (from the money Alice wants to pay) and Bob gets more. But notice that the coffee shop owner only has 0.011 BTC ($5) in the channel with Bob, which means that Alice can only pay Bob or the store owner $5 at most. If she wants to pay more, she needs to open a new channel.

This type of value asymmetry is likely to occur frequently when people buy different things for different amounts. The path from one node to another is easy to find, but finding the right hop each time is the hard part.

Eventually we may use more on-chain transactions

Let's think about how Alice's wallet opens a new channel if she can't find a path from the store to the amount she wants. Presumably, at a given time, most, if not all, of the bitcoins in your wallet will be in channels. So where does Alice's wallet have the bitcoins to open a new channel with the store? Well, if it has to close one of the existing channels, then the process when your wallet can't find a path when transacting will be this:
1) Close an existing channel to complete the on-chain transaction.
2) Open a new channel with the payee to complete the on-chain transaction.

Only one of those two transactions was a payment. If one large transaction can’t find a path (and therefore has to close an old channel to open a new one), a lot of deposits will be wasted. If more than 50% of transactions can’t find a path, the Lightning Network will actually facilitate more Bitcoin transactions on the chain than direct payments to people.

Most users are offline.

To the extent that people use a desktop wallet, they don’t leave it up 24/7, they close the program when not using it, close the lid of their laptop, turn off their computer, etc. In addition, many people’s mobile wallets are dormant and not always online. Therefore, we rejected this solution because 99% of our expected users will not participate in routing payments. How small is the probability that 99% of expected users will not participate if the previously organized routing is not working well?

Channels cannot be created on the fly

Remember that wallets have a magical ability to create new channels on the fly when they can’t find a route. In our previous example, Alice wanted to pay the coffee shop, and her wallet couldn’t find a route, so the wallet had to create a new channel and keep it open.

This may have worked in the past, but remember, now the core developers have added full RBF to us (note that it is not opt-in when the block is full, it is mandatory or your transaction will get stuck). So you just can't open new channels instantly (at least not for retail purchases), because the bitcoins used to open channels can be freely used in both directions to other places, so you can only pay after the channel is confirmed. So now we are left with the situation that you can't pay the store owner if you can't find a path through an existing (confirmed) channel. This will put huge pressure on using large connected payment hubs, because that's the only way you can guarantee a path through confirmed channels.

The recipient must be online

Recall the explanation of the HTLC path from the previous example. Alice's wallet contacts Bob's wallet and asks it for a hashed random number (R). Well, basically Bob needs to be online to give her that number. This can be directly compared to Bitcoin, where the sender and receiver do not need to be online at the same time. Of course Bob could outsource this function to a third party (which is a shameful solution IMO), but this just creates more pressure to use only one payment hub instead of an organized path.

So when we take all of the above points into account, this organized wallet-to-wallet path doesn’t seem to work particularly well and would put pressure on the original hub-and-spoke model.

Taking all of the points into account (namely the core development team), there is really no way to prove those eager to deprecate Bitcoin Core functionality right or wrong other than to wait and see how Lightning Network works. If Lightning Network ends up being a dead end (which we certainly don’t want to happen), then Bitcoiners will have no choice but to use it at that point, just like us.

－－－－
Original article: https://chrispacia.wordpress.com/2015/12/23/lightning-network-skepticism/
By Chris Pacia
Translator: Wang Er
BTC address: 16enj2bapYdzPfa2DWSVaT1g95MCXg2hHt
Editor: printemps
Source (translation): Babbitt Information (http://www.8btc.com/skepticism)