Debunking the myth that the 1 MB block-size limit was an original, permanent, sacred design constraint.
The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices. Source
To think about what a really huge transaction load would look like, I look at the existing credit card network. I found some more estimates about how many transactions are online purchases. It's about 15 million tx per day for the entire e-commerce load of the Internet worldwide. At 1KB per transaction, that would be 15GB of bandwidth for each block generating node per day, or about two DVD movies worth. Seems do-able even with today's technology. Source
The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate. Source
A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year Source Source
There could be millions of SPV clients. They only matter in how many transactions they generate. Source
The fee the market would settle on should be minimal. Source
It can be phased in, like:
if (blocknumber > 115000) maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches that block number and goes into effect, the older versions that don't have it are already obsolete.
When we're near the cutoff block number, I can put an alert to old versions to make sure they know they have to upgrade. Source
If all transactions using Bitcoin were conducted inside a network of micropayment channels, to enable 7 billion people to make two channels per year with unlimited transactions inside the channel, it would require 133 MB blocks (presuming 500 bytes per transaction and 52560 blocks per year). Current generation desktop computers will be able to run a full node with old blocks pruned out on 2TB of storage. Source
- BIP 103: Block size following technological growth Pieter Wuille
- "most devs think the blocksize limit will be increased eventually, but only after other scalability improvements are adopted." Peter Todd
- "Strongly agree. My suggestion 2MB now, then 4MB in 2 years and 8MB in 4years then re-asses. (Similar to BIP 102)" Adam Back
- "SegWit is great, but it will take too long to implement to have a major impact. Need to also raise block size limit IMHO. I am very positive about Greg's scaling proposal. I think it would be a lot stronger if there was a date commitment to 2-4-8" Andreas Antonopoulos
- "Satoshi did plan for Bitcoin to compete with PayPal/Visa in traffic volumes. The block size limit was a quick safety hack that was always meant to be removed." Source
- I primarily want to keep the limit fixed so we don't have a perverse incentive. Ensuring that everyone can audit the network properly is secondarily. If there was consensus to, say, raise the limit to 100MiB that's something I could be convinced of." Peter Todd
the block size (whether voluntarily or enforced) needs to result in a system that remains verifiable for many. What those many are will probably change gradually. Over time, more and more users will probably move to SPV nodes (or more centralized things like e-wallet sites), and that is fine. But if we give up the ability for non-megacorp entities to be able to verify the chain, we might as well be using those a central clearinghouse. There is of course wide spectrum between "I can download the entire chain on my phone" and "Only 5 bank companies in the world can run a fully verifying node", but I think it's important that we choose what point in between there is acceptable.
My suggestion would be a one-time increase to perhaps 10 MiB or 100 MiB blocks (to be debated), and after that an at-most slow exponential further growth. This would mean no for-eternity limited size, but also no way for miners to push up block sizes to the point where they are in sole control of the network. I realize that some people will consider this an arbitrary and unnecessary limit, but others will probably consider it dangerous already. In any case, it's a compromise and I believe one will be necessary. Pieter Wuille
I'm the guy who went over the blockchain stuff in Satoshi's first cut of the bitcoin code. Satoshi didn't have a 1MB limit in it. The limit was originally Hal Finney's idea. Both Satoshi and I objected that it wouldn't scale at 1MB. Hal was concerned about a potential DoS attack though, and after discussion, Satoshi agreed. The 1MB limit was there by the time Bitcoin launched. But all 3 of us agreed that 1MB had to be temporary because it would never scale. Ray Dillinger
Yes, the plan was to raise the size of the blocks. And yes, I think it should have been done. The 1MB limit was considered temporary. We got the current limit just to prevent people from filling space with dumb stuff but thought, of course they'll make it bigger when people actually need the space for legit transactions. But now they can't make it bigger, because that was a classic case of nerds making a design mistake by failing to note that we were leaving a decision in the hands of people with perverse incentives. Ray Dillinger -- Bitcoin is a disaster
- Tadge Dryja: Scaling L1 Bitcoin. Talk
- James O’Beirne: Modeling Bitcoin Blocksize Contraints. Talk
- Jameson Lopp: 'Goldiblocks,' A Dynamic Bitcoin Blocksize. Talk
- Arthur Gervais: On the Security and Performance of Proof of Work Blockchains. Paper
- Mark Friedenbach: 'Forward Blocks', On-chain/settlement capacity increases without the hard-fork. Paper
- Scaling Bitcoin with Giacomo Zucco, John Carvalho & Matt Corallo Interview
-
The temporary limit 1 MB limit was added after 1.5 years in mid 2010. Before that it was 32mb (the max network msg size) Source
-
SegWit was not a real 4x block size increase -- only theoretically. In practice, it merely increased the throughput from 6-7tps to about 11-12tps. Full blocks are about 1.6 MB on average.
The attacks were so large that they disconnected entire regions from the internet:
I was DDoS’d. It was a massive DDoS that took down my entire (rural) ISP. Everyone in five towns lost their internet service for several hours last summer because of these criminals. It definitely discouraged me from hosting nodes.
In other cases, entire data centers were disconnected from the internet until the single XT node inside them was stopped. About a third of the nodes were attacked and removed from the internet in this way.
Worse, the mining pool that had been offering BIP101 was also attacked and forced to stop. The message was clear: anyone who supported bigger blocks, or even allowed other people to vote for them, would be assaulted.