Block size limit controversy: Difference between revisions

From Bitcoin Wiki
Jump to navigation Jump to search
← Older edit
Phantomcircuit (talk | contribs)
Editors
99 edits
No solutions will be available immediately, however sidechains and lightning are technically capable of being delivered immediately, a hard forking blocksize change is not.
Luke-jr (talk | contribs)
Clerks, Administrators, Editors
3,074 edits
→‎Entities positions: Remove altcoin promotion
 
(75 intermediate revisions by 20 users not shown)
Line 1: Line 1:
== Argument in favor of increasing the blocksize ==
{{see also|Scalability FAQ}}
* Bigger blocks (more transactions per second)
Originally, Bitcoin's block size was limited by the number of database locks required to process it (at most 10000).
This limit was effectively around 500-750k in serialized bytes, and was forgotten until 2013 March.
In 2010, an explicit block size limit of 1 MB was introduced into Bitcoin by [[Satoshi Nakamoto]]. He added it hidden in two commits<ref>https://www.reddit.com/r/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a30b56eb "fix openssl linkage problems"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 1.</ref><ref>[https://github.com/bitcoin/bitcoin/commit/a790fa46f40 "don't count or spend payments until they have 1 confirmation"], Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 2.</ref> in secret. This limit was effectively a no-op due to the aforementioned forgotten limit.


== Argument in opposition of increasing the blocksize ==
In 2013 March, the original lock limit was discovered by accident (Bitcoin Core v0.8.0 failed to enforce it, leading to upgraded nodes splitting off the network).
After resolving the crisis, it was determined that since nobody knew of the limit, it was safe to assume there was consensus to remove it, and a [[hardfork]] removing the limit was scheduled and cleanly activated in 2013 May. From this point forward, the 1 MB limit became the effective limiting factor of the block size for the first time.
 
