Lightning Network Skepticism

I like the idea of the lightning network. I think the developers behind it are very smart and it’s a very clever use of Bitcoin contracts. I’m sure that whatever comes from it will be useful to some parts of the Bitcoin ecosystem at a minimum. What I’m not for, however, is prematurely deprecating critical parts of bitcoin (zeroconf transactions and low transaction fees) when it’s not yet clear that the lightning network will be a viable replacement for them. Yet that’s what the core developers seems bent on doing.

We know that lightning is at least technically feasible. We don’t know if it’s economically feasible or even a desirable alternative. Will it be a decentralized peer-to-peer payment layer or will it end up as a quasi-centralized payment network similar modern banking? We don’t know the answer to this question and probably wont know until we see it in action. Which is why it comes across as irresponsible to go “all-in” on lightning at this point.

My main concern from the beginning was that, as a hub-and-spoke payment layer, there would be very few hubs and the network would be quasi-centralized and a regulatory sitting duck. It seems I wasn’t the only one with this concern as there’s been a fairly recent pivot away from the hub-and-spoke network topology to a more organic, wallet-to-wallet routing. The network is now envisioned as a more pure p2p payment layer without those large scale payment hubs.

Certainly this has to be viewed as a promising development as it begins to address my primary concern. Unfortunately, I find this view of the lightning network overly optimistic. In what follows I will give a lightning network overview and some reasons why I think it’s likely the network will end up with the hub-and-spoke topology anyway.

How it works

At the core of the lightning network is the concept of payment channels. Using some complex bitcoin scripts, two parties can create a “channel” that, once opened, can allow them to make an unlimited number of trustless “off-chain” transactions.

To open the channel, both parties jointly create a transaction in which one or both of them deposits bitcoins into the channel. This transaction gets broadcast to the bitcoin blockchain. In the above example Alice has funded the channel with 0.5 bitcoins and Bob with 0.8.

To close the channel either party can broadcast a second, on-chain transaction to the bitcoin network that will payout both parties what they paid in. However, at any time while the channel is open, both parties can jointly agree to modify the payout distribution of the channel without needing to make an on-chain transaction. For example, if Alice wants to pay Bob 0.1 BTC, they could update the payout distribution such that Bob gets 0.9 BTC and Alice gets 0.4. And payments can be made back and forth like this an unlimited number of times as long as the channel remains open.

A network of channels

To see how this could be expanded into a payment network consider the following:

Above, Alice wants to pay Bob 0.5 BTC, but she does not have a channel open with him. Fortunately, she does have a channel open with Charlie, who has a channel open with Bob. Alice can basically route her payment to Bob through Charlie using something called a hashed timelock contract (HTLC).

To do this Alice sends a message to Bob saying “Hey, I want to send you a payment”. Bob responds by generating a random number (R) and sending Alice the hash of that number (H) (you can think of the hash of R as an encrypted form of that number). Alice’s wallet then contacts Charlie and says, “Hey Charlie, if you can provide me with the unencrypted value (R) that produced (H) then I will consent to updating the payout distribution of our channel so that you get 0.5 BTC more and I get 0.5 BTC less”. Charlie agrees even though he doesn’t (yet) know R. Charlie then goes to Bob and says, “Hey Bob, if you can provide me with the unencrypted value (R) that produced (H) then I will consent to updating the payout distribution of our channel so that you get 0.5 BTC more and I get 0.5 BTC less.

Now Bob knows R since he’s the one who generated it, so he immediately gives R to Charlie and updates the payout distribution of the channel. Charlie then gives R to Alice and updates their channel and then boom, Alice paid Bob 0.5 BTC off chain.

The original vision of the lightning network was that of a hub-and-spoke network.

Your wallet would connect to a “payment hub” which would play the role of “Charlie” in the above example. By having the various payment hubs maintain channels with each other Alice, who has a channel open with hub A, could pay Bob, who has a channel open with hub B, the same way as before only with one or two extra hops in between.

This network topology would be OK if there are many small payment hubs (like hundreds or thousands), but would royally suck if there are only handful of large hubs. It would be Visa, MasterCard, and Amex all over again.

How many hubs?

It’s impossible to forecast the exact number of hubs that would exist in the network in equilibrium, but there is at least some reason to think the number will be smaller rather than larger. While it’s true that the software will be open source and anyone will be able to run a payment hub (at least until the government decides to regulate it), the high cost of running a payment hub is likely to serve as a severe barrier to entry and create centralization pressure.

What cost am I talking about? Let’s go back to the example where Charlie played the role of the “payment hub”:

Recall that for Alice to send bitcoin to Bob (through Charlie), Charlie had to update the distribution of the channel he had with Bob (paying Bob more and himeself less) before he updated the distribution of his channel with Alice. In other words, Charlie had front Bob 0.5 BTC (for a very short period of time) before he was reimbursed by Alice.

This implies that if Charlie wants to be a payment hub, he needs to deposit enough of his own bitcoin into a channel with each of his “customers” to facilitate these off-chain payments. If Charlie didn’t have at least 0.5 BTC ($220 at today’s price) pre-deposited in Bob’s channel, then the payment could not have been made.

Now this money does not constitute a loan of any sort. Charlie would retain 100% control of it. But the money at least needs to sit there in these channels to facilitate these off-chain payments. We know that the time value of money is a thing, so there is a very real cost to operating a payment hub. Not to mention you need to come up with a lot of money up front just to get started.

