> I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01. You can do that in a soft-fork way. Just rejecting blocks with difficulty=1, and requiring always a block with the true network difficulty, is a valid soft-fork. To better see that, you can imagine, what would happen, if someone would apply difficulty adjustment rule on mainnet. Then, it would be possible to temporarily mine a block on a CPU, see it confirmed by your node (and rejected by the rest of the network), and then, when the next real block would appear, your client would automatically switch to a stronger chain (and then, those CPU-mined blocks would be truly worthless). So, I assume if you change "fPowAllowMinDifficultyBlocks" from "true" to "false", when block time will be greater than unix time "1767225600", then you will get a valid soft-fork. Non-upgraded clients could then still see some CPU-mined blocks, but they will disappear, if the hashrate majority will support your changes, and then old clients will automatically follow your chain. Also note that a single ASIC block can reorg a lot of CPU-mined blocks, so it is always guaranteed, that this change will be chainwork-compatible. wtorek, 18 marca 2025 o 22:24:49 UTC+1 Antoine Poinsot napisał(a): > Hi, > > Testnet4 was rolled out a year ago to address the shortcomings of > testnet3. One of those shortcomings was the difficulty reset creating > havoc. [0] In spite of this a similar rule was adopted for testnet4. [1] As > a result, testnet4 is similarly creating havoc. [2] > > The goal of testnet is to mimic the Bitcoin mainnet. This is why it is > useful to have in addition to a more control testing environment such as > Signet. > > The given rationale for a difficulty reset was to let developers > occasionally mine blocks on their laptop. But you cannot have your cake and > eat it too: either the network is permissionless (PoW) or you assign > identities and privileges to some (Signet). By trying to do both at the > same time testnet4 created a loophole for abuse. As a result it failed on > both count: it neither mimics mainnet nor allows developers to mine active > blocks on their laptop. > > I propose to fix this by removing the difficulty reset rule from testnet4 > through a flag day hard fork on 2026-01-01. I picked a date well in the > future to minimize disruption. This leaves enough time for a patch to be > reviewed, merged, included in the next major Bitcoin Core release, > backported to previous releases and adopted by the infrastructure running > on testnet4. That should be enough for a test network. > > Let me know what you think, > Antoine > > [0] > https://gnusha.org/pi/bitcoindev/CADL_X_eXjbRFROuJU0b336vP...@mail.gmail.com > > [1] > https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#rule-specification > [2] https://fork.observer - pick the network on the top right corner > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f0cace2b-d734-4b36-b8a1-d4364a573a19n%40googlegroups.com.