Fixing Testnet4: proposal

[BayAreaCoins]

Edit:

Could someone just ask on the mailing list on the "Unbreaking testnet" email if the proposed date is still going to happen or if it is being pushed back(?)

Yes, I may send the message.

Stwenhao got an email in the list inquiring.  https://groups.google.com/g/bitcoindev/c/iVLHJ1HWhoU/m/XalE9M6TAgAJ

Thank you very much Saint.


Update

It also should be noted, that Testnet isn't broken... people just don't care for the game how the rules are set up.  Which everyone totally agrees isn't great, but if a play works... you can't expect a professional team not to run it.

That being said, the price of Testnet is very low due to this.  If that is the goal of Testnet, to keep it "free" or at least the prices low (because zero is basically impossible)... then perhaps letting these folks take that profit isn't terrible.

Technically, the Testnet coins are flowing into an active market at least with them.  The other miner is just stocking 1.2 million coins without a single txid... that's crazy bad, regardless if they are including transactions or not.  All the ASIC blocks confirm folks for now and it's just part of wait it out... welcome to crypto.

[BayAreaCoins]

For those who don't know, testnet4 is pretty much broken. CPU miners are taking advantage of the 20-min rule and there's very intense competition on who gets to broadcast the block faster. So intense, that some miners send empty blocks to gain that little advantage over bandwidth and verification time. A discussion started in the Bitcoin Development Mailing list, but it hasn't got anywhere: https://groups.google.com/g/bitcoindev/c/iVLHJ1HWhoU.

My proposal to fix testnet4 is to simply remove the 20-min limit after a certain epoch, months into the future, so that everyone has time to upgrade. Also, difficulty should also be decreased significantly after the epoch of that block (by around 5/6th) because around 5 in 6 blocks are CPU blocks, and by disabling CPU blocks, we should expect the block interval to increase significantly.

One good justification for this proposal is that the purpose of testnet is to mimic mainnet as closely as possible. It'd be good for devs to be able to mine testnet "for free", but this mindset has lead to these unintended consequences where you can't have the cake and eat it too. Having the illusion of "free mining" without the usability of a test network is far worse than having a usable test network where coins are just not free to mine.

What do you think?

Feedback please: https://github.com/bitcoin/bitcoin/compare/master...l0rdicon:bitcoin:testnet_4_fork

This should fork Testnet4 as described in the OP. 

[stwenhao]

https://github.com/l0rdicon/bitcoin/blob/testnet_4_fork/src/kernel/chainparams.cpp#L121

Code:

/**
 * Main network on which people trade goods and services.
 */
class CMainParams : public CChainParams {
public:
    CMainParams() {
        // ...

        // Deployment to disable minimum difficulty blocks (testnet4 only)
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].bit = 1;
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].nStartTime = Consensus::BIP9Deployment::NEVER_ACTIVE;
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].min_activation_height = 0;
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].threshold = 1916; // 95% for mainnet
        consensus.vDeployments[Consensus::DEPLOYMENT_NOMINDIFFICULTY].period = 2016;

Only changes in "class CTestNet4Params" are needed. Things from "CMainParams", "CTestNetParams", "SigNetParams", and "CRegTestParams" should be removed. Because you want to make changes only to testnet4, not to everything else.

https://github.com/l0rdicon/bitcoin/blob/testnet_4_fork/src/test/pow_tests.cpp#L213

Code:

/* Test that GetNextWorkRequired respects deploymentActiveDisablesMinDiff parameter */
BOOST_AUTO_TEST_CASE(get_next_work_deployment_disables_min_difficulty)
{
    //...
}

This is only "happy day scenario" test. You should also check, if all other networks still behave in the same way. Because you don't want to do the same changes on mainnet, or other networks. You want them only on testnet4.

https://github.com/l0rdicon/bitcoin/blob/testnet_4_fork/test/functional/feature_testnet4_nomindifficulty.py#L37

Code:

        # Note: Full testing of the hardfork activation requires:
        # 1. Mining blocks until the deployment activates (height 150000)
        # 2. Verifying that min-difficulty blocks are rejected after activation
        # 3. Verifying that difficulty can increase above minimum after activation
        # This is left as a future enhancement as it requires significant test infrastructure

It should be tested, before changes like that will be deployed. Also, there are some edge cases, that needs to be tested, for example: blocks with 0x1d00ffff difficulty should not be rejected, if the real network difficulty will ever naturally drop to that level.

Stwenhao got an email in the list inquiring.

Yes, but as you can see, it didn't change anything.

Testnet isn't broken... people just don't care for the game how the rules are set up

Exactly. People don't care, so I am quite surprised, that any changes are proposed to testnet4 at all. But good luck, maybe your code changes will be accepted, if some things will be improved (for example: testing edge cases, and making sure, that other networks, like mainnet, are left unchanged).

