Talk:Scalability

Response to Dan Kaminskys presentation

Dans slides were presented at Blackhat 2011.

Response from Mike Hearn (original author)

Mike responded in this forum thread.

Response from Gregory Maxwell

When techies hear about how bitcoin works they frequently stop at the word "flooding" and say "Oh-my-god! that can't scale!". The purpose of this article is to take an extreme example, the peak transaction rate of Visa, and show that bitcoin could technically reach that kind of rate without any kind of questionable reasoning, changes in the core design, or non-existent overlays. As such, it's merely an extreme example— not a plan for how bitcoin will grow to address wider needs (as a decentralized system it is the bitcoin using public who will decide how bitcoin grows)— it's just an argument that shows that bitcoin's core design can scale much better than an intelligent person might guess at first.

Dan rightly criticizes the analysis presented here— pointing out that operating at this scale would significantly reduce the decentralized nature of bitcoin: If you have to have many terabytes of disk space to run a "full validating" node then fewer people will do it, and everyone who doesn't will have to trust the ones who do to be honest. Dan appears (from his slides) to have gone too far with that argument: he seems to suggest that this means bitcoins will be controlled by the kind of central banks that are common today. His analysis fails for two reasons (and the second is the fault of this page being a bit misleading):

First, even at the astronomic scale presented here the required capacity is well within the realm of (wealthy) private individuals, and certainly would be at some future time when that kind of capacity was required. A system which puts private individuals, or at least small groups of private parties, on equal footing with central banks could hardly be called a centralized one, though it would be less decentralized than the bitcoin we have today. The system could also not get to this kind of scale without bitcoin users agreeing collectively to increase the maximum block size, so it's not an outcome that can happen without the consent of bitcoin users.

Second, and most importantly, the assumed scaling described here deals with Bitcoin replacing visa. This is a poor comparison because bitcoin alone is not a perfect replacement for visa for reasons completely unrelated to scaling: Bitcoin does not offer instant transactions, credit, or various anti-fraud mechanisms (which some people want, even if not everyone does), for example. Bitcoin is a more complete replacement for checks, wire transfers, money orders, gold coins, CDs, savings accounts, etc. and if widely adopted probably replace the uses of credit cards which would be better served by these other things if they worked better online.

Bitcoin users sometimes gloss over this fact too quickly because people are too quick to call it a flaw but this is unfair. No one system is ideal for all usage and Bitcoin has a broader spectrum of qualities than most monetary instruments. If the bitcoin community isn't willing to point out some things would better be done by other systems then it becomes easy to make strawman arguments: If we admit that bitcoin could be used as a floor wax and desert topping, someone will always point out that it's not the best floorwax or best desert topping.

It's trivial to build payment processing and credit systems _on top_ of bitcoin, both classic ones (like Visa itself!) as well as decentralized ones like Ripple. These systems could handle higher transaction volumes with lower costs, and settle frequently to the bitcoin that backs them. These could use other techniques with different tradeoffs than bitcoin, but still be backed and denominated by bitcoin so still enjoy its lack of central control. We see the beginnings of this today with bitcoin exchange and wallet services allowing instant payments between members.

These services would gain the benefit of the stable inflation resistant bitcoin currency, users would gain the benefits of instant transactions, credit, and anti-fraud, bitcoin overall would enjoy improved scaling from offloaded transaction volume without compromising its decentralized nature. In a world where bitcoin was widely used payment processing systems would probably have lower prices because they would need to compete with raw-bitcoin transactions, they also could be afford lower price because frequent bitcoin settling (and zero trust bitcoin escrow transactions) would reduce their risk. This is doubly true because bitcoin could conceivably scale to replace them entirely, even if that wouldn't be the best idea due to the resulting reduction in decentralization.

Other discussion

There is one major point that the page overlooks: the limitation on block creation.

Block creation is limited to an average of one block every ten minutes. Furthermore, block size (which includes the transactions in the block) is limited to 1,000,000 bytes.

Each transaction requires 10 bytes, plus approximately 106 bytes for every input and approximately 69 bytes for every output. The exact size depends on the size of the public key, which I have not been able to confirm, but the keys in my wallet.dat seem to be about 65 bytes each.

If we assume that transactions average two inputs and two outputs, then the average transaction size will be about 350 bytes (note that the main page assumes an average of 1KB per transaction). If we further assume that the block size will, in practice, be limited to 500,000 bytes because the transaction fees increase as the block size increases, then that means there will be, on average, approximately 1430 transactions per block. That works out to an average of 2.5 transactions per second - well below the stated goal of at least 4,000 transactions per second.

Even if we assume only one input and one output per transaction, and that each block will contain the full 1,000,000 bytes, that still works out to only 5,405 transactions per block, or 9 transactions per second.

Unfortunately, this is not a limitation that can be overcome by simply increasing memory, or switching to a different ISP with more bandwidth. It is a built-in limitation, designed to deliberately slow down block creation. One solution is to somehow allow blocks to be freely created, while still keeping the rate of coin creation constant.

The bottom line is that, as it sits, this system is not scalable.

MAX_BLOCK_SIZE has always been planned to increase as needed. That limitation should be ignored. theymos 17:15, 4 March 2011 (GMT)

What Theymos said. Increasing MAX_BLOCK_SIZE will be done when "lightweight, header-only" client mode is done. Until then, block size has to be kept under control.--Gavin Andresen 00:19, 5 March 2011 (GMT)

I've updated the page with more discussion of this topic. --Mike March 5 2011

The thing with VISA or and credit card company is that there wouldn't be that many actual transactions. When I buy stuff with my credit card the vender doesn't get paid instantly. I pay my bill once a month and the vender gets all his transactions lumped into one payment from VISA (once a week, I think). Someone correct me if I'm wrong, but the number of real transfers of money would be much smaller. --Randomproof 17:29, 1 April 2011 (GMT)

Would also be nice to get some kind of an estimate on how much the crypto-operations could be accelerated with a GPU. Jojkaart 20:48, 13 June 2011 (GMT)

Shouldn't this (under Opimizations -> Network Structure): "Switching to DNS would give dramatically faster startup times that do not scale with the size of the network." read: "Switching to DNS would give dramatically faster startup times that do scale with the size of the network."? ie Remove the "not". --Tokoin 09:24, 21 July 2011 (GMT)