WIP: Feature/8.22.0

[gto90]

No description provided.

[SmartArray]

All four GitHub Actions finally ran through 🎉🥳

🔥 This is a huge milestone for this pull request (PR) 🔥

However, the PR is not fully finished yet. We have a bunch of things to test thoroughly and several changes to consensus critical parameters to double check.
Throughout the last weeks, while I was working on this PR, I noted down a bunch of different things that are critical to this release:

• TODO-001: Several deployments were moved to buried deployments. New values for the activation block heights were chosen by myself by looking up block heights in the block explorer. Example commit: JaredTate@3c7a7d3
  Required steps:

  • Validate that chosen block height for DEPLOYMENT_CSV and DEPLOYMENT_NVERSIONBIPS (4164302) was chosen correctly
  • Validate that chosen block height for DEPLOYMENT_SEGWIT (4394880) was chosen correctly
  • Validate that chosen block height for DEPLOYMENT_RESERVEALGO (7550000) was chosen correctly
  • Perform a full sync and validate that the node syncs to 100% without rejecting any blocks that have new versions active

• TODO-002: Throughout fixing the automated unit tests for Qt we noticed that the current fee model for DigiByte needed special care. The commit JaredTate@4c03608 increases the incremental relay fee for replacement transactions (BIP 125) by 200x that was required for Rbf. This shouldn't have an impact at all since Rbf is disabled for DigiByte currently.
  Required steps:

  • Discuss whether Rbf shall remain disabled for the next release. Due to the small block time it is unlikely we will enable Rfb at all.
  • Create a bunch of transactions using digibyte-tx and digibyte-qt, validate the calculated fee is still correct and transactions will not be rejected by the network

• TODO-003: Validate that digibyte-qt is working properly.
  Required steps:

  • Ensure digibyte-qt shows the correct DigiByte network parameters
  • Ensure digibyte-qt is not crashing when sending a regular transaction

• TODO-004: The bitcoin upstream changes caused a big refactoring of internal classes, etc. This forced us to reintegrate Dandelion-specific code, which might have broken Dandelion.

  • Validate Dandelion is really disabled when using -disable-dandelion arg and non-dandelion transactions can be crafted and broadcasted
  • Validate Dandelion is enabled (i.e. dandelion thread is starting) when not specifying -disable-dandelion arg
  • Validate Dandelion is enabled and correctly broadcasting a dandelion transaction (observe logs!!). Ensure that the transaction eventually transitions from the stempool into the real mempool.
  • Validate Dandelion is enabled but normal transactions are still possible

• TODO-005: Similar to TODO-004 we need to validate MultiAlgo is working properly

  • A full sync will already show that MultiAlgo is still working, as it would reject blocks if not working properly.
  • Try to submit malicious blocks and ensure they are properly rejected by the network (wrong high-hash)
  • Use a real Odocrypt miner to mine a block in testnet. An attempt to mine N consecutive blocks should show the adapting difficulty.
  • Use a real Odocrypt miner to mine a block in mainnet

• TODO-006: During the merge, Taproot (🚀) was introduced into our codebase. The unit tests already validate that taproot is working as expected.
  Required steps:

  • Alter and validate activation parameters (https://github.com/JaredTate/digibyte/blob/eaeadc657b49d39a71b21cbb1fa9d61a028cff55/src/chainparams.cpp#L157)
  • Perform testnet sync and ensure that taproot is disabled before reaching the desired block height, and activated after reaching it.

• TODO-007: DigiByte Signet has been added. Validate signet parameters.

• TODO-008: Perform a fresh sync in DigiByte Testnet. Ensure that no crashes, no weird warnings and no unexpected behavior occurs.

• TODO-009: Perform a fresh sync in DigiByte Mainnet. Ensure that no crashes, no weird warnings and no unexpected behavior occurs. Ensure that the client is not forking.

Not saying this list is complete, but it should serve as a perfect starting point.

When most of the tasks are completed, we could soon start the review and aim at an eventual approval.
From that point, we need to double test everything is working properly, add possibly create release candidates and finally distribute signed releases.

Theoretically, we can work on integrating additional features (sync improvements, new mining algorithms?) before creating an official release.

[JaredTate]

Tested ACK. Let's get this 8.22.0 branch open under Digibyte-core so we can get others involved & testing, working on issues. This PR is currently passing all tests, and 4 gitflow tests we set up. But as @SmartArray said there is still a lot to be done.

Also, trying to add this review keeps crashing my browser with such a massive PR or single browser page. For anyone who can't get comments in, just hit accept review and then come back and edit it after.

[gto90]

ACK, I concur that we should merge this to the feature branch and invite the community to begin working on the TODO list proposed by @SmartArray above against that feature branch.

[ycagel]

ACK. Great work to everyone that participated in this. Let's open it up to the community and keep testing and checking off items on the TODO list.

[SmartArray]

ACK.

Sorry it took me so long, 2010 files were a bit much.

Looking forward to get this release perfect