This should fork Testnet4 as described in the OP.

Maybe it will. Now I am trying to build it from the source code, and see, how it works. But judging by the code, it does more than that, for example it is trying to fork all other networks as well. And bugs like that should be fixed, before going further.

Feedback please

It would be easier, if there would be any Pull Request on GitHub. You don't have to submit it into Bitcoin Core instantly (also because it is not ready, and will be closed in the current, unfinished state), but you can start with creating a Pull Request from your own testnet_4_fork branch to your own master branch. That should be enough, to create a room on GitHub, where it could be commented, instead of doing that on bitcointalk.

Edit:

if a play works... you can't expect a professional team not to run it

It is interesting to know, what is the current overproduction of blocks in testnet4:

Code:

genesis_time=1714777860
current_time=1768560000
time_difference=current_time-genesis_time=53782140
blocks=time_difference/600=89636.9

It means, that the current testnet4 should now have around 90k blocks. But instead, it has around 120k blocks. Which means, that there are around 30k more blocks, than there should be, if we assume 10 minutes between blocks. Which also means, that the chain overproduced around 1.5 million tBTC4, because of dropping difficulty.

Edit: Checking testnet4 blocks with 20 minutes and 1 second delay:

Code:

$ cat testnet4.sh 
nonce=$(./bitcoin-cli -testnet4 getblockcount)
while [ 1 ]
do
  ./bitcoin-cli -testnet4 setmocktime $((1714777860 + nonce * 1201))
  ./bitcoin-cli -testnet4 generatetoaddress 1 tb1pfees9rn5nz 100000000
  echo nonce: $nonce
  ((nonce=nonce+1))
done

Of course, it requires enabling "setmocktime", and hacking Proof of Work, but it is doable:

Code:

[*] 2026-01-16T10:55:49Z (mocktime: 2026-08-15T23:30:59Z) UpdateTip: new best=398f2d2983be0e0706d7eccd42f1db241ff9a554dd2757e3f0aee2de447eb27f height=60000 version=0x20000002 log2_work=47.872721 tx=60001 date='2026-08-15T23:30:59Z' progress=0.002832 cache=8.2MiB(60000txo)
[*] 2026-01-16T10:55:49Z (mocktime: 2026-08-15T23:51:00Z) UpdateTip: new best=1b048e50a581aa10f41a6865cecdcdac8bcd16fffaf4b30266f2d49798ef975c height=60001 version=0x20000002 log2_work=47.872745 tx=60002 date='2026-08-15T23:51:00Z' progress=0.002832 cache=8.2MiB(60001txo)
[*] 2026-01-16T10:55:49Z (mocktime: 2026-08-16T00:11:01Z) UpdateTip: new best=919622182ed1e5e072205993ecbc7029d8bea7a2402538f126dec111825445e2 height=60002 version=0x20000002 log2_work=47.872769 tx=60003 date='2026-08-16T00:11:01Z' progress=0.002832 cache=8.2MiB(60002txo)
[*] 2026-01-16T10:55:49Z (mocktime: 2026-08-16T00:31:02Z) UpdateTip: new best=f8eb451f12f2e7a3b1609dde5ab59569d4b6ba4c8a7bf7efa0a192e5c5a32e21 height=60003 version=0x20000002 log2_work=47.872793 tx=60004 date='2026-08-16T00:31:02Z' progress=0.002832 cache=8.2MiB(60003txo)
[*] 2026-01-16T10:55:49Z (mocktime: 2026-08-16T00:51:03Z) UpdateTip: new best=9f10a9cc6b8b10bac1d880696a274d89e95ee2d4ff94269dc8fc8b801e63bbe9 height=60004 version=0x20000002 log2_work=47.872817 tx=60005 date='2026-08-16T00:51:03Z' progress=0.002832 cache=8.2MiB(60004txo)

Edit: Script for testing ASICs:

Code:

$ cat mining_asic.sh
#SHA-256("ASIC")=36e3041f1c69dc35d7e2d9de4dd0d5b85fd8d324edbdd9860c25b0c7395b9283
#pubkeyASIC=02AEBBD0364EB984A03BEF1F58C516B1D671657CA50E50E069E77823ED3FD833AF
#addressASIC=tb1qxulcd7nf9t94xr0v3sncjjwmfs7pu75vwr8wpa
nonce=0
while [ 1 ]
do
  blocks=$(./bitcoin-cli -testnet4 getblockcount)
  blockhash=$(./bitcoin-cli -testnet4 getblockhash $blocks)
  mediantime=$(./bitcoin-cli -testnet4 getblock $blockhash | grep "\"mediantime\"" | grep -oE "[0-9]+")
  ./bitcoin-cli -testnet4 setmocktime $mediantime
  ./bitcoin-cli -testnet4 generatetoaddress 1 tb1qxulcd7nf9t94xr0v3sncjjwmfs7pu75vwr8wpa 100000000
  echo nonce: $nonce
  ((nonce=nonce+1))
