#Blocksize Survey

[flix]

The Bitcoin Network will probably reach the 7 tps level in 2016 at current growth rates. With a maximum block size of 1MB this will force an increase in fees and stress the network, unless the rules are changed to allow larger blocks.

Here is a summary of several major proposals by the core developers on how to solve this issue:

For near-term increase:
Gavin Andresen: Currently favors "8MB very soon, then automatic double every two years till it hits 8GB in distant future", aka BIP101. Also finds Jeff Garzik's BIP100 (see below) acceptable.
[INTERVIEW] https://youtu.be/B8l11q9hsJM
Mike Hearn: Agrees with Gavin on BIP101. Currently working on implementing the increase in an alternative client, Bitcoin XT, to provide full node operators with a real choice.  
[INTERVIEW]  https://youtu.be/8JmvkyQyD8w
Jeff Garzik: Favors "8MB after miner negotiation and a delay period before enforcement, stepping up/down on maxblocksize possible after with similar miner voting, absolute upper limit for the hard fork at 32MB", aka BIP100. Also proposed "2MB immediately and nothing further", aka BIP102, as an emergency stopgap in case adoption takes off, fees ratchet up and the sudden ecosystem meltdown puts further growth in danger.

For very conservative increase:
Pieter Wuille: "First increase scheduled at 2017 (to ~1.04MB, I believe), then automatic increase some 17% per year till 2GB in distant future", aka "Draft BIP103" (nominally un-numbered).
Luke-jr: Finds Pieter's proposal an acceptable compromise, though generally favors smaller blocks, occasionally expressing views that even 1MB blocks are too big.

Against increase until "something X is implemented":
Adam Back: Proposed "Extension blocks", aka a sidechain-lite, that allows migration to bigger blocks with only a soft fork. Also favors only migrating when sidechain tech is ready, against hard-forks in general.
[PODCAST] http://a16z.com/2015/09/02/a16z-podcast-hard-forks-hard-choices-for-bitcoin/  [VID] https://youtu.be/wYHyR2E5Pic

Against increase in near-to-medium term future:
Gregory Maxwell: Against hard-forks in general, also against bigger blocks in the short-to-medium term future.
Mark Friedenbach: Against hard-forks in general, also against bigger blocks in the short-to-medium term future.

Staying neutral:
Wladimir J. van der Lann (Core lead dev): "You guys wake me up when you have a consensus, not gonna merge anything till then" (not actual words)

===================================================================================================

Positions of major miners, companies:                 http://blocksize.org/

Bitcoin Consensus Census               https://bitcoin.consider.it/

[flix]

Of course the devs don't have the final word... many other stakeholders will get to vote on what actually happens, especially in a hard fork where any holder of BTC will get to choose sides. Miners, nodes, wallet providers, investors... all will have their say.

Still, a broad consensus is very desirable as a contested hard fork will cause a great deal of turmoil. A 50-50 Bitcoin civil war would be a horrible scenario, causing volatility and uncertainty for many months or even years.

With a bit of leadership and consensus among developers, it should be much easier to reach a meaningful (90%?) consensus in the Bitcoin community which makes the hard fork as smooth as possible.

[AtheistAKASaneBrain]

Of course the devs don't have the final word... many other stakeholders will get to vote on what actually happens, especially in a hard fork where any holder of BTC will get to choose sides. Miners, nodes, wallet providers, investors... all will have their say.

Still, a broad consensus is very desirable as a contested hard fork will cause a great deal of turmoil. A 50-50 Bitcoin civil war would be a horrible scenario, causing volatility and uncertainty for many months or even years.

With a bit of leadership and consensus among developers, it should be much easier to reach a meaningful (90%?) consensus in the Bitcoin community which makes the hard fork as smooth as possible.

There's no civil war scenario, as long as the protocol works is all that matters, people can fight all they want. Maybe it will take a dead end scenario were we are pushed to do something to reach a consensus.

[mindrust]

I can do with any scenario, as long as everyone's opinion got considered. Because i am  someone who got no idea about the blocksize but also a true democrat who respects the others opinions.

[flix]

Of course the devs don't have the final word... many other stakeholders will get to vote on what actually happens, especially in a hard fork where any holder of BTC will get to choose sides. Miners, nodes, wallet providers, investors... all will have their say.

Still, a broad consensus is very desirable as a contested hard fork will cause a great deal of turmoil. A 50-50 Bitcoin civil war would be a horrible scenario, causing volatility and uncertainty for many months or even years.

With a bit of leadership and consensus among developers, it should be much easier to reach a meaningful (90%?) consensus in the Bitcoin community which makes the hard fork as smooth as possible.

There's no civil war scenario, as long as the protocol works is all that matters, people can fight all they want. Maybe it will take a dead end scenario were we are pushed to do something to reach a consensus.

