Block size limit controversy

Blocks size in blockchain is limited to 1MB. Miners can mine blocks up to the 1MB fixed limit, but any block larger than 1MB is invalid. This limit cannot be modified without a hard fork. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks (“altcoins”), hard forks require adoption by nearly all economically active full nodes.

1 Block size of Bitcoin mining
2 Letter of developers
3 Arguments in favor of increasing the blockchain block size
4 Arguments in opposition to increasing the block size limit
- 4.1 Damage to decentralization
5 Proposals
6 Entities positions
7 See also
8 External links
9 References

Block size of Bitcoin mining

No issue in the history of cryptocurrencies has been debated as passionately, as often, or as forcefully as the bitcoin block size. To an outsider, it must be quite comical to witness folks debating a consensus parameter within the bitcoin network — no joke — as if it were a matter of life or death. To insiders, the stakes are high, tribal lines are drawn, and crossing them risks your reputation among your peers. The block size limit entered the world innocuously enough. A maximum block size limit of 1MB was added by Satoshi Nakamoto without any fanfare, or even any explanation, in July of 2010. Satoshi’s intent remains a debated topic, yet the parameter’s effect is clear — it limits the size of a block, the size of the batch of updates to the global ledger.

Recall that the Bitcoin network batches transactions into blocks that are released to the network approximately every ten minutes. To participate in the bitcoin network without a trusted third party, all of this blockchain data must be downloaded and verified in more or less real time. The more data that needs to be downloaded and verified to keep pace with the network, the larger the system requirements (bandwidth, cpu, storage) will necessarily be. The Bitcoin max block size limits the rate at which information is etched into the blockchain. Essentially, it acts to throttle the entire system. This limits the number of “on-chain” transactions that can be processed. The parameter’s value is of great consequence as it dictates the transactional throughput of the base layer. It also dictates the system requirements for participating in Bitcoin without needing to trust another party.

Letter of developers

Why the blocksize limit keeps Bitcoin free and decentralized?

Letter published at Change.org, signed by numerous developers of bitcoin software core Vladimir van der Laan, Cory Fields, Luke Dashjr, Jonas Schnelli, Gregory Maxwell-as well as programmers involved in the creation of various applications and platforms based on cryptocurrency (Blockstream, Darkwallet, Libbitcoin, Tidbit, etc.). In their letter, they emphasize that they played an important role in the development of bitcoin.

“We are fully committed to bitcoin and listening to the needs of the community. Over the past five years, we have written code, we have conducted more than fifty bitcoin updates and reviewed more than forty-five formal proposals to improve the performance of bitcoin, its reliability and its scalability. Technical discussions, sometimes heated, have always focused on improving bitcoin.”

Much has already been done, but” a number of key problems still stand”, the authors of the open letter. But the most important thing, in their opinion – caution, because bitcoin “means a lot to many people”, and at stake billions of dollars of user assets. Moreover, it is very important to increase the maximum block size without damaging “the most important features of bitcoin – decentralization, reliability and openness to updates”. Insisting that they years considered the question of the block size, the authors of the letter imply that there is no one who could better judge of this matter than themselves.

But in the letter they report that they will look for solutions only together with other members of the bitcoin community. The authors report on two upcoming seminars on increasing the maximum size of the bloc, which they believe will lead to a “technical consensus” in the ongoing discussion. The first workshop will be held on 12-13 September in montréal and the second on 6-7 December in Hong Kong. The authors of the letter Express confidence that”working together, we will be able to agree on a better way of action.”

The letter is signed by many developers of the bitcoin core software. But under it there is no signature of Andresen Gavin and Mike Hearn. Two of the most famous bitcoin developers believe that they have already found a solution to the problem. They proposed BIP101-a change in the bitcoin code, increasing the maximum block size in the block chain to 8 megabytes since the beginning of 2016, followed by a doubling every two years – so the block size will be 16 megabytes in 2018, 32 megabytes in 2020 and so on. Faced with doubts about the need for such changes, Mike hirn decided to implement the development and create a new version of bitcoin, Bitcoin XT, based on BIP101.

The miners had a choice – either not to change anything and stay with the size of the block of 1 megabyte, or fully accept Bitcoin XT, based on the ideas of Andrisen and hirn. But despite the open letter in support of BIP101 and Gavin Andresen, signed by representatives of the largest bitcoin companies, the largest mining pools supported the third decision-BIP100, proposed by Jeff Garzik, and provides that the size of the block changes every three months in accordance with the result of the vote miners. Even KnCMiner who previously signed a letter in support of BIP101, in the end voted for BIP100.

Arguments in favor of increasing the blockchain block size

More transactions per second
Off-chain solutions are not yet ready to take off the load from the main blockchain.

Arguments in opposition to increasing the block size limit

Block size limit

There are many valid reasons to want a bigger block size. The current block size limits the Bitcoin use to 4-7 transactions per second. This can force regular users to compete for transactions by increasing the fees, pricing some users out of the network, once Bitcoin is popular enough.

A hard fork requires waiting for sufficient consensus.
Risk of catastrophic consensus failure^[1]
An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.^[2]
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
“Congestion” concerns can be solved with mempool improvements including transaction eviction.
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 decentralization

