I added unit tests that test the modified functions in isolation. Check my changes again.
Testnet4 fork behavior (4 tests):
1. testnet4_min_difficulty_pre_fork: At height 149,999, min-difficulty blocks ARE allowed (returns powLimit when block is >20min late)
2. testnet4_min_difficulty_at_fork: At height 150,000, min-difficulty blocks are NOT allowed (returns previous difficulty instead)
3. testnet4_min_difficulty_post_fork: At height 150,001, min-difficulty blocks are NOT allowed.4. testnet4_permitted_difficulty_transition: PermittedDifficultyTransition() is permissive before fork, strict after.
Other chains unaffected (3 tests):
5. regtest_min_difficulty_unaffected: Regtest still allows min-difficulty at any height (nMinDifficultyBlocksForkHeight=0 means no fork)
6. mainnet_min_difficulty_unaffected: Mainnet unaffected (fPowAllowMinDifficultyBlocks=false)
7. Existing ChainParams_TESTNET4_sanity already verifies basic testnet4 param sanity.
Running the proof-of-work tests, I get no errors detected: If you have any other unit tests in mind, let me know, but I think those are enough.
- Also, rejecting all blocks with CPU difficulty would mean, that the updated network will be stuck from time to time, when ASIC miners will come in, raise the difficulty, and then go away, leaving the rest of the users with halted chain.
The network is already in a halted chain, because empty blocks are propagated faster than non-empty, and transactions are confirmed most often when ASIC miners include them in their blocks. When ASIC miners go away with the current model, the users will have to wait for a much longer time, due to empty blocks.