Well... if we have a 50-50 split between Bitcoin and Bitcoin XT, or any other "small Bitcoin" vs "big Bitcoin"... and both currencies have enough traction there will be a period of time in which both coins fight for the Bitcoin name. Of course nobody is forced to choose sides... but keeping coins in the losing chain means a lot of lost value... also confusion among wallets, users and markets as to which Bitcoin they are using can lead to a lot of trouble. Much more than we have seen with soft forks in the past.

Whereas if there is consensus... it is just a matter of "everybody update their software" and trauma can be kept to a minimum.

[Lauda]

Before I could cast my vote, I needed to learn something new. This is the first time that I've heard about extension blocks, and I'm fairly interested because it only requires as soft fork. Adam kind of proposed one optional 10 MB (changeable) blockchain that synchronizes with the 1 MB blockchain (i.e "sidechain-lite"). However, Gavin has made a point that this might bring 'too much unnecessary complexity'. 10 MB extension blocks are pretty much as dangerous as 10 MB main blocks.
Pieter Wuillie and Luke-jr have weird mindsets. The network is now having trouble from time to time with the amount of transactions. How can 1 MB blocks be even too big?

From my perspective, even with sidechains/lightning network/something else there will come a time where 1 MB blocks are not enough. Forking in the future is a terrible idea. A increase should be done as soon as possible (after all negotiations, coding, testing, consensus have been dealt with) to leave room for the future. I hardly doubt that we can do any damage if we increase it to X amount.
Considering the proposals on the table I would say, BIP100 seems the most reasonable one.

[flix]

I don't think that it will be possible to do another hard fork in 2017 and beyond. Once Bitcoin reaches 30-50 million users (of which 3-5 million will be frequent users) hard forks will be almost impossible and solutions will need to be built on layers above the main Bitcoin protocol.

Because of this, I feel very strongly that any solution should be permanent. It should also be flexible enough to adapt to rapidly changing user growth. If Bitcoin adoption follows the Twitter pattern and goes from 30 to 300 million users in 4 years... the blocksize limit should automatically adjust.

The way that the difficulty mechanism has been able to adjust to multiple scenarios (slow growth, exponential growth, decline, medium growth) is IMHO the ideal to aim for with maxblocksize.  https://blockchain.info/charts/difficulty

Failing that, I would be happy with BIP100 or BIP101.

...but whatever happens, a 90% consensus among miners, exchanges and wallet providers is an absolute must-have. I don't want to have 2 types of Bitcoin in my wallets for any extended period of time.

[flix]

Another reason to do the fork soon, is that after the next reward halving (est.2017) it will be much harder to convince miners to accept low tx fees. Right now fees are a tiny part of their income compared to the 25BTC reward... in effect all BTC holders are currently paying miners via inflation. As new money creation declines, fees will have to pay for the network.

...but it is better for everyone if fees become a major source of income for miners at 50 million users and 1M daily txs than earlier. Scale must come first.

Social media companies (like Twitter and Facebook) that delayed revenue generation until they reached massive scale and network effects are a good example.

[Pk880058]

Another reason to do the fork soon, is that after the next reward halving (est.2017) it will be much harder to convince miners to accept low tx fees. Right now fees are a tiny part of their income compared to the 25BTC reward... in effect all BTC holders are currently paying miners via inflation. As new money creation declines, fees will have to pay for the network.

I think that the fees we give for transaction becomes the part of the pool's income and not of the miners.
Isn't that right?

[LiteCoinGuy]

BIP101. Gavin Andresen. Let us go.

(Jeffs idea is "just" a workaround.)

[flix]

BIP101. Gavin Andresen. Let us go.

(Jeffs idea is "just" a workaround.)

Sure, Jeff and Gavin are mostly in agreement anyway...

[Lauda]

BIP101. Gavin Andresen. Let us go.

(Jeffs idea is "just" a workaround.)

Sure, Jeff and Gavin are mostly in agreement anyway...

Actually it is not just a workaround. "miner negotiation and a delay period before enforcement" is actually very important one wants to get this done right and with consensus. If they want to force the blocksize increase, then we can just skip this part.
Either BIP100 or BIP101 would be a good place to start. The question is when?
The 2 MB proposal is BIP102 and should not be confused with BIP100.

[LiteCoinGuy]

BIP101. Gavin Andresen. Let us go.

(Jeffs idea is "just" a workaround.)

Sure, Jeff and Gavin are mostly in agreement anyway...

Actually it is not just a workaround. "miner negotiation and a delay period before enforcement" is actually very important one wants to get this done right and with consensus. If they want to force the blocksize increase, then we can just skip this part.
Either BIP100 or BIP101 would be a good place to start. The question is when?

thanks  . i thought that jeff made a proposal for  2 MB blocks just because we need more time.

iam still in favor with gavins vision.

[unamis76]