While a bigger block size is defended by many. There are also reasonable arguments for the concervative side that belives blocks should be limited to 1 MB.

Among these are the bandwidth requirements of full nodes, which would increase causing the full node count to be reduced. The fact that some solutions that do not require bigger blocks or an hard fork to take place in order to increase scalability, like segwit and sidechains, many claim that a bigger block size will not be necessary.

There is also the concern that introducing this change to Bitcoin through an hard fork will create instability, which could give way to complications like a split in the network resulting in two blockchains.

Larger blocks make full nodes more expensive to operate.
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.
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 have 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^[3].

Proposals

BIP 100

Change block size limit based on miner votes, but don’t leave the range (1MB, 32MB) without a softfork or hardfork respectively.

BIP 101

Increase to 8 MB after both January 11, 2016 has passed and 75% of miners are supporting. Double the limit every two years with the size increasing linearly within those two year intervals.

BIP 102

Increase to 2 MB on November 11, 2015.

BIP 103

Increase by 17.7% annually until 2063.

BIP 109

Hard Fork to 2MB in 2016. Dynamic max_block_size in 2017.

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.

Entity	Supports Larger Blocks	Supports Hard Fork
Magnr	Yes: “We believe an immediate 2mb blocksize increase is important and urgently required to enable Bitcoin to flourish and deliver more utilitarian use to more people all across the world.”^[4]	Yes: “We support the Bitcoin Classic proposal^[5] – Magnr^[6]
	No: “We do NOT support the blocksize increase”^[7]
	No:”At this time, I oppose increasing the block size limit as per Gavin’s proposal” – Nadav Ivgi (founder)^[8]
Green Address	No: “In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs.”^[9]
MPEx	No^[10]
Paymium	No: ” a sane transaction fee market to emerge, by letting the blocks actually fill-up.” – CTO David Francois^[11]
Ethereum	Neutral: “If the niche of digital gold 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)^[12]
F2Pool	Neutral: “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.”^[13]
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^[14]
	Yes: “BitcoinReminder.com also supports 20MB blocks (or even more?)”^[15]
	Yes: “We support @gavinandresen and his proposal for 20mb blocks”^[16]
Bitpay	Yes:”Agreed (but optimistic this will be the last and only time block size needs to increase)” – CEO Stephen Pair^[17]	Yes: “In summary, we believe BIP 101 will safeguard Bitcoin’s decentralized nature while providing a reliable, immediate path toward greater network throughput, and we would like to express our support for merging BIP 101 into Bitcoin Core.” – Stephen Pair^[18]
	Yes: “We are supporting increasing #Bitcoin max block size to 20MB.”}}^[19]“I’m strongly in favor of the block size cap increase to 20MB.” – CEO Henry Brade^[20]	Yes:”And I’m in favor of releasing a version with this change even with opposition.” – CEO Henry Brade^[21]
Blockchain.info	Yes:”It is time to increase the block size. Agree with @gavinandresen” – CEO Peter Smith^[22]“Scaling #bitcoin is a big deal. Increase the block size.” – Nic Cary^[23]
BlockTrail	Yes:”We’d love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too.”^[24]
Bread Wallet	Yes:”[…] in support of the Gavin’s 20Mb block proposal.” – CEO Aaron Voisine^[25]
BTC Guild	Yes:”Needs to happen, but needs future expansion built in at a reasonable rate.” – Eleuthria^[26]
BX.in.th	Yes: “http://BX.in.th will support the 20MB block size”^[27]
CoinBase	Yes: “Coinbase supports increasing the maximum block size”^[28]“Why we should increase the block size” – CEO Brian Armstrong^[29]	Yes: “5/ hard forks probably shouldn’t happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing” – CEO Brian Armstrong^[30]
Coinify	Yes:”We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network.” – CTO Hamed Sattari^[31]
Adam Back	Yes: “For the record I am not aware of a single person who has said they do not agree with scaling Bitcoin. Changing a constant is not the hard-part. The hard part is validating a plan and the other factors that go into it. It’s not a free choice it is a security/scalability tradeoff. No one will thank us if we “scale” bitcoin but break it in hard to recover ways at the same time.” ^[32]	No:”I strongly urge that we return to the existing collaborative constructive review process that has been used for the last 4 years which is a consensus by design to prevent one rogue person from inserting a backdoor, or lobbying for a favoured change on behalf of a special interest group, or working for bad actor” – Dr. Adam Back^[33]
	Yes:”#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin.” – Joel Lehtonen^[34]
OKCoin	Yes: “OKCoin’s tech team believes it’s the right decision” ^[35]
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^[36]
Xapo	Yes: “One meg is not enough: Xapo supports increasing the maximum block size” – CEO Wences Casares^[37]

External links

References

Categories:

Block size limit controversy

Block size limit controversy

Contents

Block size of Bitcoin mining

Letter of developers

Arguments in favor of increasing the blockchain block size

Arguments in opposition to increasing the block size limit

Damage to decentralization

Proposals

BIP 100

BIP 101

BIP 102

BIP 103

BIP 109

Entities positions

See Also on BitcoinWiki

External links

References