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 existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling. If you're interested, I can go over the ways it would cope with extreme size.
By Moore's Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions. 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
100,000 block generating nodes is a good ballpark large-scale size to think about. Propagating a transaction across the whole network twice would consume a total of US$ 0.02 of bandwidth at today's prices. In practice, many would be burning off excess allocated bandwidth or unlimited plans with one of the cheaper backbones. There could be millions of SPV clients. 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
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. Source
In a few decades when the reward gets too small, the transaction fee will become the main compensation for nodes. I'm sure that in 20 years there will either be very large transaction volume or no volume. Source
We can phase in a change later if we get closer to needing it. Source
I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it's not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions. Source
The eventual solution will be to not care how big it gets. But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore. Source
As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy. Source
While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial. 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 am - in general - in favor of increasing the size blocks: as technology grows, there is no reason why the systems built on them can't scale proportionally. 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
- 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.
A common objection to larger blocks is that slower propagation and validation increase stale-block rates, reducing the share of honest hash power securing the main chain. This is true all else equal, but it is only a partial analysis because it assumes miner revenue, transaction demand, the Bitcoin price, and hash rate remain constant. If greater on-chain capacity increases adoption and total fee revenue enough for miner revenue to grow faster than the losses caused by stale blocks, overall chain security may increase. The net effect also depends on propagation asymmetries, mining concentration, and the cost of independent validation.