Was going to vote BIP 101, but since 2 options are allowed, voted 101 and 100. BIP101 is the best proposal, but it should adopt BIP100 block increase/decrease mechanism and final block size to be perfect.

Here's an interesting link I found on the issue.

[Kazimir]

Consensus is WAY more important than whatever particular solution it's gonna be.

Increasing blocksize now, increasing blocksize gradually over time in the near future, lowering the average block time, all fine with me. Bitcoin should remain functional like it has been the past 6.5 years.

[flix]

Consensus is WAY more important than whatever particular solution it's gonna be.

Increasing blocksize now, increasing blocksize gradually over time in the near future, lowering the average block time, all fine with me. Bitcoin should remain functional like it has been the past 6.5 years.

Agree completely. Any change must have overwhelming consensus.

But consensus can be built over time, and the way to do so is to have an extended and very public discussion of the issue. We still have at least 6 months before the problems become urgent. We should make the most of that time to get each dev to explain their position very clearly, including its consequences and meaning for the future of Bitcoin.

[Pain84]

Pieter Wuillie and Luke-jr have weird mindsets. The network is now having trouble from time to time with the amount of transactions. How can 1 MB blocks be even too big?

They consider it too big when viewing it from a decentralization point of view. Even at 1MB, mining is centralized, full node count continues to drop drastically every year, the recent fork revealed that majority of hashpower was SPV mining, meaning they were blindly building blocks without even checking if txns were valid! They consider decentralization the upmost important property of Bitcoin because that is the ONLY 1 thing that sets it apart from any other currency today. Their view is that once you lose decentralization, Bitcoin becomes just another currency, ie. vulnerable to manipulation, censorship, inflation like other currencies. With regards to too many txns for 1MB, they can all still work via offchain DBs like coinbase/changetip (just as much of the financial system functions today, only inter-bank settlements are cleared with the central bank) or more promisingly Lightning which has the added benefit of being trustless and instant confirmation.

In short, their view is that bitcoin should not risk decentralization to allow onchain txns for everyone and everything. All of that can be done on higher layers.

[Lauda]

They consider decentralization the upmost important property of Bitcoin because that is the ONLY 1 thing that sets it apart from any other currency today.
-snip-
In short, their view is that bitcoin should not risk decentralization to allow onchain txns for everyone and everything. All of that can be done on higher layers.

You're trying to tell me that Bitcoin is a decentralized, government issued currency?   Your post has too much wrong in it and I'm afraid that if we try to discuss it, we would start going off topic.
Mining won't be more centralized if the blocksize is 1, 2, 4, X MB. I just do not see the correlation there. The node count will increase once pruning is fully implemented, however the number of full nodes will be reduced.

Consensus is WAY more important than whatever particular solution it's gonna be.

Increasing blocksize now, increasing blocksize gradually over time in the near future, lowering the average block time, all fine with me. Bitcoin should remain functional like it has been the past 6.5 years.

People can be easily manipulated into consenting to the wrong solutions. I do agree that consensus is important, but not that much over a valid solution.

[flix]

With regards to too many txns for 1MB, they can all still work via offchain DBs like coinbase/changetip (just as much of the financial system functions today, only inter-bank settlements are cleared with the central bank) or more promisingly Lightning which has the added benefit of being trustless and instant confirmation.

In short, their view is that bitcoin should not risk decentralization to allow onchain txns for everyone and everything. All of that can be done on higher layers.

I agree that decentralisation is important.

I agree that not all transactions need to be on-chain. There are other solutions. (Although off-chain txs just move the centralisation elsewhere)

However there has to be a meaningful percentage of on-chain txs. Otherwise you lose all the advantages of keeping Bitcoin decentralised and the Blockchain secure.

Also, once coin creation diminishes and miners need to be paid fees... the number of tx makes a huge difference on whether the fees remain competitive.

7 tps is ridiculously small. Only 604.800 txs per day. It was always a temporary limit.

If Bitcoin is to be used by millions of people, maybe not for paying coffee, but at least for online shopping.... we are going to need at least 10 million tx per day (115 tps). VISA peak rate is 4.000 tps.

[flix]

Right now miners are rewarded on average with 6 x 24 x 25 = 3600 BTC per day.
For 604.800 daily txs to equal that reward, fees would have to be 3600 / 604.800 = 0.006 BTC per tx.

However with bigger blocks... say at 100tps (14MB blocks):  3600/ 8.640.000 = 0.0004 BTC per tx.
Right now that's about $0.12 per tx. Too expensive for micropayments, but still competitive for almost anything else.

If the Bitcoin network wanted to be as popular as VISA, say in 10 years time... 4000 tps would mean 345 million txs per day capacity. That would mean 571MB blocks.

Even BIP101 would not get to 512MB blocks until 2028.


(On the plus side at 4000tps, even without full blocks, fees per tx would be tiny, smaller than $0.01 or BTC0.0000104).