Unbreaking testnet4

In a recent discussion on the Bitcoin Development Mailing List, Antoine Poinsot offered insights into the challenges developers face when attempting to mine on their own laptops using testnet4. He explained that the conventional method for mining with limited resources involves adjusting the computer's clock forward by 20 minutes or employing faketime. This adjustment causes the network difficulty to drop to its lowest level, allowing for the mining of blocks, including non-standard transactions, which are then broadcasted to the network. This technique also serves as a strategy for acquiring more testnet coins without needing an ASIC or relying on faucets.

However, Poinsot pointed out that while this approach might have been somewhat viable on testnet3, it has become significantly less effective on testnet4. On testnet3, the reward for mining a block after height 4 million was less than 10k sats, making the effort scarcely worthwhile. In contrast, testnet4 offers a substantial increase in block rewards, dispensing 50 tBTC per block, which has led to a surge in mining activity. Consequently, many CPU miners have begun mining multiple blocks by repeatedly advancing their clocks, not just once but several times in succession, until they encounter the restriction placed by other nodes on how far into the future a block can be, capped at two hours.

This aggressive mining tactic results in immediate complications for developers aiming to mine a single non-standard transaction. Given that the network's tip is constantly set around two hours ahead, any attempt to mine atop this by further advancing the clock would lead to rejection from peer nodes. Therefore, the utility of CPU mining for non-standard transactions on testnet4 is essentially nullified as long as this behavior continues.

Poinsot concludes by reflecting on the fundamental differences between testnet and mainnet environments. He notes that testnet will never accurately replicate the mainnet due to its inherently low or negligible value, leading to distinct behaviors and incentives. As such, dedicating time to address these issues might not be the best allocation of resources, suggesting a possible shift away from complexity in code related to testnet environments.