How much should a payment hub pre-deposit in each channel? I have no idea, but let’s just say it’s $500 worth of bitcoin. If you want to run a payment hub that serves just 100 people, you would need $50,000 capital just to start up (and more realistically will be in the millions). Some redditors I’ve run into seem to think people will be able to run payment hubs from their bedrooms. I’d like to suggest that’s not going to be the case.

So at the end of the day centralization is a major cause for concern if the lightning network ends up with a hub-and-spoke topology.

Wallet-to-wallet routing

Can we do better than the hub-and-spoke model? Recently there’s been a lot of talk about avoiding payment hubs and trying to create a more decentralized, organic routing between wallets. How would this work? Consider an example where Alice wants to pay for a cup of coffee. Using the same technique as before her wallet would try to find a route through other nodes in the network to pay the coffee shop. If it can’t find one, the wallet will just open a new channel with the coffee shop, pay for the cup of coffee, then leave the channel open for future use. Alice’s wallet could theoretically maintain dozens of open channels.

If a new channel is opened every time someone tries to pay for something but can’t find a route, eventually some organic routing paths between users will start to form. For example:

What we see above is Alice left her channel with the coffee shop open. Bob did the same thing last time he went to that coffee shop. He also recently bought a new tie from a retailer and his wallet opened a channel for that payment as well.

In this example, Alice should be able to not only send bitcoins off-chain to Bob, but also to the retailer using the routing paths that formed organically. Great! This looks like we’ve solved the centralization problem in the lightning network. But we have to ask is this type of routing feasible? I, for one, hope that it is because the Bitcoin Core developers have bet the house on it. But when you think about it a little more deeply it may not be in practice. I’m going to list off some reason why.

Routing paths are much harder to find when values are considered.
In the above example, we were able to get a route from Alice to the retailer going through the coffee shop and Bob. In reality, it will likely be difficult to find organic routing paths for the value we need. Let’s add some values into our example:

Both Alice and Bob paid $5 for the cup of coffee (0.011 BTC) which is why the coffee shop has 0.011 BTC on its side of both Alice and Bob’s channels. For Alice to send any money to either Bob or to the retailer, the coffee shop needs to update the payout distribution of the channel it has with Bob, paying itself less (by the amount Alice wants to send) and paying Bob more. But notice the coffee shop only has 0.011 BTC ($5) in its channel with Bob. This means that the most Alice could send to either Bob or the retailer is just $5. If she wants to send any more than that, she will need to open a new channel.

It’s likely this type of value asymmetry will happen fairly frequently as people are paying each other different amounts for various things. Finding paths from one node to another should be easy. Finding paths where every hop has the correct value will prove to be the difficult part.

We could end up making more on-chain transactions.
Consider how Alice had to open a new channel when her wallet couldn’t get a route to the retailer for the amount she wanted. Presumably, at any given time most, if not all, of the bitcoin in your wallet will be sitting in channels. Where would Alice’s wallet get the bitcoin to open a new channel with the retailer? Well, it will have to close one of its existing channels. So the process for making a transaction when your wallet can’t find a route is:

1) Make an on-chain transaction closing out an existing channel.
2) Make an on-chain transaction opening a new channel with the payee.

That’s two on-chain transactions just to make one payment. If a large percentage of transactions fail to find a route (and thus have to close a channel and open a new one), most of the savings could be wasted. If more than 50% of transactions fail to find a route, the lightning network will actually result in more on-chain bitcoin transactions than just paying people directly.

The vast majority of users will be offline.
To the extent anyone even uses a desktop wallet, they rarely keep it open 24/7. They either close it out when not using it, shut their laptop lid, turn off the computer, etc. Additionally, most people are using mobile wallets which go to sleep and do not remain online all the time. So we end up with a scenario where 99% of our expected users are not going to be able to participate in routing payments. If it seemed unlikely that organic routing was going to work well before, how less likely does it seem when 99% of users are not going to be participating?

Channels cannot be created on-the-fly.
Remember the magic sauce of organic routing is the ability of wallets to open new channels on-the-fly when they can’t find a route. In our original example, Alice went to pay the coffee shop, couldn’t find a route, so her wallet just opened a new channel and kept it open.

This may have worked in the past, but remember the Core developers have now pushed full RBF on us (and note it won’t be “opt-in” when blocks are full. It will be mandatory else your transactions will get stuck). So you simply can’t open channels on-the-fly (at least not for retail purchases). You will only be able to make a payment once the channel has confirmed since the coins which funded the channel could be trivially double spent otherwise. So what we are left with is if you can’t find a route through existing (confirmed) channels, you cannot make a payment to a retailer. This is going to create enormous pressure to use large well-connected payment hubs because that will be the only way you can guarantee to get a route through confirmed channels.

Recipients have to be online.
Remember back to the original explanation of routing using hashed timelock contracts. Alice’s wallet contacted Bob’s wallet and asked for a hash of a random number (R). Well, Bob basically needs to be online to give that to her. This is in direct contrast to Bitcoin as it is currently used where the sender and recipient don’t need to be online at the same time. Of course Bob could outsource this function to a third party (which is an ugly solution IMO), but this is just going to create even more pressure to just use a payment hub rather than organic routing.

So when we consider all of the above points, it seems very likely that this organic wallet-to-wallet routing isn’t going to work very well and there will be pressure to use the original hub-and-spoke model.

Given all this (which has to be known to the Core development team) there’s really no way you can justify the rush to deprecate core features of bitcoin without waiting to see how the lightning network plays out. If the lightning network ends up sucking (let’s hope it doesn’t), then so will bitcoin as we will have no choice but to use it by that point.