Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: start DIP0024 from block 1, backport bitcoin#24527, bitcoin#23086 - fire up test chains by first block - 7/n #6325

Draft
wants to merge 8 commits into
base: develop
Choose a base branch
from

Conversation

knst
Copy link
Collaborator

@knst knst commented Oct 10, 2024

Issue being fixed or feature implemented

This PR is 7th in the achieving ultimate goal to activate old forks from block 1.
It helps to run unit and functional tests faster; it helps for platform's dev-environment to start faster.

What was done?

Prior work: #6187, #6189, #6214, #6225, #6269, #6275

This PR:

How Has This Been Tested?

Run unit, functional tests.

Breaking Changes

[regtest only] -dip8params, -bip147height are removed.

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone

@knst knst added this to the 22 milestone Oct 10, 2024
@knst knst changed the title feat: bury mn_rr fork - fire up test chains by first block - 7/n feat: bury mn_rr fork - fire up test chains by first block - 7/n Oct 10, 2024
@knst knst changed the title feat: bury mn_rr fork - fire up test chains by first block - 7/n feat: bury DIP0024 fork - fire up test chains by first block - 7/n Oct 11, 2024
@knst knst changed the title feat: bury DIP0024 fork - fire up test chains by first block - 7/n feat: start DIP0024 from block 1, backport bitcoin#24527, bitcoin#23086 - fire up test chains by first block - 7/n Oct 11, 2024
knst and others added 8 commits October 17, 2024 15:34
For current implementation it is not important when exactly fork happened
yet important to know when first rotating quorum formed
It is superseeded -testactivationheight=bip147@height
It is superseeded -testactivationheight=dip0008@height
…ckchain

fa4ca8d test: Add -testactivationheight tests to rpc_blockchain (MarcoFalke)

Pull request description:

  Suggested: bitcoin#22818 (comment)

ACKs for top commit:
  laanwj:
    Code review ACK fa4ca8d
  theStack:
    Concept and code-review ACK fa4ca8d

Tree-SHA512: 41304db1a15c0c705a9cc2808c9f1d7831a321a8a7948a28ec5d3ee1ed3da6a0ce67cd50c99a33aaed86830c59608eb6ffadbeaba67d95245c490f9b6c277912
5ce3057 test: set segwit height back to 0 on regtest (Martin Zumsande)

Pull request description:

  The change of `consensus.SegwitHeight` from 0 to 1 for regtest in bitcoin#22818 had the effect that if I create a regtest enviroment with  current master (or 23.x), and then try to load this chain with an older version (22.x), I get an InitError
  `Witness data for blocks after height 0 requires validation. Please restart with -reindex`
  and have to reindex because `BLOCK_OPT_WITNESS` is no longer set for the Genesis block and `NeedsRedownload()` in validation returns `true` with an older version.
  That might be a bit annoying for tests that use a shared regtest dir with different versions.

  If people think this is enough of an issue to be worth fixing, I think it should also make it into 23.x

ACKs for top commit:
  theStack:
    Concept and code-review ACK 5ce3057

Tree-SHA512: b0e89ff7fc953bc0ae929d2da44cde7149321d987fb4763934f6c9635d00d807129a50b459cc5e69e86bb1819e4b063b969486e8016a1cb8db8f905fa315653d
It can happen because now order of activation of hardforks v20, mn_rr, dip3
can be changed by using testactivationheight on Regtest and no more
guarantee about this assertions
@knst knst marked this pull request as draft October 17, 2024 16:08
@knst
Copy link
Collaborator Author

knst commented Oct 17, 2024

converted to draft because feature_llmq_simplepose.py is failing often on CI

Copy link

This pull request has conflicts, please rebase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant