Increase DEFAULT_BLOCK_MAX_SIZE to 1MB #7622

pull hikari-no-yume wants to merge 1 commits into bitcoin:master from hikari-no-yume:increaseDefaultBlockSize changing 1 files +1 −1
  1. hikari-no-yume commented at 6:49 pm on February 29, 2016: none

    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!

  2. Increase DEFAULT_BLOCK_MAX_SIZE to 1MB e067dbef38
  3. hikari-no-yume commented at 6:51 pm on February 29, 2016: none
    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.
  4. luke-jr commented at 7:00 pm on February 29, 2016: member
    NACK, regardless of what we do with the block size limit, the actual block sizes should be smaller, not larger.
  5. hikari-no-yume commented at 7:02 pm on February 29, 2016: none
    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.
  6. sandakersmann commented at 7:57 pm on February 29, 2016: contributor
    ACK
  7. mr-e- commented at 8:13 pm on February 29, 2016: none
    “the actual block sizes should be smaller” - citation required
  8. chriswheeler commented at 8:19 pm on February 29, 2016: contributor
    ACK
  9. bitcartel commented at 8:38 pm on February 29, 2016: none
    @luke-jr Why should block sizes be smaller? Please explain.
  10. chriswheeler commented at 9:12 pm on February 29, 2016: contributor
    @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?
  11. jameshilliard commented at 10:26 pm on February 29, 2016: contributor
    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.
  12. krisives commented at 11:07 pm on February 29, 2016: none
    @TazeTSchnitzel Make the request for BitcoinClassic. These guys have different goals for Bitcoin than creating a p2p exchange system. Just move past them.
  13. luke-jr commented at 0:13 am on March 1, 2016: member
    @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.
  14. sandakersmann commented at 5:31 am on March 1, 2016: contributor
    The free market will win. I just can’t tell yet if it means replacing Core or Bitcoin.
  15. dcousens commented at 5:38 am on March 1, 2016: contributor

    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?

  16. jonasschnelli added the label Consensus on Mar 1, 2016
  17. laanwj commented at 12:59 pm on March 1, 2016: member

    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)

  18. laanwj added the label Mining on Mar 1, 2016
  19. laanwj removed the label Consensus on Mar 1, 2016
  20. laanwj commented at 1:07 pm on March 1, 2016: member

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

     0Running testscript prioritise_transaction.py ...
 1Initializing test directory /tmp/testlObaE6
 2start_node: bitcoind started, calling bitcoin-cli -rpcwait getblockcount
 3start_node: calling bitcoin-cli -rpcwait getblockcount returned
 4Assert that prioritised transasction was mined
 5Assert that de-prioritised transaction is still in mempool
 6Assertion failed: 
 7  File "/home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/test_framework/test_framework.py", line 135, in main
 8    self.run_test()
 9  File "/home/travis/build/bitcoin/bitcoin/bitcoin-i686-pc-linux-gnu/qa/rpc-tests/prioritise_transaction.py", line 80, in run_test
10    assert(high_fee_tx in mempool)
11Stopping nodes
12Cleaning up
13Failed
14Traceback (most recent call last):
15  File "qa/pull-tester/rpc-tests.py", line 261, in <module>
16    runtests()
17  File "qa/pull-tester/rpc-tests.py", line 161, in runtests
18    rpcTestDir + testScripts[i] + flags, shell=True)
19  File "/usr/lib/python2.7/subprocess.py", line 511, in check_call
20    raise CalledProcessError(retcode, cmd)
21subprocess.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.

  21. chriswheeler commented at 1:08 pm on March 1, 2016: contributor

    @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?

  22. MarcoFalke commented at 1:11 pm on March 1, 2016: member

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

    There is already some discussion about that in #3229

  23. AliceWonderMiscreations commented at 1:13 pm on March 1, 2016: contributor

    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.

  24. laanwj commented at 1:17 pm on March 1, 2016: member

    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.

  25. chriswheeler commented at 1:34 pm on March 1, 2016: contributor

    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?

  26. jtimon commented at 1:48 pm on March 1, 2016: contributor

    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.

  27. rebroad commented at 3:40 pm on March 1, 2016: contributor
    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.
  28. MarcoFalke commented at 10:17 am on March 28, 2016: member
    @TazeTSchnitzel Are you working on getting the unit test pass?
  29. hikari-no-yume commented at 5:29 pm on March 28, 2016: none
    I’m not, unfortunately.
  30. laanwj commented at 9:09 am on March 29, 2016: member
    May just pass after #7697, respinning travis.
  31. dcousens commented at 1:23 am on March 31, 2016: contributor
    Passes
  32. laanwj closed this on Jun 13, 2016
  33. MarcoFalke locked this on Sep 8, 2021


hikari-no-yume luke-jr sandakersmann mr-e- chriswheeler bitcartel jameshilliard krisives dcousens laanwj MarcoFalke AliceWonderMiscreations jtimon rebroad

Labels
Mining

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2024-10-30 03:12 UTC
This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me