Difference between revisions of "Block size limit controversy"

From Bitcoin Wiki
Jump to: navigation, search
(Entities positions)
Line 104: Line 104:
| [[MPEx]]
| [[MPEx]]
| {{No}}{{citation needed}}
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>

Revision as of 03:10, 11 June 2015


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.

Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
—Satoshi Nakamoto [1]

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)

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.

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[2]

Bitcoinpaygate No: "We do NOT support the blocksize increase"[3]
BitcoinReminder Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"[4]
BitHours Yes: "We support @gavinandresen and his proposal for 20mb blocks"[5]
BitPay Yes
"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair[6]
Bitrated No
"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)[7]
Bittiraha.fi Yes: "We are supporting increasing #Bitcoin max block size to 20MB."[8]
"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade[9]
"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade[10]
Blockchain.info Yes
"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith[11]
"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary[12]
Breadwallet Yes
"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine[13]
BTC Guild Yes
"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria[14]
BX.in.th Yes: "http://BX.in.th will support the 20MB block size"[15]
CoinBase Yes: "Coinbase supports increasing the maximum block size"[16]
"Why we should increase the block size" - CEO Brian Armstrong[17]
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)[18]
F2Pool 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."[19]
GreenAddress No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."[20]
Kryptoradio Yes
"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen[21]
MPEx No[22]
OKCoin Yes: "OKCoin's tech team believes it's the right decision"[23]
Paymium No: "[allow] a sane transaction fee market to emerge, by letting the blocks actually fill-up." - CTO David Francois[24]
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[25]
Xapo Yes: "One meg is not enough: Xapo supports increasing the maximum block size" - CEO Wences Casares[26]
  1. https://bitcoin.org/bitcoin.pdf
  2. http://sourceforge.net/p/bitcoin/mailman/message/34093337/
  3. http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp
  4. http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd
  5. https://twitter.com/bithours/status/605131647747358721
  6. https://twitter.com/spair/status/595341090317799424
  7. https://twitter.com/shesek/status/605005384026177537
  8. https://twitter.com/Bittirahafi/status/596682373028311040
  9. https://twitter.com/Technom4ge/status/596334370803326978
  10. https://twitter.com/Technom4ge/status/596334370803326978
  11. https://twitter.com/OneMorePeter/status/595676380320407553
  12. https://twitter.com/niccary/status/595707211994763264
  13. http://sourceforge.net/p/bitcoin/mailman/message/34096857/
  14. https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3
  15. https://twitter.com/BitcoinThai/status/605022509101023232
  16. https://twitter.com/coinbase/status/595741967759335426
  17. https://twitter.com/brian_armstrong/status/595453245884997634
  18. http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6
  19. http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/
  20. http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
  21. https://twitter.com/koodilehto/status/596675967667568641
  22. http://log.bitcoin-assets.com//?date=07-01-2015#967332
  23. https://twitter.com/okcoinbtc/status/598412795240009728
  24. http://fr.anco.is/2015/gavineries/
  25. https://twitter.com/aantonop/status/595601619581964289
  26. https://twitter.com/wences/status/595768917907402752