Scaling Bitcoin To Billions of Transactions Per Day
We’re doing a presentation on the lightning network and micropayments. Right now bitcoin faces some interesting problems, like transactions aren’t instant, and micropayments don’t work. The transaction fees are 1/10th of a cent or higher depending on the exchange rate. And, “bitcoin doesn’t scale” especially if you have a lot of micropayments. One megabyte blocks? Well, let’s increase them. What happens? Well, you go from seven transactons per 2nd with one megabyte with about two hundred twenty million transactions per year. With a seven billion population on the planet, that’s less than one transaction per year or substantially less.
What does bitcoin look like with more than one billion transactions per day? Well that’s 1.8 GB (1655 MB) and about eighty seven terabytes/year. You can store enough transactions from a year for a place maybe the size of San Francisco or another metro area. Well you might say okay, let’s up it even more. Then what happens? Well you get some centralization, right.
Mining sort of doesn’t work for this. You’re going to end up with one or two mining pools. They sort of have an incentive to create thicker blocks and it causes more centralization. An individual running a bitcoin knot at home can’t do a total validation of all transactions. It’s not indeed bitcoin. It doesn’t work very well.
How do we solve this? Dump everything into a SQL database. Coinbase does this. But it’s very useful. Sometimes there’s a need for that. You can put everything into sidechains, and you could also use payment channels which is a one-to-one connection to another party. It’s like the Starbucks bounty card model where you always have a single relationship with another entity.
These do face some problems. The SQL model is basically like MtGox redeemable codes. When you add custodial risk, that creates problems. Sidechains are interesting, but they aren’t indeed a scalability solution. Sidechains are more tricky. It works well for something like namecoin where you want it to use bitcoin instead of its own currency. It’s a promising technology. Sending funds inbetween chains may exacerbate the problem if you want to send funds inbetween them because it’s two transactions instead of one transaction now. If you have money on chain A and someone wants to receive money on chain B, you have to bridge them and this might require two transactions instead of one transaction. Payment channels are problematic because what if you want to send money to someone else?
What you truly want is anyone-to-anyone payments. When a transaction hits the blockchain, anyone can send to anyone else because you can set the output. In the SQL database model where you give them all your money and they update database entries, you sort of need to give that one person your money. If someone wished to receive money on Coinbase.com, you could send them a bitcoin transaction but that’s not scalable, so you have to put your money on Coinbase very first and then send money in the Coinbase network. That’s a lot of centralization.
For sidechains, you have to be on the same sidechain or else you have the doubling of transactions as described earlier.
Inwards a payment channel, you just need the same relationship. So what we propose is a payment channel inbetween many parties in a multi-hop hub and spoke model, like internet routing. This uses minimally trusted intermedaries. They can’t take your coins. It does not involve a third-party custodian. This does require a puny malleability soft-fork. We kind of need to fix malleability anyway. If we fix malleability, we can do this.
Tadge is going to introduce payment channels and then build off of that.
We were looking around to see who came up with payment channels. There’s some stuff in 2012. I don’t know who came up with the idea and we may never know. Anyway, it’s an old idea, well old for bitcoin.
Payment channels require multisig. It permits two entities to send transactions to each other rapidly without hitting the blockchain each time. I am going to go through the basics of setting up a two-party unidirectional payment channel. Alice can only send money to Bob through this. So what she does is she gets a refund transaction. There’s a multisig address that Alice and Bob both have control over. Alice wants to send one BTC to it. Before she does so, she gets Bob’s refund signature. So at worst, Alice loses access to her funds for thirty days. Bob creates this timelock refund transaction. Alice can either sign it herself, or it can wait half-signed. Alice keeps this on her hard drive because she knows that at the end of the month she can get her money back. Once she has this, she knows it’s safe and she sends bitcoin to the multisig address because she knows worst case she can get it back. Once it’s in the multisig address, she can commit to payments to Bob. Alice can sign this and then forearm the transaction to Bob. She can give 0.9 BTC to Alice and 0.1 BTC to Bob. She will sign this transaction. It’s not valid because Bob has not signed it yet. Alice cannot thrust this to the blockchain because miners would overlook it. She can give this to Bob out-of-band. Bob can treat this as a payment. Bob can sign this at any time, and then broadcast it to the network, and in doing so close out the channel. Instead however, Bob will wait. He knows that the channel is going to be open for the rest of the month. The next time that Alice pays, she gives 0.8 BTC to herself and 0.Two BTC to Bob. He sees that this is better for himself, so he will broadcast this transaction instead of the earlier one. At some point, Alice might request the channel to be closed out and Bob could cooperate, or if Bob is a masturbate he could wait until the end of the month to sign a transaction. If Bob waits too long, Alice gets all of her money back. So Bob is motivated to sign this at some point before the end of the month (the locktime expiry). The network only sees the multisig transaction with two outputs. So during that month period, she can send as many petite microtransactions to Bob as she wants.
You can switch the direction of channels after you create it. Setup the refund transaction, fund the multisig address. When Alice spends to Bob, she adds a locktime (nlocktime). So now Bob wants to pay Alice back for whatever reason, Bob says I am going to pay Alice now from the money that you were paying me. He can provably commit to a payment to Alice by overriding this transaction. He sets a lower locktime on the transaction. So this is a race inbetween when people make a transaction published to the blockchain. You can’t do this a million times. You only have so many times you can use a shorter locktime. Switching the direction requires bringing the expiry closer to the present. They can both sign a fresh thing with no locktime if they cooperate.
Okay, so then I will transition shortly to 3-party payments. I will demonstrate the motivation and Joseph will talk about how it works. Let’s say that Bob is a big company or they are some kind of payment processor like Bitpay or something that people use a lot. Alice has a channel open. Carol has a channel open. Everyone has a connection to Bob, and Alice wants to send to Carol, and this is the future where sending a bitcoin transaction is expensive. It would be nice to send to Bob who can then send it to Carol instead of using an expensive bitcoin transaction. So Alice can send to Bob and hten Bob can send to Carol. This is a micropayment network.
But there’s some trust issues here. Bob might just take the bitcoin that Alice sent. And Carol could claim that she never got the coins, and there’s no real way to verify whether Bob took the money. So this doesn’t truly work. It might work if you trust Bob but we’re attempting to minimize trust. So Joseph is going to talk about how to actually do this.
Yeah that model works pretty well. You can use 2-of-3 multisig to help mitigate the problems. It would be nice to do this in a trustless way.
You can create a hashlock contract. A hash function is a undirectional cryptographic method whereby you take some input and you get some output that cannot be reversed. What you do is you take some random data R and you convert it through hash160 or whatever and you use that as a key and you need the lock which is the random data R in order to unlock the funds encumbered. And there’s a paper from two thousand thirteen called pay-to-contract and essentially if Alice has the data R which produces H, she can say I have paid you the money. She does that by the receiver writing some signed message effectively a contract that says if Alice knows R which produces H then at that point Alice has paid me 0.1 BTC and that works. And you might ask yourself, why not just check on the blockchain? You can’t. Because everything we’re discussing here is off-blockchain. So you need some way to prove that funds have been sent.
So essentially this right here is what Carol produces. She has some random data R. And she runs it through some hash function (like hash160) to produce H. She gives H to Alice. Now Alice knows H but doesn’t know R. And Carol knows both. Alice uses a payment channel payment to Bob but this is encumbered and can only be released if Bob can produce R. Let’s assume this work; if it doesn’t work then bitcoin has some problems. Bob does the same with Carol. What happens is that Carol has a payment from Bob that is encumbered. Carol can only use these funds if she gives R to Bob or broadcasts it to the blockchain. Carol might tell Bob R because she wants her money. Bob and Carol can broadcast the channel on to the blockchain, or they could agree to novate “I know you know R, I know you can put the funds on the blockchain, let’s not do that because it’s expensive, let’s do it in the channel”. If Bob is uncooperative then Carol can broadcast it on the blockchain. But assume Bob is nice. Now that he knows R, he can get the one bitcent from Alice. So Bob was acting as an intermediary, and it wasn’t a substantial risk. He can always pull funds from Alice and give them to Carol.
But the problem is that if Carol turns down to disclose R she could hold up funds in the channel. If Alice’s connection to Bob expires before Bob and Carol’s then Bob has already paid Carol. Alice and Bob’s channel has already hit the blockchain. Bob could be out of the money. That’s a problem. Also, Bob has to be sort of wealthy. So say Alice has one BTC, the channel has one BTC, Bob has zero BTC. Alice can’t receive any more funds because she’s sort of utter. If everyone gives money to Bob, you kind of want Bob to send money out, to create channels outside; if Bob sends money to Alice then that has a channel that can be spent so the system sort of works. The availability of funds that Bob has, has some implications for fees. Bob just needs to be indeed rich on a single hub-and-spoke model.
Say that Bob is rich. How do you mitigate the problem? You can do third-party multisig where the Alice and Bob payout is using a third-party escrow service. That could work fairly well today. You could also trust that Bob would be fair and send the money and not encumber everything. But what we truly need is a trustless model. Corruptible custodians are undesirable. You want to make sure Bob is incapable to steal funds. Complicated chained transactions in bitcoin don’t truly work because with malleability you can create hostage scripts where if funds are locked in 2-of-2 multisig then the refund transactions are not spendable because the other transactions were mutated. So this creates a hostage script and one attack here involves the time value of money where one party might be able to tolerate a longer locktime in order to intimidate the other party.
To fix malleability, you basically need to introduce some sort of fresh sighash flags in a soft-fork, such as SIGHASH_NORMALIZED and or SIGHASH_NOINPUT. This would permit you to build a transaction without either party able to broadcast the parent on the blockchain. You could edit the sighash flags or you could use a fresh opcode. You can undress out the signatures with SIGHASH_NORMALIZED, or you can eliminate the txids totally. It’s slightly more risky if you’re spending to the same address numerous times but you shouldn’t be doing that anyway. NOINPUT is much more pliable with what it can do. NORMALIZED also lets a lot of these contracts work. Hopefully we can get both of these sighash flag types. I don’t think there’s a ton of controversy because we already have SIGHASH_NONE, so why not these? They are much safer anyway.
So in order to enforce Bob being able to send to Carol and Bob knowing that he can receive funds from Alice, you want to build this contract. What would be the terms of this contract? For example, if Bob can produce to Alice some input R where R is some random data that Bob generates, with input R from hash H within three days, then Alice will pay Bob 0.1 BTC. However, after three days the above clause is invalid meaning that within these three days if you can produce this hash then you will get 0.1 BTC but after three days the funds locked inwards this output will be refunded and either party might agree to lodge the terms using other methods, like instead of broadcasting on the blockchain perhaps they would lodge on the channel. And violating the terms would incur a maximum penalty, so if Bob does something sneaky you can fix that.
So you create a transaction in bitcoin transactions using transaction outputs. So there would be a 0.1 BTC output inbetween Alice and Bob. And the payment, is a payment with no locktime but requires R. So if this output is committed inbetween Alice and Bob, and Bob produces R, then he can broadcast on the blockchain the transaction that spends from this output and Bob would have to broadcast both the output and the spend. However, after three days, Alice has an unencumbered transaction which does not require R, which is a refund of what Alice committed (the 0.1 BTC). So what happens is that Alice funds the 0.1 BTC, Bob doesn’t broadcast anything, if Bob produces something in three days he can get 0.1 BTC. And this is sort of what the script looks like for the output:
OP_DEPTH three OP_EQUAL OP_IF OP_HASH160 <R> OP_EQUALVERIFY OP_0 two <AlicePubkey1> <BobPubkey1> two OP_CHECKMULTISIG OP_ELSE OP_0 two <AlicePubkey2> <BobPubkey2> two OP_CHECKMULTISIG OP_END
The very first one has three items the 2nd one has two items.
So what happens is that when three days occurs and Bob doesn’t produce anything, Alice has the option of going to Bob and telling him that he didn’t produce anything. So she might propose updating the channel to eliminate that output entirely. If Bob doesn’t agree, Alice broadcasts the output and the refund on to the blockchain.
So what can you do? Let’s say that Alice wants to send funds to Dave through Bob and Carol. And perhaps Alice detects Bob through cjdns or whatever. She knows that there’s some network that Bob and Carol is in. So maybe there’s 100s of Bobs and Carols. There’s a fair amount. Maybe more than today with card processors, but you know. There’s some route. And the blue lines are the individual channels inbetween the participants. This will commence looking like what it did before, Dave generates an R, gives an H to Alice, Alice creates a HTLC (hash timelocked contract) inbetween her and Bob. It’s a hashed timelock contract with a 3-day locktime so that the funds are locked up for three days and if Bob can produce R in those three days then he can pull one bitcent from Alice but if he can’t, Alice gets her money back. Bob does the same with Carol, except it’s two days. And Carol does the same with Dave but it’s one day. Dave pulls the money because he knows R. Dave could broadcast it on the blockchain, and Carol could broadcast it on the blockchain, but in this case they agreed to liquidate the contract through the blockchain and they sent the funds atomically. Bob does the same with Carol, and Bob does the same with Alice. At no point has a transaction hit the blockchain.
What happens if Bob determines to not cooperate with Carol on day two? Instead of doing this, Bob just says I’m not going to talk to you Carol and just overlooks them. Carol knowing R broadcasts the entire transaction chain on to the bitcoin blockchain. So what happens is that the blockchain now knows R because Alice has redeemed the funds. And at this point Bob has sent money to Carol on the blockchain (unwillingly) because Carol can unilaterally take the money. Bob doesn’t deserve that money, he looks on the blockchain and sees R, but if Bob’s not paying attention, then Alice after three days can say I want my money back and Alice gets it for free. Alice knowing R has technically paid Dave. Which is why you want to agree in general and be cooperative.
What does a timeout look like? Let’s say that Dave is going to sit on it and never broadcast R. Dave and Carol’s channel’s output closes very first. And Carol is blessed with this setup because she knows that her payment closes out, and the skill that she will close it out, before her money gets pulled. So the nice thing about this is that if Dave discloses R after the fact, Carol’s already closed out her channel, she doesn’t care, whether inwards the channel or on the blockchain. And right now like, it closes out, it closes out, and it’s okay. It’s as if the transaction had never happened, after three days.
What are the implications of this? You can view bitcoin transactions as circuits instead of packets. Only uncooperative channels get broadcasted on the blockchain, other than expiry of course. But that means that you truly have to look at bitcoin a little differently. If most of the transactions are happening off-chain then bitcoin’s view as a circuit there’s a lot of switches. I don’t want to go into a long rant about that right now. Almost all transactions do occur off-chain securely and there’s almost zero risk. The risks are largely about not broadcasting in time. There’s ways to mitigate this. If everyone broadcasts everything on-time, then there’s no situation where Carol has already paid Dave but can’t pull funds from Bob. That doesn’t happen. It’s pretty much near zero trust. It’s trustless. It’s different from providing custody of your funds to a third-party. Creating channels will become infrequent if you use something like this.
So a question would be, well these channels are operating inbetween Alice and Bob and it will eventually expire, right? And then you create a fresh channel. Well that’s a lot of blockchain spam. You would have a tradeoff inbetween channel expiry and time risk and time value of money. You could mitigate this with another soft-fork, for OP_RELATIVECHECKLOCKTIMEVERIFY where the transaction’s outputs have a relative timelock dependent on when it comes in the blockchain instead of some hard blockheight. If you want more information, check out the paper. I don’t know if this will go into bitcoin, but it would be nice because you could have channels that span for years. You could leave it open for years. You could also say it closes next week, but you could roll-over to another time period or something without a transaction on the blockchain. Within those two weeks that you choose, you have a time to get a refund if you find it necessary.
Instant transactions work now. You can have funds committed within one 2nd, there’s no backsies, there’s no dual spending, etc. Micropayments become indeed scalable. You could send the equivalent of a tenth of a cent. You could pay for things by the megabyte. You could pay for every single website that you visit. You could pay a tenth of a cent. Totally feasible. Nothing hits the blockchain, why not?
Bitcoin could indeed scale with this. If you presume that channels wont be used and everyone uses bitcoin like we do today. If everyone in the world are making two bitcoin blockchain transactions per day, you’re looking at something like at best twenty four gigabyte blocks. The bandwidth at best would be something like fifty megabits per knot connection, at best. If you have channels instead and have this channel network and you presume that everyone has two channels for themselves, except for the core knots and anyone could be a core knot, then those people can make a lot of transactions, they can make almost infinite transactions inwards of one hundred thirty three megabyte blocks. I think two channels per year, especially if you have a relative checklocktimeverify is generous; most people only have one or two bank accounts. It’s not a bank account because you don’t have custodial risk. You’re looking at something like three megabits per 2nd per knot connection, which is truly reasonable. Well, twenty four GB isn’t that bad. What happens if everyone is making twenty blockchain transactions per day? Well then you’re looking at two hundred forty GB every ten minutes. That’s not practical. I think especially if people begin using micropayments a lot more, I think it’s very feasible for people to make twenty transactions per day. I think most people in the west very likely do five to ten per day. Twenty is not that big of a hop. So you kind of want to solve that. Using that payment network, it’s the same- if people do more transactions, unless someone gets truly rich or truly poor and they need to make a fresh channel, it’s the same.
So what are the storage costs under this model? You’re looking at something like seven TB/year for almost unlimited transactions, which is about $300/year in blockchain archival storage. That’s only if you want to keep a utter record of every single bitcoin blockchain transaction ever, for those seven billion people. So if you want to front that $300/year, it’s not that expensive; it’s much more feasible than two hundred forty GB blocks. And for most people, I think those of us developers miners etc are most likely going to use the pruning patch where you keep the most latest two weeks, maybe twenty weeks, and the utter utxo set and you’re looking at something like two TB which is common in current generation desktops. Two to four TB is pretty common. And will only run you maybe $100-$150 and you’re good forever. For those of us with cellphones, you’re looking at several megabytes of storage. The SPV story is slightly lighter; both clients create the channel, so they are only looking for txids so they could be an even more lightweight client. They only have to keep track of older blockheaders and older outputs.
A: Yes. That’s a two-part questions. Are you using multisig and hash-encumbered? This is the hash-encumbered part of this output. It has a multisig signature inbetween Alice and Bob so it’s presumed that this output is pre-signed by both parties except for knowing R. So they know the output. And the 2nd question was the relative checklocktime? That’s not an opcode that exists. That’s an opcode that we would like. Instead of just checklocktimeverify which just keeps going or fails, relative checklocktimeverify will come back a depth in the blockchain. It would be something like come back the depth of my input, if it’s less than something then fail the entire thing, otherwise include the number. This way it’s not dangerous for reorgs. You have a window of time for which it’s valid. It would need to be a script opcode.
Q: The question is usability.
A: The end user doesn’t need to know any of this. You’re not truly sending to bitcoin addresses. You sort of need a direct connection. You use the internet. You need some kind of giant talk network or something so that everyone can talk to each other. But that already exists. In terms of the usability, it wont look too different from bitcoin wallets today, especially if you use a payment protocol where you’re sending to some domain name or URI, coinbase.com/username or something, so you would type that in and hit send. You could also do something more elaborate by using pubkeys instead, but irrespective of that, you need some sort of connection.
A: Bob can charge a puny fee, it doesn’t matter, maybe one or two satoshis. Alice can have numerous connections to numerous Bobs and she can find the rate that meets her needs the best. Bob’s fee can be positive or negative. Perhaps he has a lot of build-up in one direction, so perhaps someone else sends a indeed large transaction in the other direction, and now it’s free for another spend, so he might want to give a negative fee to Alice. Bob knows the graph. The blockchain becomes very opaque, you only see two transactions per year per user, and they’re actually doing thousands and you just never see it. And Bob gets some visibility into some subset of transactions, perhaps he’s selling that to marketers or something. Right now every transaction is open, and in this model Bob gets to see more of the transactions than the other guys, so maybe Bob wants to do it for free because he gets that metadata.
A: As long as one of Bob and Carol agrees to rip up their records, nobody has to know what happened.
A: If everyone reports everything, there’s not much you can do. There might be ways to mitigate this.
A: You need the sighash soft-fork. It seems like the best way to fix malleability. From all the people I talk with, nobody disagrees. Most people that we’ve tlaked with think it should be made default. Bitcoin multisig is fundamentally cracked; you can’t use a lot of that stuff today because you need to fund something before writing the contract. It’s sort of weird right now. Without any trusted third party, you both need to fund a transaction before you can create an output spent from it. So you can’t do chained numerous transactions. You need something like a 3-deep chain, and to do that you need to fix malleability.
Q: Changetip CEO has mentioned that before everything was on chain, and now everything has custodial model simply because of scalability and practicality, that micropayments are not feasible? So what are the next steps?
A: There’s a lot of stuff to do, and it’s going to have to come together. Even if you desired to implement this today, you need a soft-fork. You could build a single Bob model using trust. That works today. You could commence today, and have these workarounds and then hope that there’s a malleability fix later to truly scale out. That’s most likely okay. Right now you need this for micropayments, but that’s not a critical need. We could still scale up bitcoin by fairly a bit before we commence truly needing to shove things off-chain. We’re working on this. The developers need to be okay with the soft-fork. The miners need to be okay with it. I think everyone’s sort of okay with it already.
A: Yes, you can have micropayment channels from all your users. Bob also doesn’t need to receive money, he needs to have some money going out. That output gtoday can be mutated using some minor switches in bitcoin core v0.Ten, but Bob’s outputs to Alice, let’s say that Bob encumbers his one BTC to Alice, that part can be mutated and it could create a hostage screenplay. But maybe in a duo months it will solve itself.
Q: Why can’t Alice’s payments to Carol be very puny?
A: Well, you don’t want to trust Bob to a lot of money in transit. So perhaps you only send Bob ten satoshis and Bob would send Carol ten satoshis. You could send ten at a time, since it’s not hitting the blockchain. It’s bandwidth overhead and latency. it would be nice if you had no risk so you could send arbitrary amounts, of course.
A: Bob needs a lot of money even with little bits going through. Say that Alice puts a BTC into the channel and Carol does the same. Alice wants to pay Carol, she can’t, because it’s Carol’s money in the channel with the Carol-Bob channel, so Bob can’t credibly shove that back to Carol. So nobody would be able to pay each other; they can only pay Bob. So Carol would have to put one BTC into the channel and then Bob would put one BTC into the channel as well so that there could be bi-directional transactions. The advantage of multi-hop is that Bob doesn’t need to be rich. As long as it averages out, they don’t have to be rich.
Q: How many hops?
A: I think two intermedaries. I think three hops. I think that takes over the world. How many intermedaries do you need? I think there will be a fully connected graph inbetween all the Bobs and Carols. Even with a thousand, that’s like a million different channels. But I think it is going to be more disconnected, like three in the middle. I think Bob and Carol do have money committed online and this is all hot wallets for Bob and Carol and so there’s maybe one entity that doesn’t want to expose itself too much. These are similar to existing financial security issues, like a bunch of valuable stuff and you don’t want to get hacked. Those are going to be the real questions for Alice and Bob. The other users could be offline and they could be using multisig. It thrusts a lot of risk into the center, because they’re making fees off of it. With commodity money, your risk paid in the form of fees is effectively what the main concentrate is. But fiat is mostly debt, so the interest rate is mostly paid based on your counteparty risk. But with gold you’re taking on the security risks, so the fees are related to the security risk. The people that are more secure would most likely charge lower fees.
Q: How much capital will Bob and Carol have to have, and how does this equate to the throughput?
A: I think it will solve itself. Just charge zero. Right now the time-value of bitcoin is sort of zero. Someone who has 20,000 BTC will just sit on it at the moment. Well, you could put those 20,000 BTC up here. This is a bitcoin lease rate with zero counterparty risk. It’s kind of good.
A: On blockchain is so much lighter is that you very first pack up the blocks, then you budge to lightning network when the fees become prohibitive. I don’t think it’s a big risk. There’s interesting ways to increase the block size, if miners truly get mad, they could prevent some of this stuff from happening. Miners are going to get fees no matter what, I think they will eventually restrict the block size in a way to get more fees, but I think the blockchain transaction fees are going to go up substantially. If you are dumping data on the blockchain because you think bitcoin transactions are going to stay cheap, well I think the transactions are going to go up to $Five per transaction or $Ten per transaction.