done

And CPUs:

Code:

$ cat mining_cpu.sh 
#SHA-256("CPU")=db9a4c7d4c195ebf80068dd04120accce1cbfbef342bb43a53cbd651eb96e37b
#pubkeyCPU=03EC894061108F01125A523BD4899F08019F0F88EE31853B03666DCE5878522916
#addressCPU=tb1qcc4ym9vgdu8ux0md2eqg5m4zctacpcexywrkzf
nonce=0
while [ 1 ]
do
  blocks=$(./bitcoin-cli -testnet4 getblockcount)
  blockhash=$(./bitcoin-cli -testnet4 getblockhash $blocks)
  blocktime=$(./bitcoin-cli -testnet4 getblock $blockhash | grep "\"time\"" | grep -oE "[0-9]+")
  ./bitcoin-cli -testnet4 setmocktime $((blocktime + 1201))
  ./bitcoin-cli -testnet4 generatetoaddress 1 tb1qcc4ym9vgdu8ux0md2eqg5m4zctacpcexywrkzf 100000000
  echo nonce: $nonce
  ((nonce=nonce+1))
done

Also, it can be nice to visually identify blocks with different target than 0x1d00ffff: https://github.com/stwenhao/bitcoin/pull/1/commits/09ed76f857623e0507e7ade3411416d93a8297e8

Then, ASIC blocks can be easily spotted in logs, if mining them will require for example five leading hex zeroes:

Code:

2026-01-16T12:23:55Z (mocktime: 2024-06-18T12:50:12Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T12:50:12Z) UpdateTip: new best=4f0d85e37d12d6093acee67f9d2ad79fedb925a6b6922303455be00088fac64e height=5060 version=0x20000002 log2_work=44.323883 tx=5061 date='2024-06-18T12:50:12Z' progress=0.002782 cache=0.8MiB(5068txo)
2026-01-16T12:23:55Z (mocktime: 2024-06-18T13:10:13Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T13:10:13Z) UpdateTip: new best=f7fcd73979cb49be701a02ab190548dcf041cc9c9411ff1fe9ebb960f56e8139 height=5061 version=0x20000002 log2_work=44.324165 tx=5062 date='2024-06-18T13:10:13Z' progress=0.002782 cache=0.8MiB(5069txo)
2026-01-16T12:23:55Z (mocktime: 2024-06-18T13:30:14Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T13:30:14Z) UpdateTip: new best=211b50dc1e288a8d6c199fa8f6c673f9a322c9b7d85f38a12603a8ca27a15f48 height=5062 version=0x20000002 log2_work=44.324446 tx=5063 date='2024-06-18T13:30:14Z' progress=0.002782 cache=0.8MiB(5070txo)
2026-01-16T12:23:55Z (mocktime: 2024-06-18T13:30:14Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T11:50:09Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T11:50:09Z) UpdateTip: new best=000009a9704a27f6455a62d260c12dc154bead1aded33f93f7ec3a6e4db5815f height=5063 version=0x20000002 log2_work=44.324760 tx=5064 date='2024-06-18T11:50:10Z' progress=0.002786 cache=0.8MiB(5071txo)
2026-01-16T12:23:55Z (mocktime: 2024-06-18T11:50:10Z) CreateNewBlock(): block weight: 892 txs: 0 fees: 0 sigops 400
2026-01-16T12:23:55Z (mocktime: 2024-06-18T11:50:10Z) UpdateTip: new best=00000a054939f531212cb881540d84b669e401d464682241d89678da170cc97f height=5064 version=0x20000002 log2_work=44.325073 tx=5065 date='2024-06-18T11:50:11Z' progress=0.002786 cache=0.8MiB(5072txo)

Edit: Deployment after block 150,000 seems to work:

Code:

[*] 2026-01-16T12:59:53Z (mocktime: 2028-03-12T00:54:56Z) UpdateTip: new best=0000036b5c6a5141dbb88999060cf6186d49c3471ed6a8e6325b1c5bb17af574 height=153500 version=0x20000000 log2_work=49.260734 tx=153501 date='2028-03-12T00:54:57Z' progress=0.004351 cache=20.1MiB(153500txo)
[*] 2026-01-16T12:59:53Z (mocktime: 2028-03-12T00:54:56Z) UpdateTip: new best=00000a620a71c04dd45ef7cca86cf252edde48d9f01b46525261d4b2beec47ed height=153501 version=0x20000000 log2_work=49.260751 tx=153502 date='2028-03-12T00:54:57Z' progress=0.004351 cache=20.1MiB(153501txo)
[*] 2026-01-16T12:59:53Z (mocktime: 2028-03-12T00:54:56Z) UpdateTip: new best=00000ff9c4089baf25c12054bbfe97c6663909967a182c5b96755c4146d1f9c7 height=153502 version=0x20000000 log2_work=49.260767 tx=153503 date='2028-03-12T00:54:57Z' progress=0.004351 cache=20.1MiB(153502txo)
[*] 2026-01-16T12:59:53Z (mocktime: 2028-03-12T00:54:56Z) UpdateTip: new best=0000052806339b70b094dca8d884b4ae623b320c0fb78ae705b5527469e8e5fd height=153503 version=0x20000000 log2_work=49.260783 tx=153504 date='2028-03-12T00:54:57Z' progress=0.004351 cache=20.1MiB(153503txo)
[*] 2026-01-16T12:59:54Z (mocktime: 2028-03-12T00:54:56Z) UpdateTip: new best=00000ce9283cd8966cb1fc583c392d2e76a355124ae3edc63d7d0b92e7501efe height=153504 version=0x20000000 log2_work=49.260799 tx=153505 date='2028-03-12T00:54:57Z' progress=0.004351 cache=20.1MiB(153504txo)

ASIC miner can continue mining, while CPU miner returns an error:

Code:

nonce: 50
error code: -1
error message:
TestBlockValidity failed: bad-diffbits, incorrect proof of work
nonce: 51
error code: -1
error message:
TestBlockValidity failed: bad-diffbits, incorrect proof of work
nonce: 52
error code: -1
error message:
TestBlockValidity failed: bad-diffbits, incorrect proof of work
nonce: 53
error code: -1
error message:
TestBlockValidity failed: bad-diffbits, incorrect proof of work
nonce: 54
error code: -1
error message:
TestBlockValidity failed: bad-diffbits, incorrect proof of work

However, if you want to make it a soft-fork, instead of a hard-fork, then maybe it is a better idea to just ban block times, which are bigger than 20 minutes (except difficulty adjustments, where the real network difficulty is always enforced). Because then, if you will have hashrate majority on your side, making a soft-fork, instead of a hard-fork, will keep you in the same network (which means, that then, there will be no split between testnet4 and testnet5, if done correctly).

[BlackHatCoiner]

Only changes in "class CTestNet4Params" are needed. Things from "CMainParams", "CTestNetParams", "SigNetParams", and "CRegTestParams" should be removed. Because you want to make changes only to testnet4, not to everything else.

I agree. Also, I don't think it will ever be merged if it contains a lot of code. I have forked Bitcoin Core latest version and pushed some changes that should do the work by modifying only testnet4, with simple code changes: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix

I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default in consensus/params.h, only ever used by the CTestNet4Params class. GetNextWorkRequired and PermittedDifficultyTransition are also modified to check whether min difficulty blocks are enabled, and if yes, whether nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not testnet4). Tell me what you think.

[BayAreaCoins]

Only changes in "class CTestNet4Params" are needed. Things from "CMainParams", "CTestNetParams", "SigNetParams", and "CRegTestParams" should be removed. Because you want to make changes only to testnet4, not to everything else.

I agree. Also, I don't think it will ever be merged if it contains a lot of code. I have forked Bitcoin Core latest version and pushed some changes that should do the work by modifying only testnet4, with simple code changes: https://github.com/bitcoin/bitcoin/compare/master...batmanbytes:bitcoin:testnet4-fix

I have introduced int nMinDifficultyBlocksForkHeight which is 0 by default in consensus/params.h, only ever used by the CTestNet4Params class. GetNextWorkRequired and PermittedDifficultyTransition are also modified to check whether min difficulty blocks are enabled, and if yes, whether nMinDifficultyBlocksForkHeight is 0 (which would indicate it is not testnet4). Tell me what you think.

I agree with both.  Less code is better, and it definitely shouldn't mess with anything else except the desired target (Testnet4).

Saint, thanks for taking the time to make your post.  I've forwarded this on to Xploited (l0rdicon).

Thanks fellas.  We will get there.


Saint, Blackhat, or whoever, I don't figure you'd be interested in making a pull request, would you?  I'd tip.  (I don't code)

I figure no, but it's for sure no if I don't ask.  I definitely don't belong in that arena and barely squeeze in on Bitcointalk IMO.


Also,  with POW "we" (people that agree on a rule change) don't actually have to have Core merge anything, do we?  We just need 80% of 2016 blocks to pass a new rule... as I understand(?)

Feels rude, obviously, but an option nevertheless(?)

It's an interesting test.