Skip to content

Conversation

ux3257
Copy link
Contributor

@ux3257 ux3257 commented Aug 28, 2022

Update chain parameters for upcoming major release.
See doc/release-process.md and #24418 for review instructions.

fixes #25921

@maflcko maflcko added this to the 24.0 milestone Aug 29, 2022
@DrahtBot
Copy link
Contributor

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #24737 (Remove taproot chain param by MarcoFalke)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@ekzyis
Copy link

ekzyis commented Aug 30, 2022

Approach ACK 0d3f35d

Compared chain params with my local chains:

main

Compared m_assumed_blockchain_size and m_assumed_chain_state_size: ?

$ du -sh *
4,0K	banlist.dat
4,0K	banlist.json
4,0K	bitcoin.conf
4,0K	bitcoind.pid
450G	blocks
4,8G	chainstate
11M	debug.log
244K	fee_estimates.dat
7,0M	mempool.dat
4,0K	onion_v3_private_key
3,0M	peers.dat
4,0K	settings.json
$ python -c "print(450 * 1.1)"
495.00000000000006
$ python -c "print(4.8 * 1.1)"
5.28

Not sure where the difference of 1 to 496 for m_assumed_blockchain_size comes from but close, I guess.

Rounding 5.28 up would lead to 6 for m_assumed_chain_state_size.

Compared ChainTxData: OK

$ bitcoin-cli getchaintxstats 4096 00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd
{
  "time": 1661697692,
  "txcount": 760120522,
  "window_final_block_hash": "00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd",
  "window_final_block_height": 751565,
  "window_block_count": 4096,
  "window_tx_count": 6886667,
  "window_interval": 2353770,
  "txrate": 2.925802860942233
}

Compared nMinimumChainWork: OK

$ bitcoin-cli getblockheader 00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd
{
  "hash": "00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd",
  "confirmations": 310,
  "height": 751565,
  "version": 541065216,
  "versionHex": "20400000",
  "merkleroot": "d221de9319a48dc8556d7df26a4904fe187606c79609264bd66acbbbef1b94bf",
  "time": 1661697692,
  "mediantime": 1661693980,
  "nonce": 1083113272,
  "bits": "1709ed88",
  "difficulty": 28351606743493.77,
  "chainwork": "00000000000000000000000000000000000000003404ba0801921119f903495e",
  "nTx": 1404,
  "previousblockhash": "00000000000000000000f88dbf90c562b384e38b2df2b75c53f47d6abfd74781",
  "nextblockhash": "00000000000000000008ae3601b900bf442c108ccee05e8ddacb1c2fcc3f2928"
}

testnet3

Compared m_assumed_blockchain_size and m_assumed_chain_state_size: ?

$ du -sh testnet3/
32G	testnet3/
$ python -c "print(32 * 1.1)"
35.2
$ du -sh testnet3/chainstate/
1,5G	testnet3/chainstate/
$ python -c "print(1.5 * 1.1)"
1.6500000000000001

Why 42 for m_assumed_blockchain_size? I would have set it to 35 or 36. But maybe there is something wrong with my node, since the previous value was already 40. I did IBD from test net yesterday.

2 for m_assumed_chain_state_size is okay due to rounding up.

Compared ChainTxData: OK

$ bitcoin-cli getchaintxstats 4096 0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060
{
  "time": 1661705221,
  "txcount": 63531852,
  "window_final_block_hash": "0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060",
  "window_final_block_height": 2344474,
  "window_block_count": 4096,
  "window_tx_count": 122163,
  "window_interval": 1132062,
  "txrate": 0.1079119341520164
}

Compared nMinimumChainWork: OK

$ bitcoin-cli getblockheader 0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060
{
  "hash": "0000000000000004877fa2d36316398528de4f347df2f8a96f76613a298ce060",
  "confirmations": 306,
  "height": 2344474,
  "version": 754475008,
  "versionHex": "2cf86000",
  "merkleroot": "3455093eee84e11b115e724df0eb032fe7c50bf21c95a0b294cbac93713632d3",
  "time": 1661705221,
  "mediantime": 1661701618,
  "nonce": 773522042,
  "bits": "1939f2c0",
  "difficulty": 74116169.84175669,
  "chainwork": "00000000000000000000000000000000000000000000076f6e7cbd0beade5d20",
  "nTx": 73,
  "previousblockhash": "000000000000002dd614890d5ef76b5b9c43dda7b1b7689325545bf768f55a08",
  "nextblockhash": "0000000000000032370212d9daeafb6e6db7728716e53b2e273421b68240bf09"
}

@jonatack
Copy link
Member

Don't forget that this update should be reviewed with reindex-chainstate and assumevalid=0 to catch any issue causing rejection of blocks in the past history. I did it that for the last release and it took around 10 days on my laptop (2 x 2500 GHz), so if anyone plans to do it, don't hesitate to get started ;)

Copy link
Member

@Sjors Sjors left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tACK 767d825

Verified data using existing nodes and ran a full sync with -assumevalid=0 -minimumchainwork=00000000000000000000000000000000000000003404ba0801921119f903495e on a recent version of master now (and without checkpoints, for good measure, see #25725). Update, note to self: don't forget to set -dbcache to some big number if you don't want to wait forever.

Also ran a full sync on signet and testnet.

@@ -107,7 +107,7 @@ class CMainParams : public CChainParams {
pchMessageStart[3] = 0xd9;
nDefaultPort = 8333;
nPruneAfterHeight = 100000;
m_assumed_blockchain_size = 460;
m_assumed_blockchain_size = 496;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Between three machine I get 449, 451 and 459 GB for the blocks dir, using du -h (blocks + chainstate dir). Multiplied by 1.1 that would make between 494 and 505 GB. So based on the methodology used in 23.0 your pick of 496 looks correct to me.

The instructions are outdated compared to what @laanwj did last time.

/* nTxCount */ 712531200,
/* dTxRate */ 2.891036496010309,
// Data from RPC: getchaintxstats 4096 00000000000000000009c97098b5295f7e5f183ac811fb5d1534040adb93cabd
.nTime = 1661697692,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's indeed a nicer way to format this.

Copy link
Member

@achow101 achow101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

utACK 767d825


pchMessageStart[0] = 0x0b;
pchMessageStart[1] = 0x11;
pchMessageStart[2] = 0x09;
pchMessageStart[3] = 0x07;
nDefaultPort = 18333;
nPruneAfterHeight = 1000;
m_assumed_blockchain_size = 40;
m_assumed_blockchain_size = 42;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On my node, it's only 32 GB. With 10% buffer, that's only 35.2, so this probably doesn't need to updated?

$ du -h --exclude=wallets --exclude=indexes testnet3/                                                                                                  04:23:29 PM
188K	testnet3/database
335M	testnet3/blocks/index
30G	testnet3/blocks
1.5G	testnet3/chainstate
32G	testnet3/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also get 29G for the blocks, plus 0.5 for blocks/index. That's on a freshly synced node. Perhaps a node that went through many reorgs uses a bit more.

@maflcko maflcko merged commit 447f50e into bitcoin:master Sep 6, 2022
@bitcoin bitcoin locked and limited conversation to collaborators Sep 6, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Update chainparams pre 24.0 branch-off
7 participants