Difference between revisions of "Block size limit controversy"
(The blocksize limit was not introduced to encourage higher fees. (otherwise need citation) Clarified this by putting this in the argument list. Also, only a majority and not the support of virtually everyone is required for a hardfork.) |
(The argument that an emergency hard fork can reach consensus if needed is actually an argument in favor of raising the blocksize "if needed". This is unclear/needs clarification.) |
||
Line 6: | Line 6: | ||
== Unclear Arguments == | == Unclear Arguments == | ||
+ | * An emergency hard fork can achieve consensus for deployment on a short time period if needed. {{clarification needed}} | ||
* Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc. | * Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc. | ||
** Neutral: Bitcoin competitors will have lower fees | ** Neutral: Bitcoin competitors will have lower fees | ||
Line 15: | Line 16: | ||
== Arguments in opposition to increasing the blocksize == | == Arguments in opposition to increasing the blocksize == | ||
− | |||
− | |||
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}} | * Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}} | ||
* Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds. | * Orphan rate amplification, more reorgs and double-spends due to slower propagation speeds. |
Revision as of 21:20, 10 August 2015
![]() |
This page documents a current event. Information may change rapidly as the event progresses. |
See also: Scalability FAQ
Blocks are limited to 1MB in size. Miners can mine blocks upto the 1MB fixed limit, but any block larger than 1MB is invalid. The blocksize limit was introduced as an anti-DDoS measure and its main purpose is to discourage economically frivolous transactions from flooding the block chain.[citation needed] This limit cannot be modified without a hard fork. Hard forks require adoption by a majority of all of the bitcoin participants, especially miners.
Contents
Arguments in favor of increasing the blocksize
- More transactions per second
Unclear Arguments
- An emergency hard fork can achieve consensus for deployment on a short time period if needed. [clarification needed]
- Increased blocksize will leave space for extensions like Mastercoin, Counterparty, etc.
- Neutral: Bitcoin competitors will have lower fees
- Negative: Bitcoin full nodes are forced to use more resources that don't support Bitcoin
- Faster confirmation times with lower fees required
- Positive: Bitcoin users pay lower fees
- Negative: It will continue to be cheap to spam transactions such as Satoshi Dice bets
- Negative: Fees cannot be zero eventually in order to secure the mining ecosystem
Arguments in opposition to increasing the blocksize
- Risk of catastrophic consensus failure[1][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?]
- "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.
- A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop")
Damage to decentralization
- 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[2].
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 | |
---|---|---|---|
Bitcoinpaygate | No: "We do NOT support the blocksize increase"[3] | ||
Bitrated | No "At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)[4] |
||
GreenAddress | No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."[5] | ||
MPEx | No[6] | ||
Paymium | No: "[allow] a sane transaction fee market to emerge, by letting the blocks actually fill-up." - CTO David Francois[7] | ||
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)[8] | ||
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."[9] | ||
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[10] |
||
BitcoinReminder | Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"[11] | ||
BitHours | Yes: "We support @gavinandresen and his proposal for 20mb blocks"[12] | ||
BitPay | Yes "Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair[13] |
||
Bittiraha.fi | Yes: "We are supporting increasing #Bitcoin max block size to 20MB."[14] "I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade[15] |
Yes "And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade[16] | |
Blockchain.info | Yes "It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith[17] "Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary[18] |
||
Breadwallet | Yes "[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine[19] |
||
BTC Guild | Yes "Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria[20] |
||
BX.in.th | Yes: "http://BX.in.th will support the 20MB block size"[21] | ||
CoinBase | Yes: "Coinbase supports increasing the maximum block size"[22] "Why we should increase the block size" - CEO Brian Armstrong[23] |
||
Dr. 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." [24] | 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[25] |
|
Kryptoradio | Yes "#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen[26] |
||
OKCoin | Yes: "OKCoin's tech team believes it's the right decision"[27] | ||
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[28] |
||
Xapo | Yes: "One meg is not enough: Xapo supports increasing the maximum block size" - CEO Wences Casares[29] |
- ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
- ↑ https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/
- ↑ http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp
- ↑ https://twitter.com/shesek/status/605005384026177537
- ↑ http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
- ↑ http://log.bitcoin-assets.com//?date=07-01-2015#967332
- ↑ http://fr.anco.is/2015/gavineries/
- ↑ http://www.reddit.com/r/ethereum/comments/380q61/i_know_this_may_not_directly_be_ethereum_related/crrofl6
- ↑ http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/
- ↑ http://sourceforge.net/p/bitcoin/mailman/message/34093337/
- ↑ http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd
- ↑ https://twitter.com/bithours/status/605131647747358721
- ↑ https://twitter.com/spair/status/595341090317799424
- ↑ https://twitter.com/Bittirahafi/status/596682373028311040
- ↑ https://twitter.com/Technom4ge/status/596334370803326978
- ↑ https://twitter.com/Technom4ge/status/596334370803326978
- ↑ https://twitter.com/OneMorePeter/status/595676380320407553
- ↑ https://twitter.com/niccary/status/595707211994763264
- ↑ http://sourceforge.net/p/bitcoin/mailman/message/34096857/
- ↑ https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3
- ↑ https://twitter.com/BitcoinThai/status/605022509101023232
- ↑ https://twitter.com/coinbase/status/595741967759335426
- ↑ https://twitter.com/brian_armstrong/status/595453245884997634
- ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
- ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
- ↑ https://twitter.com/koodilehto/status/596675967667568641
- ↑ https://twitter.com/okcoinbtc/status/598412795240009728
- ↑ https://twitter.com/aantonop/status/595601619581964289
- ↑ https://twitter.com/wences/status/595768917907402752