Bitcoin Wiki - User contributions [en]

Block size limit controversy

2015-06-08T04:41:16Z

Gappleto97: Recorrected F2Pool's position based on missed criteria (Sorry for the confusion)

== Introduction ==

Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.

Blocksize limits were put in place for the dual purposes of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.

{{Quote|Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.|Satoshi Nakamoto <ref>https://bitcoin.org/bitcoin.pdf</ref>}}

The fixed blocksize limit cannot be modified without a hard fork.

Hard forks require adoption by virtually all of the bitcoin participants.

== Arguments in favor of increasing the blocksize ==
* Bigger blocks (more transactions per second)
* Sidechains and Lightning do not exist.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* An emergency hard fork can achieve consensus for deployment on a short time period if needed, should blocks become full before Bitcoin has scalability improvements.
* Risk of catastrophic consensus failure{{clarification needed}}
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentalization ===
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.
* Larger blocks leads to more expensive full nodes.
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.

== Entities positions ==
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner[http://sourceforge.net/p/bitcoin/mailman/message/34093337/]
|
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}[http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp]
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}[http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd]
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}[https://twitter.com/bithours/status/605131647747358721]
|
|-
| [[BitPay]]
| {{Yes}} "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair[https://twitter.com/spair/status/595341090317799424]
|
|-
| Bitrated
| {{No}} "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)[https://twitter.com/shesek/status/605005384026177537]
|
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}[https://twitter.com/Bittirahafi/status/596682373028311040] "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade[https://twitter.com/Technom4ge/status/596334370803326978]
| {{Yes}} "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade[https://twitter.com/Technom4ge/status/596334370803326978]
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith[https://twitter.com/OneMorePeter/status/595676380320407553] "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary[https://twitter.com/niccary/status/595707211994763264]
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine[http://sourceforge.net/p/bitcoin/mailman/message/34096857/]
|
|-
| [[BTC Guild]]
| {{Yes}} "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria[https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3]
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}[https://twitter.com/BitcoinThai/status/605022509101023232]
|
|-
| [[Coinbase (business)|CoinBase]]
|{{Yes|Yes: "Coinbase supports increasing the maximum block size"}}[https://twitter.com/coinbase/status/595741967759335426] "Why we should increase the block size" - CEO Brian Armstrong[https://twitter.com/brian_armstrong/status/595453245884997634]
|
|-
| Ethereum 
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)[http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6]
|
|-
| [[F2Pool]]
| {{No|No: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}[http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/]
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}[http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84]
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen[https://twitter.com/koodilehto/status/596675967667568641]
|
|-
| [[MPEx]]
| {{No}}{{citation needed}}
|
|-
| OKCoin
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}[https://twitter.com/okcoinbtc/status/598412795240009728]
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois[http://fr.anco.is/2015/gavineries/]
|
|-
| Third Key Solutions
| {{Yes}} "Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos[https://twitter.com/aantonop/status/595601619581964289]
|
|-
| Xapo
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares[https://twitter.com/wences/status/595768917907402752]
|
|}

Block size limit controversy

2015-06-08T03:57:51Z

Gappleto97: /* Entities positions */ Corrected opinion of F2Pool

== Introduction ==

Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit. Any block larger than 1MB is invalid.

Blocksize limits were put in place for the dual purposes of discouraging economically frivolous transactions from flooding the blockchain and encouraging transactions fees to incentivize miners.

{{Quote|Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.|Satoshi Nakamoto <ref>https://bitcoin.org/bitcoin.pdf</ref>}}

The fixed blocksize limit cannot be modified without a hard fork.

Hard forks require adoption by virtually all of the bitcoin participants.

== Arguments in favor of increasing the blocksize ==
* Bigger blocks (more transactions per second)
* Sidechains and Lightning do not exist.

== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* An emergency hard fork can achieve consensus for deployment on a short time period if needed, should blocks become full before Bitcoin has scalability improvements.
* Risk of catastrophic consensus failure{{clarification needed}}
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* No amount of max block size would support all the world's future transactions on the main blockchain (various types of off-chain transactions are the only long-term solution)
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.

=== Damage to decentalization ===
* Bitcoin is only useful if it is decentralized because centralization requires trust. Bitcoins value proposition is trustlessness.
* The larger the hash-rate a single miner controls, the more centralized Bitcoin becomes and the more trust using Bitcoin requires.
* Running your own full node while mining rather than giving another entity the right to your hash-power decreases the hash-rate of large miners. Those who control hash-power are able to control their own hash power if and only if they run a full node.
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.
* Larger blocks leads to more expensive full nodes.
* Therefore, larger blocks lead to less hashers running full nodes, which leads to centralized entities having more power, which makes Bitcoin require more trust, which weakens Bitcoins value proposition.

== Entities positions ==
Positions below are based on a suggested fixed block size increase to 20MiB. Positions against these larger blocks do not necessarily imply that they are against an increase in general, and may instead support a smaller and/or gradual increase.
{| class="wikitable sortable"
! Entity
! Supports Larger Blocks
! Supports Hard Fork
|-
| [[Armory]]
| {{Yes}} "This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner[http://sourceforge.net/p/bitcoin/mailman/message/34093337/]
|
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}[http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp]
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}[http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd]
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}[https://twitter.com/bithours/status/605131647747358721]
|
|-
| [[BitPay]]
| {{Yes}} "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair[https://twitter.com/spair/status/595341090317799424]
|
|-
| Bitrated
| {{No}} "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)[https://twitter.com/shesek/status/605005384026177537]
|
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}[https://twitter.com/Bittirahafi/status/596682373028311040] "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade[https://twitter.com/Technom4ge/status/596334370803326978]
| {{Yes}} "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade[https://twitter.com/Technom4ge/status/596334370803326978]
|-
| [[Blockchain.info]]
|{{Yes}} "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith[https://twitter.com/OneMorePeter/status/595676380320407553] "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary[https://twitter.com/niccary/status/595707211994763264]
|
|-
| Breadwallet
| {{Yes}} "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine[http://sourceforge.net/p/bitcoin/mailman/message/34096857/]
|
|-
| [[BTC Guild]]
| {{Yes}} "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria[https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3]
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}[https://twitter.com/BitcoinThai/status/605022509101023232]
|
|-
| [[Coinbase (business)|CoinBase]]
|{{Yes|Yes: "Coinbase supports increasing the maximum block size"}}[https://twitter.com/coinbase/status/595741967759335426] "Why we should increase the block size" - CEO Brian Armstrong[https://twitter.com/brian_armstrong/status/595453245884997634]
|
|-
| Ethereum 
| {{Neutral|Neutral: "If <nowiki>[the niche of digital gold]</nowiki> is what Bitcoin users want, then they should keep the limit, and perhaps even decrease it. But if Bitcoin users want to be a payment system, then up it must go."}} - Vitalik Buterin (founder)[http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6]
|
|-
| [[F2Pool]]
| {{Yes|Yes: "We do support bigger blocks and sooner rather than later. But we cannot handle 20 MB blocks right now. ... I think we can accept 5MB block at most."}}[http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/]
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}[http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84]
|
|-
| Kryptoradio
| {{Yes}} "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen[https://twitter.com/koodilehto/status/596675967667568641]
|
|-
| [[MPEx]]
| {{No}}{{citation needed}}
|
|-
| OKCoin
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}[https://twitter.com/okcoinbtc/status/598412795240009728]
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois[http://fr.anco.is/2015/gavineries/]
|
|-
| Third Key Solutions
| {{Yes}} "Gavin is right. The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos[https://twitter.com/aantonop/status/595601619581964289]
|
|-
| Xapo
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares[https://twitter.com/wences/status/595768917907402752]
|
|}

Scalability

2015-06-08T00:15:05Z

Gappleto97: /* Scalability targets */ Updated Visa max capacity

The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.

==Scalability targets==

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 4,000 tps. It has a peak capacity of around 56,000 transactions per second, [http://usa.visa.com/about-visa/our-business/visa-transaction.js] however they never actually use more than about a third of this even during peak shopping periods. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]

PayPal, in contrast, handles around 10 million transactions per day for an average of 115 tps. [https://www.paypal-media.com/about]

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.

==Current bottlenecks==

Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.

==CPU==

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some [[ECDSA]] signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.

Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.

==Network==

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.

When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.

==Storage==

At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.

==Optimizations==

The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks).

However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.

===CPU===

Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.

Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).

Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.

===Simplified payment verification===


It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg. you only really need to store as low as 2016 headers).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

See also: [[Thin Client Security]].

== Related work ==
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.

* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.

[[Category:Technical]]