[Qt]: fixes m_assumed_blockchain_size variable value #15183

pull marcoagner wants to merge 1 commits into bitcoin:master from marcoagner:fix_m_assumed_blockchain_size changing 1 files +2 −2
  1. marcoagner commented at 5:45 PM on January 16, 2019: contributor

    This is used by Qt but I'm not sure if this is the right tag here. Please, edit the title if there's something better.

    m_assumed_blockchain_size (src/chainparams.cpp:CChainParams) was BLOCK_CHAIN_SIZE (src/qt/intro.cpp) and while the transition was being made by PR 13216 (merged commit: 9d0e528), 3fc2063 changed its value from 200 to 220, which 9d0e528 ended up reverting.

    So, as per MarcoFalke's suggestion (https://github.com/bitcoin/bitcoin/pull/13216#discussion_r247560123), I'm bumping it to 240 before 0.18 is branched to avoid any confusion.

    Anything else (e.g. constexpr) that should/could be done here? Thanks.

  2. MarcoFalke added this to the milestone 0.18.0 on Jan 16, 2019
  3. MarcoFalke commented at 6:44 PM on January 16, 2019: member

    Tagging 0.18, this should be done prior to a major release: https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#release-process

    Bump testnet as well?

  4. laanwj added the label GUI on Jan 16, 2019
  5. laanwj commented at 10:21 AM on January 17, 2019: member

    Yes, probably best to do this just before branching off 0.18, to have the most up-to-date number.

  6. marcoagner commented at 11:19 PM on January 17, 2019: contributor

    I will then keep this open (if there's no problem, ofc) and rebase it just before branching with the fix/bump of m_assumed_blockchain_size for both mainnet and testnet. Thanks.

  7. laanwj commented at 12:11 PM on January 22, 2019: member

    Sounds good to me!

  8. laanwj renamed this:
    [Qt]: fixes m_assumed_blockchain_size variable value:
    [Qt]: fixes m_assumed_blockchain_size variable value
    on Feb 6, 2019
  9. laanwj commented at 6:12 PM on February 6, 2019: member

    FYI planned split-off date for the 0.18 branch is 2019-03-01, if you have time please update it on that date or a few days before that

  10. MarcoFalke commented at 7:09 PM on February 6, 2019: member

    I think this can be done right now, we have to add an overhead anyway. Being off by one GB either way won't hurt.

  11. marcoagner commented at 11:48 AM on February 7, 2019: contributor

    Thank you for the heads up. I'll be able to update this in a few days when I come back home and access my full node drives to check the exact values plus overhead by myself. (unless somebody suggests one right now, ofc - which happens to be most of the work here haha)

  12. Sjors commented at 12:32 PM on February 11, 2019: member

    Concept ACK. Maybe also add any useful commands to the release process doc.

  13. laanwj commented at 12:45 PM on February 12, 2019: member

    Being off by one GB either way won't hurt.

    Also good point. You'll want to round up anyhow.

  14. MarcoFalke commented at 10:21 PM on February 12, 2019: member

    ACK bd2893be508950d7b47d5bc407c79ed13bfd814e (240GB seems fine, could also bump testnet?)

  15. promag commented at 11:26 PM on February 12, 2019: member

    Concept ACK.

    Maybe also add any useful commands to the release process doc @Sjors what do you mean?

  16. Sjors commented at 9:54 AM on February 13, 2019: member

    @promag I mean the release process doc could use instructions on how you actually calculate the size correctly.

  17. laanwj commented at 5:24 PM on February 13, 2019: member

    I simply take the size of a synced ~/.bitcoin and do nothing special to compute it. After all it's used as a guideline for how much space the user needs on their drive, not strictly just the blockchain. I agree documenting that would make sense.

  18. jonasschnelli commented at 1:54 AM on February 14, 2019: contributor

    Can we also bump Testnet within the same PR?

  19. fixes m_assumed_blockchain_size variables values:
    This commit was a fix to `m_assumed_blockchain_size` reverted from
    3fc2063's 220 to 9d0e528's 200 since work on 9d0e528 was being done in
    parallel and ended up reverting `m_assumed_blockchain_size`.
    
    This commits is now a intended to be a bump of
    `m_assumed_blockchain_size` for both mainnet and testnet for new
    reasonable values.
    8c3fdd3a6d
  20. marcoagner commented at 12:52 PM on February 14, 2019: contributor

    8c3fdd3a6d90256bd2d00e86562f4d451bfd9767 now bumps the variable for both mainnet and testnet. Testnet is now bumped to 30GB; any disagreement to this value?

    As for @Sjors's suggestion, it seems proper to document this in another PR (I can update the release process doc for this and open the PR, ofc).

  21. fanquake commented at 1:20 PM on February 14, 2019: member

    utACK 8c3fdd3

  22. MarcoFalke referenced this in commit 38989ab03f on Feb 14, 2019
  23. MarcoFalke merged this on Feb 14, 2019
  24. MarcoFalke closed this on Feb 14, 2019

  25. laanwj referenced this in commit 981ec9b817 on Sep 30, 2019
  26. sidhujag referenced this in commit 8ce6b10dce on Oct 2, 2019
  27. humbleDasher referenced this in commit 154e9c4b6e on Dec 5, 2021
  28. humbleDasher referenced this in commit 91310cf78a on Dec 15, 2021
  29. MarcoFalke locked this on Dec 16, 2021

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: 2026-04-21 18:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me