スケーリングビットコイン・ワークショップ: Montreal 2015

Bitcoin failure modes and the role of the lightning network

Thaddeus Dryja

Joseph Poon

I am going to be talking about bitcoin failure modes, and Joseph will talk about how the lightning network can help. I'll start. We'll start off by saying that bitcoin is working, which is really cool. Blocks starts with lots of zeroes, coins stay put, they move when you tell them to. That's really cool and it works. That's great. This is a good starting place. We should acknowledge that bitcoin can fail. But it's anti-fragile, right? What's the blockheight of the final block? There are fates maybe worse than final block.

There's this goldilocks zone, or middle of the bath tub, there's a good place in the middle. So the block size bathtub, we can take the extreme numbers where we agree everything is crazy. What would bitcoin be like with 1 kilobyte blocks? You could maybe talk the blockchain over the phone. What about 1 petabyte blocks? We could both agree that both sides are a failure there. In both of these failure modes, we agree that every human on planet earth would want to use bitcoin. This is not a pessimistic view of failure, because most people don't know about bitcoin.

So first I will talk about left side failure, 100 transactions/day perhaps, 50 MB blockchain size increase per year. You could run this on your phone. There's maybe 10 large institutions that actually have private keys and could make transactions. They have keys, you don't. Coinbase, BNY Mellon, Changetip, you have to go through them. You don't have the keys, you don't have the coins. You can, however, verify all balances that you hold with your bank.

For right side failure with super large blocks, you could still use SPV clients. Unless you have a global view of it, you don't know the total capitalization. This failure mode is sort of like federal reserve notes. The total amount of dollars, who knows. So what we want to do is expand the bathtub. We want to make sure we're within the bathtub, and expanding it would help.

More people can use bitcoin without higher global throughput of the blockchain. An example of expanding this bathtub is what we're working on, called the lightning network. The idea is that even if you're not totally picking the right point, and you need to mitigate problems like when block size gets high you still need to validate it and still use real bitcoin. The problem it really helps with is net settlement of many transactions, especially micropayments. You can have 1 blockchain transaction and it could be the net sum of many thousands or millions of transactions.

There are things that you can't do this on bitcoin today. Today you can't really do micropayments on bitcoin. They are payments below the minimum fee, such as 1/10th of a penny or 1/100th penny. At the moment the transaction fee on average is 3 cents or maybe 2 cents, so you will have trouble sending someone 1/100th of a cent. A network of payment channels certainly helps with this. If the average transaction fee goes up over time, then there might be high-value transactions might crowd out low-value transactions, and the payment channel networks are a mitigation.

If you are receiving a million micropayments on-chain, then no matter how big the blockchain is within reason, you're going to have a million transactions as inputs with a single output, that's a really really big transaction. These transactions are pretty crazy, and you want to minimize them.

The idea of the Lightning Network is that you have someone Alice open channel with Bob, Bob has channel with Carol, and Carol-Dave; and Alice can pay Dave without having the intermediates able to steal the bitcoin. You can do this with encumbering it with cryptographic hashes through bitcoin script, where if there is non-cooperation then it does hit the blockchain, but otherwise it is all off-chain. These are actual, physical bitcoin transactions between each peer. Payment paths are local, so we do need to focus on designing this correctly and ensuring that this is decentralized within the spirit of bitcoin. There must be no custodial ownership of payment along the path. You need open participation, you need anyone to run a lightning node, and you need extremely low fees.

Trusting a third-party custodian with your balance will be giving them a lot of economic rent. Trusting someone with your money is trusting them to not screw you over, so they might charge you more for that. Routing is very important because it's your client that decides how to route, so it's a local rule in a sense and therefore it's really important to ensure and enforce routing maintains decentralization. It's really also important to make sure that wallets are also channel nodes to ensure decentralization. You create this system in which you can do small bitcoin transactions in extremely high volume while maintaining the promise of bitcoin so that you can stay in the bathtub.

We can sort of look at in the failure modes and decide where in the bathtub you want to be. The red side is probably safer (smaller blocks). You want the extra functionality, but one of the assumptions here was that all 7 billion people want to use bitcoin. That may not be the case and that may never be the case. Maybe nobody wants to use it because it's too expensive to make transactions, and people would wonder why should they sign up for something where a private third-party has most keys? But in both cases, there is a lot of things you can do to mitigate these failures. When you have too large transactions, there's SPV and fraud proofs and a lot of things like that. On the low bandwidth side, you can have proof-of-solvency, different proofs where you are minimizing the trust to these institutions. In both sort of modes, we're not in a place where we want to be. We have institutions that are centralized at the moment, and we can have ways to mitigate that centralization.

We don't want to have super small blocks, and we don't want super large blocks. So where do we land then? That's a very difficult problem because of the spectrum of opinions. Well at least we can put boundaries for too small and too big.