The limit was not changed again before 2017 and was believed to require a very invasive hard fork to change. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all [[Full node#Economic_strength|economically active]] full nodes.
 
== Arguments in favor of increasing the blocksize ==
* More transactions per second
* Off-chain solutions are not yet ready to take off the load from the main blockchain.
 
== Contentions ==
* 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
* Small blocks eventually will require higher fees for fast confirmations.
** Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
** Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
** Negative: Bitcoin may look unattractive to new users with high fees
** Negative: High fees may stop or reverse global adoption, investment, development, support and centralization{{clarification needed}}
** Negative: Bitcoin users pay higher fees
* A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
** A fee market naturally develops due to miner latency regardless<ref>https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit</ref>
*** The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.
 
== Arguments in opposition to increasing the blocksize ==
* A hard fork requires waiting for sufficient consensus.
* A hard fork requires waiting for sufficient consensus.
* Risk of catastrophic consensus failure<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>{{clarification needed}}
* An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.<ref>[https://www.reddit.com/r/Bitcoin/comments/392m43/mike_hearn_blocksize_debate_at_the_breaking_point/cs00wdd How to raise block size in a short time], Peter Todd, Reddit /r/Bitcoin, 9 June 2015</ref>
* 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.
* European/American pools at more of a disadvantage compared to the Chinese pools{{why}}
* 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)
* 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)
* Risk of catastrophic consensus failure{{clarification needed}}
* Fast block propagation is either not clearly viable, or (eg, IBLT) creates centralised controls.


=== Damage to decentalization ===
=== 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.
* 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.
* 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<ref>https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/</ref>.


* 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.
==History==
 
On October 3, 2010, [[Jeff Garzik]] published a patch that immediately increases the block size to 7MB.<ref>{{cite btct|id=1347|title=(PATCH) increase block size limit|date=2010-10-03}}</ref> The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork. Satoshi and theymos immediately said not to implement it, as it would make the user's node incompatible with the network.<ref name="dontuse">[https://bitcointalk.org/index.php?topic=1347.msg15139#msg15139 "+1 theymos. Don't use this patch"] Satoshi explains here that ''if'' a change is necessary, a hard fork ''could'' be implemented with a countdown.</ref> This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.<ref name="dontuse" />
* Less individuals who control hash-power will run full nodes if running one becomes more expensive.
===BIP 100===
Change block size limit based on miner votes, but don't leave the range (1MB, 32MB) without a softfork or hardfork respectively.
===Bitcoin XT===
[[File:xt.png|thumb|128px|Bitcoin XT logo]]{{main|Bitcoin XT}}
Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.


* Larger blocks leads to more expensive full nodes.
XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.
 
===BIP 102===
* 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.
Increase to 2 MB on November 11, 2015.
===BIP 103===
Increase by 17.7% annually until 2063.
===Bitcoin Classic===
{{main|Bitcoin Classic}}
Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.
===Segregated Witness===
[[File:segwit.png|thumb|128px|SegWit logo]]{{main|Segregated Witness}}
The final solution deployed was Segwit, increasing the block size limit to 2-4 MB without a hardfork.


== 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"
{| class="wikitable sortable"
! Entity
! Entity
! Supports Larger Blocks
! Supports Larger Blocks
! Supports Hard Fork
! Supports Hard Fork
|-
| [[Magnr]]
| {{Yes|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."}}<ref>https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154</ref>
| {{Yes|Yes: "We support the Bitcoin Classic proposal<ref>https://bitcoinclassic.com</ref>."}} - Magnr<ref>https://twitter.com/magnr/status/689227046120222721</ref>
|-
| Bitcoinpaygate
| {{No|No: "We do NOT support the blocksize increase"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp</ref>
|
|-
| Bitrated
| {{No}}<br />"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)<ref>https://twitter.com/shesek/status/605005384026177537</ref>
|
|-
| [[GreenAddress]]
| {{No|No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."}}<ref>http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84</ref>
|
|-
| [[MPEx]]
| {{No}}<ref>http://log.bitcoin-assets.com//?date=07-01-2015#967332</ref>
|
|-
| [[Paymium]]
| {{No|No: "<nowiki>[allow]</nowiki> a sane transaction fee market to emerge, by letting the blocks actually fill-up."}} - CTO David Francois<ref>http://fr.anco.is/2015/gavineries/</ref>
|
|-
| [[F2Pool]]
| {{Neutral|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."}}<ref>http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/</ref>
|
|-
| [[Armory]]
| {{Yes}}<br />"This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this." - CEO Alan Reiner<ref>http://sourceforge.net/p/bitcoin/mailman/message/34093337/</ref>
|
|-
| BitcoinReminder
| {{Yes|Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"}}<ref>http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd</ref>
|
|-
| BitHours
| {{Yes|Yes: "We support @gavinandresen and his proposal for 20mb blocks"}}<ref>https://twitter.com/bithours/status/605131647747358721</ref>
|
|-
| [[BitPay]]
| {{Yes}}<br />"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair<ref>https://twitter.com/spair/status/595341090317799424</ref>
| {{Yes|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<ref>https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516</ref>
|-
| Bittiraha.fi
| {{Yes|Yes: "We are supporting increasing #Bitcoin max block size to 20MB."}}<ref>https://twitter.com/Bittirahafi/status/596682373028311040</ref><br />"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
| {{Yes}}<br />"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade<ref>https://twitter.com/Technom4ge/status/596334370803326978</ref>
|-
| [[Blockchain.info]]
|{{Yes}}<br />"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith<ref>https://twitter.com/OneMorePeter/status/595676380320407553</ref><br />"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary<ref>https://twitter.com/niccary/status/595707211994763264</ref>
|
|-
| [[Blocktrail]]
|{{Yes}}<br />"We'd love to see BIP101 with 4mb start, alternatively BIP100 with something to deal with the 21% attack could be good too."<ref>https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/</ref><br />
|
|-
| Breadwallet
| {{Yes}}<br />"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine<ref>http://sourceforge.net/p/bitcoin/mailman/message/34096857/</ref>
|
|-
| [[BTC Guild]]
| {{Yes}}<br />"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria<ref>https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3</ref>
|
|-
| BX.in.th
| {{Yes|Yes: "<nowiki>http://BX.in.th</nowiki> will support the 20MB block size"}}<ref>https://twitter.com/BitcoinThai/status/605022509101023232</ref>
|
|-  
|-  
| CoinBase
| [[Coinbase (business)|CoinBase]]
|{{Yes}}
| {{Yes|Yes: "Coinbase supports increasing the maximum block size"}}<ref>https://twitter.com/coinbase/status/595741967759335426</ref><br />"Why we should increase the block size" - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/595453245884997634</ref>
| {{Yes|Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing"}} - CEO Brian Armstrong<ref>https://twitter.com/brian_armstrong/status/633309671994998784</ref>
|-
| [[Coinify]]
| {{Yes}}<br />"We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari<ref>https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/</ref>
|
|-
| [[Adam Back]]
| {{Yes|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."}} <ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
| {{No}}<br />"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<ref>https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html</ref>
|
|-
| Kryptoradio
| {{Yes}}<br />"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen<ref>https://twitter.com/koodilehto/status/596675967667568641</ref>
|
|-
| [[OKCoin]]
| {{Yes|Yes: "OKCoin's tech team believes it's the right decision"}}<ref>https://twitter.com/okcoinbtc/status/598412795240009728</ref>
|
|-
| [[Third Key Solutions]]
| {{Yes}}<br />"Gavin is right.  The time to increase the block size limit is before transaction processing shows congestion problems." - CTO Andreas Antonopoulos<ref>https://twitter.com/aantonop/status/595601619581964289</ref>
|
|-
| [[Xapo]]
| {{Yes|Yes: "One meg is not enough: Xapo supports increasing the maximum block size"}} - CEO Wences Casares<ref>https://twitter.com/wences/status/595768917907402752</ref>
|
|
|}
|}
==References==
<references/>
[[Category:2015 events]]

Latest revision as of 00:44, 24 April 2019

See also: Scalability FAQ

Originally, Bitcoin's block size was limited by the number of database locks required to process it (at most 10000). This limit was effectively around 500-750k in serialized bytes, and was forgotten until 2013 March. In 2010, an explicit block size limit of 1 MB was introduced into Bitcoin by Satoshi Nakamoto. He added it hidden in two commits[1][2][3] in secret. This limit was effectively a no-op due to the aforementioned forgotten limit.

In 2013 March, the original lock limit was discovered by accident (Bitcoin Core v0.8.0 failed to enforce it, leading to upgraded nodes splitting off the network). After resolving the crisis, it was determined that since nobody knew of the limit, it was safe to assume there was consensus to remove it, and a hardfork removing the limit was scheduled and cleanly activated in 2013 May. From this point forward, the 1 MB limit became the effective limiting factor of the block size for the first time.

The limit was not changed again before 2017 and was believed to require a very invasive hard fork to change. As transaction volume increased with widespread Bitcoin adoption, increasing the limit became subject to heavy debate in 2015. To prevent Bitcoin from temporarily or permanently splitting into separate payment networks ("altcoins"), hard forks require adoption by nearly all economically active full nodes.

Arguments in favor of increasing the blocksize

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

Contentions

  • 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
  • Small blocks eventually will require higher fees for fast confirmations.
    • Positive: It will no longer be cheap to spam transactions such as Satoshi Dice bets
    • Positive: Fees will not be zero. This is eventually a necessity in order to incentivize miners and secure the mining ecosystem
    • Negative: Bitcoin may look unattractive to new users with high fees
    • Negative: High fees may stop or reverse global adoption, investment, development, support and centralization[clarification needed]
    • Negative: Bitcoin users pay higher fees
  • A low blocksize limit encourages higher transactions fees to incentivize miners ("let a fee market develop").
    • A fee market naturally develops due to miner latency regardless[4]
      • The relay network can be optimized so that miners don't have a stale rate increasing with latency. This should cause the fee market to once again require a block size limit to exist.

Arguments in opposition to increasing the blocksize

  • A hard fork requires waiting for sufficient consensus.
  • Risk of catastrophic consensus failure[5][clarification needed]
  • An emergency hard fork that can achieve consensus can be deployed on a short time period if needed.[6]
  • 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.

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

History

On October 3, 2010, Jeff Garzik published a patch that immediately increases the block size to 7MB.[8] The patch had no users, but it was the earliest attempt at increasing the block size through a hardfork. Satoshi and theymos immediately said not to implement it, as it would make the user's node incompatible with the network.[9] This is the oft-cited post which many people claim proves Satoshi intended for the blocksize to increase. English, however, does not work that way. Satoshi spoke conditionally, not intentionally.[9]

BIP 100

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

Bitcoin XT

Bitcoin XT logo
Main article: Bitcoin XT

Bitcoin XT was an alternative client that became notorious when it adopted BIP 101, which would direct an increase to 8 MB after both January 11, 2016 has passed and 75% of miners are in support, followed by doubling of the limit every two years with the size increasing linearly within those two year intervals.

XT failed to gain enough support to activate the hardfork, leading to Mike Hearn's resignation.

BIP 102

Increase to 2 MB on November 11, 2015.

BIP 103

Increase by 17.7% annually until 2063.

Bitcoin Classic

Main article: Bitcoin Classic

Adopt BIP 109 and hardfork to 2 MB in 2016. Dynamic max_block_size in 2017.

Segregated Witness

SegWit logo
Main article: Segregated Witness

The final solution deployed was Segwit, increasing the block size limit to 2-4 MB without a hardfork.

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."[10] Yes: "We support the Bitcoin Classic proposal[11]." - Magnr[12]
Bitcoinpaygate No: "We do NOT support the blocksize increase"[13]
Bitrated No
"At this time, I oppose increasing the block size limit as per Gavin's proposal" - Nadav Ivgi (founder)[14]
GreenAddress No: "In our mind increasing the block size like this is just pushing the problem a little further at potentially unfixable costs."[15]
MPEx No[16]
Paymium No: "[allow] a sane transaction fee market to emerge, by letting the blocks actually fill-up." - CTO David Francois[17]
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."[18]
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[19]

BitcoinReminder Yes: "BitcoinReminder.com also supports 20MB blocks (or even more?"[20]
BitHours Yes: "We support @gavinandresen and his proposal for 20mb blocks"[21]
BitPay Yes
"Agreed (but optimistic this will be the last and only time block size needs to increase)" - CEO Stephen Pair[22] 		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[23]
Bittiraha.fi Yes: "We are supporting increasing #Bitcoin max block size to 20MB."[24]
"I'm strongly in favor of the block size cap increase to 20MB." - CEO Henry Brade[25] 		Yes
"And I'm in favor of releasing a version with this change even with opposition." - CEO Henry Brade[26]
Blockchain.info Yes
"It is time to increase the block size. Agree with @gavinandresen" - CEO Peter Smith[27]
"Scaling #bitcoin is a big deal. Increase the block size." - Nic Cary[28]
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."[29]
Breadwallet Yes
"[...] in support of the Gavin's 20Mb block proposal." - CEO Aaron Voisine[30]
BTC Guild Yes
"Needs to happen, but needs future expansion built in at a reasonable rate." - Eleuthria[31]
BX.in.th Yes: "http://BX.in.th will support the 20MB block size"[32]
CoinBase Yes: "Coinbase supports increasing the maximum block size"[33]
"Why we should increase the block size" - CEO Brian Armstrong[34] 		Yes: "5/ hard forks probably shouldn't happen frequently, but periodically they are an elegant solution that helps bitcoin keep growing" - CEO Brian Armstrong[35]
Coinify Yes
"We see Bitcoin XT as the best solution for ensuring the future scalability of the Bitcoin network." - CTO Hamed Sattari[36]
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." [37] 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[38]
Kryptoradio Yes
"#Kryptoradio dev @zouppen supports 20MB block size in #bitcoin." - Joel Lehtonen[39]
OKCoin Yes: "OKCoin's tech team believes it's the right decision"[40]
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[41]
Xapo Yes: "One meg is not enough: Xapo supports increasing the maximum block size" - CEO Wences Casares[42]

References

  1. ↑ https://www.reddit.com/r/Bitcoin/comments/63859l/github_commit_where_satoshi_added_the_block_size/
  2. ↑ "fix openssl linkage problems", Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 1.
  3. ↑ "don't count or spend payments until they have 1 confirmation", Sneaky soft-forking UASF commit for MAX_BLOCK_SIZE No. 2.
  4. ↑ https://dl.dropboxusercontent.com/u/43331625/feemarket.pdf A Transaction Fee Market Exists Without a Block Size Limit
  5. ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
  6. ↑ How to raise block size in a short time, Peter Todd, Reddit /r/Bitcoin, 9 June 2015
  7. ↑ https://www.weusecoins.com/why-blocksize-limit-keeps-bitcoin-free-decentralized/
  8. ↑ BitcoinTalk thread 1347. (PATCH) increase block size limit 2010-10-03.
  9. ↑ 9.0 9.1 "+1 theymos. Don't use this patch" Satoshi explains here that if a change is necessary, a hard fork could be implemented with a countdown.
  10. ↑ https://github.com/bitcoinclassic/website/issues/3#issuecomment-172678154
  11. ↑ https://bitcoinclassic.com
  12. ↑ https://twitter.com/magnr/status/689227046120222721
  13. ↑ http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crqsnqp
  14. ↑ https://twitter.com/shesek/status/605005384026177537
  15. ↑ http://www.reddit.com/r/Bitcoin/comments/35anax/list_of_bitcoin_services_that_support_increasing/cr2mq84
  16. ↑ http://log.bitcoin-assets.com//?date=07-01-2015#967332
  17. ↑ http://fr.anco.is/2015/gavineries/
  18. ↑ http://sourceforge.net/p/bitcoin/mailman/message/34157036/],[http://sourceforge.net/p/bitcoin/mailman/message/34158911/
  19. ↑ http://sourceforge.net/p/bitcoin/mailman/message/34093337/
  20. ↑ http://www.reddit.com/r/Bitcoin/comments/37y8wm/list_of_bitcoin_services_that_supportoppose/crs9ytd
  21. ↑ https://twitter.com/bithours/status/605131647747358721
  22. ↑ https://twitter.com/spair/status/595341090317799424
  23. ↑ https://medium.com/@spair/increasing-the-block-size-limit-85ff236fc516
  24. ↑ https://twitter.com/Bittirahafi/status/596682373028311040
  25. ↑ https://twitter.com/Technom4ge/status/596334370803326978
  26. ↑ https://twitter.com/Technom4ge/status/596334370803326978
  27. ↑ https://twitter.com/OneMorePeter/status/595676380320407553
  28. ↑ https://twitter.com/niccary/status/595707211994763264
  29. ↑ https://blog.blocktrail.com/2015/08/miners-block-size-vote-explained/
  30. ↑ http://sourceforge.net/p/bitcoin/mailman/message/34096857/
  31. ↑ https://www.reddit.com/r/Bitcoin/comments/370rko/21_inc_engineer_everyone_assumes_humans_will_be/crjfnpg?context=3
  32. ↑ https://twitter.com/BitcoinThai/status/605022509101023232
  33. ↑ https://twitter.com/coinbase/status/595741967759335426
  34. ↑ https://twitter.com/brian_armstrong/status/595453245884997634
  35. ↑ https://twitter.com/brian_armstrong/status/633309671994998784
  36. ↑ https://news.coinify.com/coinify-supports-bitcoin-xt-scalability-bitcoin-payments/
  37. ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
  38. ↑ https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08276.html
  39. ↑ https://twitter.com/koodilehto/status/596675967667568641
  40. ↑ https://twitter.com/okcoinbtc/status/598412795240009728
  41. ↑ https://twitter.com/aantonop/status/595601619581964289
  42. ↑ https://twitter.com/wences/status/595768917907402752
Retrieved from "https://en.bitcoin.it/w/index.php?title=Block_size_limit_controversy&oldid=66404"