Response to Dan Kaminskys presentation
Dans slides were presented at Blackhat 2011.
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.
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)
I think Moore's law should be mentioned.
Even though now the comparison to Visa produces requirements for processing power, data storage or network capacity appear overwhelming for a casual user, the cost/performance ratio decreases all the time. My calculations based on data from wikipedia projected for 2020:
Wikipedia quotes a research article that estimates that "in 2020 a two-platter, 2.5-inch disk drive will be capable of storing more than 14 terabytes(TB) and will cost about $40". This can hold about 85 days of data (~3 months) at "visa-speed". This is a bit pricey, but within the scope of a normal user, and definitely enough for enthusiasts.
Wikipedia references articles that estimate the "moore's law" equivalent for network to be 50% increase / year. For 9 years (2011-2020), this makes an increase of approximately 38 times. In order to achieve the speed of 1GB/s, this is the equivalent of someone having 27MB/s at the moment, i.e. 215Mbit/s. I think this exceeds a normal user and most enthusiasts. Assuming a casual user has 2Mbit/s at the moment, he'll scale to "visa-speed" in about 16 years, i.e. 2027.
Moore's law is approximated as "doubling every 18 months". For 9 years this makes 34 times if I'm calculating right. 50/34 = 1.47 cores. A dual-core computer in 2020 should therefore be sufficient to handle relaying/verifying Bitcoin transactions at visa-speed. I'm ignoring mining. So why someone is proposing that double tx check should be removed from the protocol ? We would surely leave the door open to some nasty attacks if strange transactions or double spends slip into blocks from attacking miners.
I only made very rough estimates. Feel free to recalculate with more accurate data. My conclusion is that CPU would be a no-brainer, disk space would be an annoyance, however network speed would indeed appear to be a problem.
I believe the implications of SatoshiDice and similar schemes that stress the network should be mentioned, since as of March 2013, SatoshiDice transactions occupy 80% of the block chain. --Alvox (talk) 23:09, 29 March 2013 (GMT)
- So mention them? Note that SatoshiDice just abuses the network, not so much merely stressing it.. but clarifications can always be edited in after we have something to start from. --Luke-jr (talk) 23:28, 29 March 2013 (GMT)
- Is SatoshiDice relevant to scalability? If there is a solution to SatoshiDice spam then we probably should mention it, but I don't know of any solutions that can't be worked around by them --Lapp0 (talk) 17:50, 20 December 2014 (UTC)
passively running a full node and other scalability options
This page makes no distinction between passively running a full node and actively using 90% of your CPU power, 90% of your bandwidth and a ton of disk space. Clearly if it takes significant effort to run a full node, arguably unlike right now, then the number of full nodes will drop significantly.
I propose collapsing this whole article into one section titled "Increasing the Block size (Hardfork)" and include the problems with hardforking along with the problems of expensive full nodes.
Along with this section there should be other sections on other scalability improvements and their problems including sidechains, opentransactions, and others. --Lapp0 (talk) 17:47, 20 December 2014 (UTC)