Increase DEFAULT_BLOCK_MAX_SIZE to 1MB

[hikari-no-yume]

Currently, the maximum block size in Bitcoin Core is 1,000,000 bytes, or 1,000kB. There's been considerable debate about whether, how and when that limit should be raised. However, that is not the subject of this pull request.

Rather, this pull request concerns the maximum block size that miners will produce by default, which is 750kB. Unless the configuration is changed, a miner using Bitcoin Core will not produce blocks greater than this size, meaning that 250kB of potential block capacity will not be used.

While this might have been a reasonable default value in the past, it is now problematic. Bitcoin's average block size has been steadily increasing and now usually surpasses 750kB. This means that miners which use the default block size pull down the number of transactions the Bitcoin network can process at once, increasing backlogs and making transactions slower and more expensive to process, which is not desirable to any party.

Now, almost all miners override this setting and go for a 1000kB maximum. However, a problem presents itself when miners upgrade their version of Bitcoin Core. This can sometimes result in them accidentally resetting this value, and starving the network of capacity. This is not a mere hypothetical situation, indeed it appears to have happened twice in the last week, with two of Bitcoin's largest mining pools, BTCC and Antpool having apparently started capping their blocks at 750kB. It is very likely this happened due to accidentally resetting their maximum block size value when upgrading their Bitcoin Core nodes.

So, I would encourage you to merge this to avoid further unintentional network congestion.

Thanks!

[hikari-no-yume]

I am aware that an identical proposal was rejected 9 months ago, but back then Bitcoin average block sizes had not yet reached their current level. At that time, miners hadn't yet decided to raise their block size cap, so if Bitcoin Core had decided to raise the limit, that would have been preëmptive action with no pressing need. In contrast, this time round block sizes are regularly surpassing the 750kB limit, so now we're actually catching up with where the miners have already gone.

[luke-jr]

NACK, regardless of what we do with the block size limit, the actual block sizes should be smaller, not larger.

[hikari-no-yume]

Ideally, sure. But currently block sizes are usually larger than 750kB, so keeping this limit means that mining nodes which don't change from the default configuration will starve the network of capacity.

[sandakersmann]

ACK

[mr-e-]

"the actual block sizes should be smaller" - citation required

[chriswheeler]

ACK

[bitcartel]

@luke-jr Why should block sizes be smaller? Please explain.

[chriswheeler]

@luke-jr you recently signed an agreement with a number of miners for Core to code up a 2MB hark fork after SW is ready. Do you expect to ACK that PR when it is ready?

[jameshilliard]

NACK, virtually all miners set many custom configuration options including this option, the only miners that are not likely to do so are p2pool miners and there are some issues with block sizes over 750kb still being worked out there. AFAIK every major mining pool already changes this value and I think it's a good idea to encourage miners to make conscious choices. In general it makes sense for miners to have a smaller block size unless they are sure they can handle a full 1MB without a significant orphan rate increase.

[krisives]

@TazeTSchnitzel Make the request for BitcoinClassic. These guys have different goals for Bitcoin than creating a p2p exchange system. Just move past them.

[luke-jr]

@chriswheeler I continue to expect sensible miners to make blocks smaller than 1 MB on average, even after the limit is raised, until such a time that either Bitcoin requires more or can safely handle more.

[sandakersmann]

The free market will win. I just can't tell yet if it means replacing Core or Bitcoin.

[dcousens]

NACK, regardless of what we do with the block size limit, the actual block sizes should be smaller, not larger.

How does that impact on the "maximum" block size as a default? On average the actual block sizes should still be smaller? Right?

Concept ACK?

[laanwj]

Welcome, you've chosen quite a difficult subject for your first pull request here. Default changes have turned out to be very controversial in proportion to what they accomplish. Certainly in this case, as most miners will override this anyway.

Now, almost all miners override this setting and go for a 1000kB maximum. However, a problem presents itself when miners upgrade their version of Bitcoin Core

Just curious: In what scenario does upgrading the software result in a reset of bitcoin.conf settings?

(edit: changed tag: this is not a consensus change but a mining setting)

[laanwj]

Travls error: This breaks the prioritise_transaction.py RPC test for some reason:

Running testscript prioritise_transaction.py ...
Initializing test directory /tmp/testlObaE6
start_node: bitcoind started, calling bitcoin-cli -rpcwait getblockcount
start_node: calling bitcoin-cli -rpcwait getblockcount returned
Assert that prioritised transasction was mined
Assert that de-prioritised transaction is still in mempool
Assertion failed: 
  File "/home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/test_framework/test_framework.py", line 135, in main
    self.run_test()
  File "/home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/prioritise_transaction.py", line 80, in run_test
    assert(high_fee_tx in mempool)
Stopping nodes
Cleaning up
Failed
Traceback (most recent call last):
  File "qa/pull-tester/rpc-tests.py", line 261, in <module>
    runtests()
  File "qa/pull-tester/rpc-tests.py", line 161, in runtests
    rpcTestDir + testScripts[i] + flags, shell=True)
  File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '/home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/prioritise_transaction.py --srcdir /home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/src --coveragedir /tmp/coveragenhmdIP ' returned non-zero exit status 1

It must be making an implicit assumption about the amount of transactions that will be included in a block.

[chriswheeler]

@krisives Classic already sets the soft limit to be the hard limit by default, miners are of course free to reduce that if they want to produce smaller blocks.

Having an arbitrary default (e.g. 750kb) implies a recommendation. It should either be MAX or Zero. Zero might cause miners to accidentally mine empty blocks, so max makes more sense to me.

What about not having a default and requiring miners to specify?

[maflcko]

What about not having a default and requiring miners to specify?

There is already some discussion about that in #3229

[AliceWonderMiscreations]

Not have a default would break existing implementations that don't specify.
Changing the default would alter how existing implementations that don't specify operate.

Both can result administrators being reluctant to upgrade. At least that has been my experience with other software where a change to code results in a change to the default operation of the software.

[laanwj]

What about not having a default and requiring miners to specify?

Right, these kinds of things have been discussed. See also #7464 (as well as the PR @MarcoFalke mentions).

Having an arbitrary default (e.g. 750kb) implies a recommendation. It should either be MAX or Zero. Zero might cause miners to accidentally mine empty blocks, so max makes more sense to me.

Philosophically I agree with not having mining defaults. However, explicitly having to set many options makes it harder for miners to set up a node, and the last thing we'd want to discourage is for miners to run their own node.

[chriswheeler]

In which case, the only sane/logical default is MAX (currently 1MB).

If this was a new option being added, would there be any reason for it to be 750K?

[jtimon]

If this was a new option being added, would there be any reason for it to be 750K?

It is the current default. Users (including miners) should use the configurable options with whatever values they prefer instead of constantly asking to change defaults.
There's also alternative releases that change defaults or policy code like http://luke.dashjr.org/programs/bitcoin-ljr/ : not all implementation need to share bitcoin core's relay/mining policy defaults or even have the same policy code.

[rebroad]

NACK - primarily because I defer judgement to @luke-jr who as a miner I assume has greater understanding of the impact of such a change, and also because from my perspective the current tx fees are still quite reasonable and I'd like to see the block-chain not growing unnecessarily faster than it needs to. As a side note, I do think that those who can demonstrate considerable investment in bitcoin should get more say on this than those who don't, so if a democratic aspect were to be invoked I would suggest it be one vote per bitcoin rather than one vote per person.

[maflcko]

@TazeTSchnitzel Are you working on getting the unit test pass?

[hikari-no-yume]

I'm not, unfortunately.

[laanwj]

May just pass after #7697, respinning travis.

[dcousens]

Passes