Insights

Scaling Bitcoin to Billions of Transactions Per Day

4 min read • Michael Carroll on Mar 9, 2015

It was great to have Joseph Poon and Thaddeus Dryja at PubNub to talk about scaling bitcoin. Those who know Bitcoin are well aware of the difficulties of using the blockchain for micro-payments. Here at PubNub, we’re especially interested in the success of the Bitcoin ecosystem because several Bitcoin applications, companies, and exchanges use PubNub to transmit time-sensitive information.

In the talk below from SF Bitcoin Devs, Poon and Dryja discuss:

  • How to make Bitcoin capable of handling the volume of all global electronic payments on a single blockchain without custodial risk of theft.
  • Using bitcoin full nodes which require no more than a residential broadband connection and a current-generation computer.

Bitcoin Doesn’t Scale

Transactions aren’t instant, and micro-payments don’t actually work due to the cost of completing the transactions.

So what does Bitcoin look like with one billion transactions per day? The numbers don’t work out. Bigger blocks lead to centralization, and an individual running at home won’t be able to keep up. How do we solve this?

In Bitcoin, any output can pay to any other

What we propose is having a payment channel between many parties which is conceptually similar to internet routing. This uses minimally-trusted intermediaries. With a malleability fix, we can do this.

What are Payment Channels?

Payment Channels are not a new idea — we may never know who came up with it. It allows two entities to send transactions to each other without hitting the blockchain every time. There’s a multisig address; Bob sends a refund to Alice, who can either sign it herself or sign it later, but she keeps it. Once she has the refund, she can commit to payments to Bob. In exchange for Bob’s 1BTC refund, Alice will send increasing micro-transactions to Bob, and Bob will eventually accept one and sign it.

You can change the direction of channels after they are created. For example, Bob can send a refund to Alice, and Alice can sign a transaction with an 29-day nLock time; when both parties sign, the payment channel is closed.

An Interesting (Failed) Model

What would be really cool is if Bob is a big company and Alice and Carol have existing payment channels open to Bob. Wouldn’t it be nice if Alice can send money to Carol through the existing payment channel without touching the blockchain, which is expensive? This is a micro-payment network! However, there are trust issues. What if Bob keeps the micro-payment? In essence, this doesn’t really work if we want to minimize trust.

How Can We Do This in a Trustless Way?

How Can We Do This in a Trustless Way

Using a one-way hash function, Alice can prove she sent funds to Carol off-chain. Knowledge of a secret, random data “R” which is hashed, proves receipt. If Alice has the data R which produces the hash, she can say “I have paid you the money” by the receiver writing some signed message (effectively a contract) which says “If Alice knows R, at that point Alice has paid me 0.1BTC.” Remember, we aren’t checking the blockchain, so we need a way to prove that funds have been sent.

In our example, Carol creates R and hashes it and sends it to Alice. Alice sends the 0.1BTC to Bob, along with the hash; but that 0.01BTC can only be forwarded to Carol if she gives Bob the data R; this payment is encumbered. (Carol can also post R to the blockchain.)

There’s a problem — if Carol refuses to disclose R, then she’ll hold up the contract. If her channel expires, she can steal money using the hashlock! Also, corruptible custodians like Bob are undesirable. Unfortunately with Bitcoin, complex chained transactions don’t really work. Two parties cannot spend from a multisig output without being able to fund the parent transaction

Malleability

We need to fix malleability. You need some kind of sighash modification, such as flags for SIGHASH_NORMALIZED and SIGHASH_NOINPUT (where you remove your input TXids completely.) NOINPUT is a lot more flexible in letting these contracts work. Hopefully we can get one of these into Bitcoin very soon.

In order to enforce Bob being able to send to Carol and knowing he can receive funds from Alice, you want to build a contract with terms: a hashed time-lock contract. If Bob can produce to alice input R from hash H within 3 days, Alice will pay Bob 0.01BTC. However, after 3 days the above clause is invalid. Either party may agree to settle terms using other methods if both agree, and violation of terms incurs a maximum penalty of funds in this contract. We can create this transaction in Bitcoin script itself using multiple transactions.

Bitcoin Lightning Network

Multiple parties can create a hashed, time-lock contract with decreasing encumbrance times. If R never gets disclosed, then the transaction has never happened. If one party declines to communicate after starting the transaction, R can be broadcast to the blockchain and the transactions happen even without the intermediary parties need to do anything.

What are the implications of off-chain transactions?

Nearly all transactions will appear off chain, and there are nearly zero risks. There are ways to mitigate them (see the paper) but effectively if everyone broadcasts everything on time, there’s no situation where one party has paid another but can’t get paid back. Using a setup like this, creating channels would be very infrequent. Of course, channels eventually expire; you have a tradeoff between channel expiry and time risk. You can mitigate that using another soft fork: OP_CHECKLOCKTIMEVERIFY.

Bitcoin CAN Scale

7 billion people making 2 blockchain transactions per day: 240 GB blocks, means 500Mbit/s best case! But, 7 billion people roll-over two channels per year works out to ~3Mbit/s with IBLT.

0