And the remaining blocks go to the high difficulty miners.
Yes, but not all of them. I can get a block or two per day, which is still quite good result, if you consider, that I didn't improve block propagation for blocks, mined after two hours.
The high difficulty was a flaw in testnet already
It is not a flaw. Quite the opposite: pushing time to the future, and CPU-mining blocks is "a flaw". But people decided to not patch it. However, high difficulty is just a consequence of testnet consensus rules. And the reset from testnet3 into testnet4 was not, because of difficulty. Actually, you can run the same tricks, to CPU-mine blocks in both testnet4 and testnet3. I also mined many CPU blocks in testnet3, so I know, that it works. But obviously, ASICs can rule both networks, as it was in the past. And in testnet4, once per 2016 blocks, it is guaranteed, that a single block will be mined by ASICs, so if you will have only CPUs in testnet4, then they will see, how the chain stops, when they encounter the nearest difficulty adjustment.
it looks like there's an ASIC mining 20 minutes ahead in the future too
It was inevitable. And it is good, because then, testing timewarp attacks will be easier. And you can always CPU-mine some stale blocks, and test everything you want. More than that: if you try to mine on top of ASICs blocks, then you have quite high chances of getting a block, if ASIC will not manage to do it in time (which is why I can still mine one or two blocks per day).
What's the point of making it impossible for actual developers to quickly mine some testnet coins?
The test network was never designed to be ruled by CPUs. If it would be, then you would have different challenges, for example:
https://mempool.space/testnet4/tx/4289097ca8ad4f63484b8e278fba5789ee2decbe453e988934c7f9dfe9537ed8Can you see, what I did here?
$ ./bitcoin-cli -testnet4 decodescript 82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
"asm": "OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
"desc": "raw(82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#y8swm8mh",
"type": "nonstandard",
"p2sh": "2N794vgkX9KyJqfFPtqB1jTUx7QwvZgurZr",
"segwit": {
"asm": "0 14253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
"desc": "addr(tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d)#swj9w4n7",
"hex": "002014253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
"address": "tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d",
"type": "witness_v0_scripthash",
"p2sh-segwit": "2N9LCwnfvYcCCtapo2E3hcTr1SqStuJTuMo"
}
}
You want CPU-mineable coins? Then try to apply OP_SIZE on DER signatures. If you have 56 bytes, then you have to use half of the generator, as the R-value (which means, that your private key will be known), and s-value of 60 bytes (which means, that the first four bytes would have to be zero, so you would need some mining, to get a valid signature here).
And note one more thing: if you have an ASIC, then you can always beat all CPUs, if you have a competition, based on Proof of Work. Because ASICs can just produce much more work, in much shorter time. So: ASIC domination on testnets is inevitable. But: you can still compete with network propagation, so this is the place, where you should focus.
And one more thing: CPU-mined block, even if mined by ASIC, can still be reorged with a CPU. Just be faster, and produce two blocks in a row. It sometimes happens, if you are lucky.
