Tadge Dryja
Scalability of Lightning with different BIPs and some back-of-the-envelope calculations.
slides: https://scalingbitcoin.org/hongkong2015/presentations/DAY2/1_layer2_2_dryja.pdf
video: https://www.youtube.com/watch?v=fst1IK_mrng&t=1h5m50s
I don't have time to introduce the idea of zero-confirmation transactions and lightning. We have given talks about this. There's some documentation available. There's an implementation being worked on. I think it helps a lot with scalability by keeping some transactions off the blockchain. Ideally, many or most transactions. Instead, you would open and close channels. That's all that needs to be on the blockchain. When it fails, it should fail back to the efficiency and security of Bitcoin. When people are cooperating, they should use this. When they stop cooperating, they can drop back to Bitcoin and be okay.
I think that's a good tradeoff.
But how much can this get us? What do we need in order to get this? Can Lightning work today? Well, check back nextweek. bip65 is going to be active pretty soon. bip65 is not sufficient, but it's necessary. We need relative timelocks, and the ability to reliably spend from an unconfirmed transaction, which segregated witness allows. OP_CLTV is almost active. OP_CSV (bip112) is maybe soon.
There are levels of lightning that we are prepared to accept. If we never get segregated witness, if we never get checksequenceverify, we can still use lightning, it just wont be as good. Channels can work with only OP_CLTV (checklocktimeverify), but it's much less efficient ((see here for why segregated witness is useful for lightning)). This could be ready to go next week.
With Lightning Network level 1, you need 1.25 MB/user/year. With Lightning Network level 3, you need 3 KB/user/year.
Lightning level 1 with OP_CLTV only. Only checklocktimeverify. To open a channel, this is assuming there is one participant funding the entire channel, which I think is going to be very common. Joseph in the next talk will talk about the topology of the lightning payment channels. This is a fairly optimistic size, it's the minimum size you can have. You need 1 input to open a channel. You have some UTXO outpoint, you have a couple BTC, one signature spending from that, and then 3 outputs. 2 of them would be 2-of-2 multisig with some extra opcode, and one of them owuld be change back to the funder. The channel close transaction will be 2 inputs, 4 signatures because of 2-of-2 multisig for both, and 2 outputs back to the participants to the channel, which would be about 700 bytes. Signatures are what take space and time in these transactions. Putting in new outputs is pretty easy. Channel duration would be, say, 1 week, it might be longer or shorter, I am just making this up. In the CLTV-only model, the channel duration is fixed at the beginning of this sequence of transactions. It would last at least 1 week as well. If the other guy on your channel disappears or becomes uncooperative, you have to wait the whole duration. It takes a transaction to open the channel, if you make the length really long, you can keep it open longer, you can do more things with it, but if your counterparty disappears, then you have to wait for up to a month. If the channel is opened for only a day total, then if the counterparty disappears, you can get your money back next day. But you have to renew the channel daily.
Channel monitoring, if your counterparty goes rogue and tries to broadcast a previous channel state to rip you off, in CLTV-only situation, the user must verify and must observe that. You must watch the blockchain for those 20 byte P2SH scripts. If you see that script, you know your counterparty is trying to rip you off, so then you would submit the revocation hash. It's safe, but you have to keep watching during that 1 week.
There's also a genralized channel awesomeness rating, which in this case is low. Just some subjective measurement.
The second lightning level, is OP_CSV or OP_MATURITY or whatever is the coolest name. It's relative to when the input got into a block, so it's like relative checklocktimeverify. This is a cool opcode. It lets you say you can spend this, but only once it's a week old, or you know a thousand blocks old. This allows a lot of cool things for lightning channels. The channel open and close transactions are about the same size. The channel duration is indefinite and you can keep it open for as long as you want. Both channels can cooperatively close it "immediately". There is a timeout period for the uncooperative close time, which you can make perhaps 1 week like in the other, if the counterparty disappears and he's gone, you can push the current channel state to the blockchain and then I have to wait a week to collect the money back to a non-lightning P2SH output. You could tweak this from 1 week to 1 day or 1 month or something. You have to watch the blockchain at least once during that period. You have to check the phone or blockchain at least once a week or something. That channel duration matters for the timeout of the checksequenceverify matters for channel monitoring which must still be done by the user.
The monitoring itself could be done by a third-party. The third-partry could inform the user, they could email you and say you should sign it, if you ever see these 20 bytes on the blockchain please send me an email. They could email you and tell you to sign to get your money back, the user still has to sign, of course. The user still has to do something.
The generalized channel awesomeness of the second type, is medium. It helps a lot. It's good.
Lightning level 3, which includes SIGHASH_NOINPUT and segregated witness... This can reduce the channel size by half. It reduces it a lot. Channel duration is still indefinite, if you have OP_CSV. The channel monitoring can be done sort of anonymously untrustedly outsourced. If you see 20 bytes on the blockchain, please broadcast this transaction. The general transactional awesomeness of this channel type is high.
The way to do this is to have a reliable spend of an unconfirmed transaction. It deals with malleability in that, I can know, here is the txid of a transaction. It's a transaction spending from... the txid could be changed, so you can't sign. You have to watch for what the txid is. So there's two ways to fix this. Segregated witness is one of them. Segregated witness is pretty cool. It's also kind of weird, but in a good way. We might want some more time to test it out and figure out how to do it, it's a pretty big rethinking of how things work. I think that it's cool and we'll use it if it gets in. There's a simpler way, which is called SIGHASH_NOINPUT. It does not fix malleability, because txid can still be changed, but the signatures can be applicable to multiple txid values. The txid is not included in the signature. If the txid changes, it's okay. What I'm including in the signature are my outputs and my input scripts, so it's still referencing the correct, also I'm referencing, signing with the pubkey, so as long as I don't reuse pubkeys, it's really safe. There's some risks to this. If you did it the wrong way, you could for example send 2 bitcoins to a pubkeyhash, send 3 bitcoins to that same pubkeyhash, and then try to spend the two, and sign, and you're trying to send the original 2 BTC, well, a miner would redirect that signature to the 3 BTC output, and cause you to spend 3 and take that extra 1. So this is somewhat dangerous in that you don't want to reuse addresses with this sighash type. You could do this with a soft-fork, and do it with multisig only so that it's much less likely that someone would replay the signature. It would require, in 2-of-2 multisig, for both people to reuse the same pubkey, and they both would have to be doing something stupid, which is much less likely. If you were going to do a soft-fork, you could do remove the 0 bug in multisig. There was a pathological transaction a few months ago where the whole block was a single transaction with thousands of inputs, and you were hashing an enormous amount of data per signature. This helps a little. Segregated witness would also allow this lightning level 3 channel, however.
I would now want to figure out how many people can use this stuff, given 3 different levels based on different BIP availability. We could have 1 megabyte, which is like inertia with now. What about with BIP 2-4-8 and meet in 10 years? What was discussed yesterday, bip100. This would be where miners vote and decide, but still a 32 MB cap that they would be deciding within the range of. These seem like reasonable sizes to discuss. The 3 bips for lightning channels seem possible.
The assumptions I'm making are that half of the transactions in blocks are channel open and channel close transactions. Half of the LN closes and opens are merged, such that you close and immediately open another channel in the same transaction. This is quite possible if you have the cooperation of your counterparty, like Alice saying to Bob hey I am going to open a channel with Carol, please make this switch on the blockchain with me. Also, I am assuming there are no non-cooperative channel closes, hopefully only a fraction of the channels will end uncooperatively. It will happen, but hopefully extremely rare. Also, let's assume that channels tend to last about 6 months.
At level 1, e would need 150 channels/year, 150 close, 75 open. With level 2 and 3, you need 6 channels/year, 6 close 3 open. So this is basic results of the scalability matrix. (see slide).
When you only have OP_CLTV, it's about 1.25 MB per user per year. Level 2, it's kilobytes. You could have 5 million users with OP_CSV, and 42 million users with 5 KB level 2 per user per year. With fairly reasonable block sizes, oyu could get 100s of millions of users. Users are the right metric. How many transactions are they going to do? Well, as many as they want. Once you have the channel open, you can do 100s of transactions per hour, there is plenty of room. To some extent, these are pretty vague, but I would say if you do have 200 million people using the lightning network, it's probably the case that not half of the transactions are channel open and channel close transactions, it would probably be 80 to 90% of the blockchain transactions are LN related, in which case you could probably get to 800 million users.
LN can help out with scaling. Relative locktime helps out a lot. Going from level 1 to level 2 is huge. OP_CSV is really really helpful. You go from 1.25 megabytes to kilobytes. Segwit improves scalability significantly. Not the same amount of imrpovement from level 1 to level 2, for level 2 to level 3. But still useful. We can support a isgnificant fraction of all humans with reasonable block sizes.
Q: On the last slide, one of the assumptions was 3 channels per person. Assuming payment channels wouldn't be useful for retail sales, because you don't want to buy a coffee just to open immediately. Is that correct?
A: Joseph might expand on this. Let's say you buy a coffee. You're probably buying a coffee only once, right? Well, maybe the coffee is $5, and you put $50 into the channel and leave it open. Then someone else comes to the coffee shop and she does the same thing. But she has a channel with the grocery store. There's me, coffee shop, Alice, grocery store, they all have channels. When I go to the grocery store next time, I don't have to open a channel. Payments are routed.
Q: It sounded like everybody would have to open new channels.
A: I am guessing the mean is going to be 3, but it will probably be an exponential distribution. Most people will probably have 1 channel, and then some might have 100s of channels open
Q: You can make the sighash noinput slightly safer by also signing the input value.
A: Yes, that would be an option.
Q: Do they have to store lots of money in a hot wallet?
A: Yes. There's going to be people with lots of channel and lots of hops. If you look at graph theory and how this work,s it ends up working a lot better than expected. Even if you have 100 million nodes and each node only has 1 to 3 channels, you only need 6 or 7 hops is the most you ever need to do. If you are ever unable to route a payment through the channels in your subgraph, you can always open a new channel anyway.
Q: How hard is it to .. do automatically... ? Path discovery and routing.
A: That's another whole issue. It's cool, hard work, we're working on it. It's not really bitcoin-related. The bitcoin network doesn't see that stuff. It never ends up on the blockchain. It's not something we have to do for Bitcoin. The lightning clients can handle that. It's not too bad. There's a lot of research in doing that.
Q: What about including privacy?
A: Yes, there's privacy benefits, you could do onion routing for payments. That might be later-on stuff. Initially we want something perhaps less private, just to get something working.
Q: With those large numbers that this would be able to support, what would happen if a big hub goes uncooperative or malicious, and large number of users have to settle suddenly? How would this play out in the different levels you described?
A: The first line of defense is try to make sure there isn't a mega-hop or mega-hub of some kind with millions of channels. If that node goes down or goes rogue, you're going to have a backlog of millions of people trying to close out of their channel. If it exceeds the OP_CSV time, then bad things happen and people could lose money. So first, we need to make sure the network doesn't look like that. Some eople have talked about timestop where if blocks are super-congested, the checksequenceverify doesn't increment. If you have a huge backlog of people trying to close out of cahnnels, then we could have a statue of limitations freeze perhaps. Maybe an easier way is to make sure the topology doesn't look like that.
Thank you.
small correction about the scalability matrix: https://twitter.com/tdryja/status/673705980668993537
Other lightning presentation from same day: http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/network-topologies-and-their-scalability-implications-on-decentralized-off-chain-networks/
Some other resources:
http://lightning.network/lightning-network-summary.pdf
http://lightning.network/lightning-network-technical-summary.pdf
http://lightning.network/lightning-network-paper.pdf
other presentation https://www.youtube.com/watch?v=8zVzw912wPo and slides http://lightning.network/lightning-network.pdf
SF Bitcoin Social presentation slides http://lightning.network/lightning-network-presentation-sfbitcoinsocial-2015-05-26.pdf
slides re: time and bitcoin http://lightning.network/lightning-network-presentation-time-2015-07-06.pdf
https://github.com/ElementsProject/lightning
https://gnusha.org/url/https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
irc.freenode.net #lightning-dev