Requesting Testnet4 tBTC

[vjudeu]

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/4289097ca8ad4f63484b8e278fba5789ee2decbe453e988934c7f9dfe9537ed8

Can you see, what I did here?

Code:

$ ./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.

[LoyceV]

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.

I didn't really mean it on a technical level, I understand why the difficulty is high. The "flaw" is that other miners can make it very difficult for anyone to get testnet coins. It should be possible to get some testnet coins at any time when you need them, so there's no need to hoard them already.

you can always CPU-mine some stale blocks, and test everything you want.

That works on your local system, but won't allow you to interact with other testnet users.

Can you see, what I did here?

Nope, you've lost me.

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).

You've lost me even more.

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.

Do you mean you can mine >2h in the future, and then broadcast your own blocks at exactly the right time?

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.

Sounds like a challenge, but:

I have enough testnet4 coins to give them away until the end of days

I take it I did this at the right moment back then. If I'd try the same thing now, it wouldn't work.

[vjudeu]

Do you mean you can mine >2h in the future, and then broadcast your own blocks at exactly the right time?

Exactly. There is no way to tell, if you are a CPU miner, or an ASIC miner, if both blocks have minimal difficulty. And then, you can compete.

You've lost me even more.

If you have a regular signature, then it takes some bytes. If you put some Proof of Work into that, then you can make it smaller. If you check in the Script, if your signature has N bytes or less, then it requires grinding, to meet that condition. And even if all private keys are known, then still: your coins are safe, as long as nobody else will grind it faster.

More than that: you can have "signet-on-testnet", if you just put some signet challenge in your output script, and then require a signature, to contain less than N bytes. Then, signing is required, so nobody will sign those coins without permission, but also, Proof of Work will be needed, so it will be safe in a group of miners, with similar power. So, it will work more or less like Signet, but where you can peg testnet coins in and out, and where you can change signet challenge on the fly.

If I'd try the same thing now, it wouldn't work.

I guess you could mine a block or two per day, if you run your miner 24/7. As long as there is any ASIC, you can mine a block on top of that, because then, it brings us back to the past, and then, CPU mining is the easiest.

Another thing is that ASIC owners can reorg hundreds of CPU blocks, if they want. They just don't do that for some reason, but they are incentivized to do that, by testnet consensus rules.

[LoyceV]

Do you mean you can mine >2h in the future, and then broadcast your own blocks at exactly the right time?

Exactly.

So that's what this guy must be doing. He mined 58 out of the last 60 blocks (and that's where I stopped counting).

More interesting (and since there's no real Testnet4 topic yet I'll post it here) is that Testnet4 is now also being spammed. See mempool.space: blocks are full, and transaction fees are >1 tBTC already. It started by creating dust, followed by consolidating dust. That address has 1.39 million UTXOs.

I guess you could mine a block or two per day, if you run your miner 24/7. As long as there is any ASIC, you can mine a block on top of that, because then, it brings us back to the past, and then, CPU mining is the easiest.

I don't think that works anymore. From my logs (grep 'new best'):

2024-10-22T04:42:24Z UpdateTip: new best=000000000044e403d70ef10df0c336ebfa2cbaad21d0cbcb5ca7027e5f6d9609 height=51477 version=0x229e4000 log2_work=71.417351 tx=871704 date='2024-10-22T06:42:24Z' progress=1.000000 cache=198.4MiB(1534117txo)
2024-10-22T05:08:36Z UpdateTip: new best=00000000006c3f60920127e60a2e067dc8dab64ec527118460866b0357de4354 height=51478 version=0x27ea4000 log2_work=71.417351 tx=871747 date='2024-10-22T07:02:25Z' progress=1.000000 cache=198.4MiB(1519954txo)
2024-10-22T05:22:30Z UpdateTip: new best=000000000044e403d70ef10df0c336ebfa2cbaad21d0cbcb5ca7027e5f6d9609 height=51477 version=0x229e4000 log2_work=71.417351 tx=871704 date='2024-10-22T06:42:24Z' progress=1.000000 cache=198.4MiB(1534118txo)
2024-10-22T05:22:30Z UpdateTip: new best=0000000000b7a552308c0ac0986757c1172184b1709f5226727e536801b8344d height=51478 version=0x231a4000 log2_work=71.417351 tx=871747 date='2024-10-22T07:02:25Z' progress=1.000000 cache=198.4MiB(1519955txo)
2024-10-22T05:22:30Z UpdateTip: new best=0000000000e4de23973d7acee7ee3d7465c1c78ec036b675f0a9ea979ab9d91f height=51479 version=0x22e4a000 log2_work=71.417351 tx=871795 date='2024-10-22T07:22:26Z' progress=1.000000 cache=198.5MiB(1505787txo)
2024-10-22T05:42:27Z UpdateTip: new best=0000000000b7a552308c0ac0986757c1172184b1709f5226727e536801b8344d height=51478 version=0x231a4000 log2_work=71.417351 tx=871747 date='2024-10-22T07:02:25Z' progress=1.000000 cache=198.4MiB(1519956txo)
2024-10-22T05:42:27Z UpdateTip: new best=000000000026e3fd15c471dc0a46b2bdd38603b73f3d0b45376c38b8280bf2ff height=51479 version=0x21836000 log2_work=71.417351 tx=871795 date='2024-10-22T07:22:26Z' progress=1.000000 cache=198.5MiB(1505788txo)
2024-10-22T05:42:27Z UpdateTip: new best=0000000000558dc793c85bd9bdc60eb33ff94acb09cff8060a709da71419b90b height=51480 version=0x23d5e000 log2_work=71.417351 tx=871847 date='2024-10-22T07:42:27Z' progress=1.000000 cache=198.5MiB(1491617txo)
2024-10-22T06:02:28Z UpdateTip: new best=0000000000b0318cc674c27677722b6f74c8db6c2382966e961872ea84fb3645 height=51481 version=0x26f28000 log2_work=71.417351 tx=871892 date='2024-10-22T08:02:28Z' progress=1.000000 cache=198.5MiB(1477445txo)
2024-10-22T06:22:29Z UpdateTip: new best=00000000004f5c9a55b3795886c190f5ff5af478f39e95294131e68a03258a5c height=51482 version=0x25b60000 log2_work=71.417351 tx=871946 date='2024-10-22T08:22:29Z' progress=1.000000 cache=198.5MiB(1462869txo)
2024-10-22T06:42:30Z UpdateTip: new best=00000000001c421b622f908dd7546a0155dac688de02ba23a35668d33cbbc3a6 height=51483 version=0x25ffe000 log2_work=71.417351 tx=872021 date='2024-10-22T08:42:30Z' progress=1.000000 cache=198.5MiB(1448374txo)
2024-10-22T07:02:31Z UpdateTip: new best=00000000004f5c9a55b3795886c190f5ff5af478f39e95294131e68a03258a5c height=51482 version=0x25b60000 log2_work=71.417351 tx=871946 date='2024-10-22T08:22:29Z' progress=1.000000 cache=198.5MiB(1462870txo)
2024-10-22T07:02:31Z UpdateTip: new best=00000000004be984f053e43ae868f10b4250f58c1bedbce461d111a964a61ab6 height=51483 version=0x20036000 log2_work=71.417351 tx=872021 date='2024-10-22T08:42:30Z' progress=1.000000 cache=198.5MiB(1448375txo)
2024-10-22T07:02:31Z UpdateTip: new best=0000000000e9b14ef57f049ba151c1eb3ddea136d070a88d7be2e9f1b5d4c24a height=51484 version=0x2784a000 log2_work=71.417351 tx=872085 date='2024-10-22T09:02:31Z' progress=1.000000 cache=198.5MiB(1433909txo)
2024-10-22T07:22:32Z UpdateTip: new best=00000000004be984f053e43ae868f10b4250f58c1bedbce461d111a964a61ab6 height=51483 version=0x20036000 log2_work=71.417351 tx=872021 date='2024-10-22T08:42:30Z' progress=1.000000 cache=198.5MiB(1448378txo)
2024-10-22T07:22:32Z UpdateTip: new best=0000000000e6b794c363d9c210eefe0c74f20d91540cc280c0f48d58631eb22f height=51484 version=0x2300c000 log2_work=71.417351 tx=872085 date='2024-10-22T09:02:31Z' progress=1.000000 cache=198.5MiB(1433912txo)
2024-10-22T07:22:32Z UpdateTip: new best=00000000008de77e764dc602d58105ba93ca45ef9f1c71b211fd6de828e9397a height=51485 version=0x209b0000 log2_work=71.417351 tx=872134 date='2024-10-22T09:22:32Z' progress=1.000000 cache=198.5MiB(1419343txo)
2024-10-22T07:42:33Z UpdateTip: new best=0000000000e6b794c363d9c210eefe0c74f20d91540cc280c0f48d58631eb22f height=51484 version=0x2300c000 log2_work=71.417351 tx=872085 date='2024-10-22T09:02:31Z' progress=1.000000 cache=198.5MiB(1433914txo)
2024-10-22T07:42:33Z UpdateTip: new best=0000000000538588a2339b7728ac0f568c92c794b8e3d3f08c9179aea1109f00 height=51485 version=0x22f5c000 log2_work=71.417351 tx=872134 date='2024-10-22T09:22:32Z' progress=1.000000 cache=198.5MiB(1419345txo)
2024-10-22T07:42:33Z UpdateTip: new best=00000000003dc43e628b193b033c7c3c5171d9a05f55ecef031c63faa16ee790 height=51486 version=0x20848000 log2_work=71.417351 tx=872202 date='2024-10-22T09:42:33Z' progress=1.000000 cache=198.5MiB(1404802txo)

As you can see, any other "easy" miner gets their blocks replaced. It's as if someone has his blockchain on "read only" and ignores blocks from anyone else. That means no developer can mine a block for testing.

[garlonicon]

Testnet4 is now also being spammed

This network is slowly dying. It is traded at 20 real satoshis per 1 tBTC4, which means, that we are approaching testnet5. However, if new testnets will be started in exactly the same way as before, then it will be just an official pump and dump, signed by Bitcoin Core developers. And that means, the new testnet should have completely different rules (for example: all test coins should be stale, and disappear after a while).

I don't think that works anymore.

Well, it works in quite unexpected way: if there is more than a single CPU miner, then ASIC miners can pick different chains. And as a result, you can fork some ASICs off the network, if your blocks will contain future timestamps.

That means no developer can mine a block for testing.

Actually, you can mine many blocks. But: they will usually be reorged. If you have CPU block vs some other CPU block, then ASIC blocks decide, which chain is real. And also: ASICs can simply halt the chain, by not mining anything, then every CPU miner will be stuck at the next difficulty adjustment.

[BlackHatCoiner]

This network is slowly dying. It is traded at 20 real satoshis per 1 tBTC4

Where is this market?

which means, that we are approaching testnet5.

How is this going to be any different than testnet4? The way I understand the rationale is that we reset the network create a new network if acquiring coins in the current one is only practically possible by buying it. But, it's entirely possible to mine in here, I have mined several blocks a few months ago.

What's the technical addition that keeps the ASICs away in here?

[garlonicon]

Where is this market?

https://altquick.com/exchange/market/BitcoinTestnet3
https://altquick.com/exchange/market/BitcoinTestnet4

And if developers will create testnet5 with the same rules, then the same thing will happen:

1. Some people will build testnet5 from the source code, and mine it.
2. This exchange will list it, when it will be officially released.
3. People will start selling their CPU-mined coins.

And if you have for example 100k tBTC4, then selling them for 0.02 BTC is really profitable, if all of that is just CPU-mined.

But, it's entirely possible to mine in here, I have mined several blocks a few months ago.

Exactly: a few months ago. Now, you have mining pools, which can mine future blocks, so it is much harder to compete. But of course, you can mine a lot of blocks, and see, how they vanish after a while. Or: you can trick some other nodes to follow your chain, for example when some of them didn't apply timewarp rules. Or: CPU miners can increase the difficulty to the point, where it will take ASICs a lot of time, to mine a single block per difficulty adjustment, to unstuck the network.

What's the technical addition that keeps the ASICs away in here?

They are not "kept away". They are mining future blocks, and only then, they are mining with the real difficulty, when they run out of CPU blocks. Also, ASIC blocks now have future timestamps, to limit CPU-mined blocks.

But of course, if you have CPU difficulty, then you can reorg this block with just a CPU, so you have some chances. But obviously, ASIC blocks pick the chain, so they can ignore your fork, and build on top of their own chain, and then your chain will be reorged.

[LoyceV]

Testnet4 is now also being spammed

This network is slowly dying. It is traded at 20 real satoshis per 1 tBTC4, which means, that we are approaching testnet5.

There's no point in replacing it again if the same thing will happen.
Ideally, this should be possible:

The "flaw" is that other miners can make it very difficult for anyone to get testnet coins. It should be possible to get some testnet coins at any time when you need them, so there's no need to hoard them already.

the new testnet should have completely different rules (for example: all test coins should be stale, and disappear after a while).

Or infinite inflation, or doublings instead of halvings.... But that kinda defeats the purpose: testnet is supposed to be more or less equivalent to Bitcoin, so you can test things before using real coins. All those changes are not helping, and will probably create new problems: infinite inflation for instance can lead to infinite on-chain spam and very high transaction fees, which makes it unusable again.

Well, it works in quite unexpected way: if there is more than a single CPU miner, then ASIC miners can pick different chains. And as a result, you can fork some ASICs off the network, if your blocks will contain future timestamps.

I assume the block hashes with many zeros are ASIC blocks, right? If that's correct, testnet4 has barely any ASIC miners. Do I understand correctly that CPU mined blocks still add to the difficulty at the next difficulty adjustment?

Actually, you can mine many blocks. But: they will usually be reorged.

I'm not a developer, but if I want to test things, it's very nice if it's compatible with others. If the rest of the network doesn't recognize your blocks, you can't test things.

If you have CPU block vs some other CPU block, then ASIC blocks decide, which chain is real.

So a smart ASIC miner would also mine CPU blocks to get more blocks for the same hashrate?

ASICs can simply halt the chain, by not mining anything, then every CPU miner will be stuck at the next difficulty adjustment.

That doesn't help developers either.

it's entirely possible to mine in here, I have mined several blocks a few months ago.

It was possible....

1. Some people will build testnet5 from the source code, and mine it.
2. This exchange will list it, when it will be officially released.
3. People will start selling their CPU-mined coins.

My take: the old testnet (3) market is based on scarcity and blockchain spammers (I call anything Ordinal-related spam). Does that mean the testnet (4) market is based on future scarcity expectations? Hoarding while it's cheap to sell later?

if you have for example 100k tBTC4, then selling them for 0.02 BTC is really profitable, if all of that is just CPU-mined.

What if it's ASIC mined? Testnet shouldn't be competing with real Bitcoin for ASIC power.

mining pools, which can mine future blocks

Isn't this part of the problem? "Future blocks" shouldn't exist.

CPU miners can increase the difficulty to the point, where it will take ASICs a lot of time, to mine a single block per difficulty adjustment, to unstuck the network.

That answers my previous question.

ASIC blocks now have future timestamps, to limit CPU-mined blocks.

Isn't the solution to make testnet much less forgiving for inaccurate timestamps? NTP (Network Time Protocol) is very accurate, and I can't remember the time I manually had to adjust a computer's time. It's always correct, and all I adjust is my own local timezone. If someone doesn't use the correct time on his system, why not just reject their blocks?
I get why the "20 minute rule" is made, it makes total sense to drop the difficulty to 1 if it takes too long to mine the next block. But this should only happen if the last block was really 20 clock-minutes ago. I have no idea what unintended consequences such a change would have.

[BlackHatCoiner]

https://altquick.com/exchange/market/BitcoinTestnet4

Now I truly feel the 2010 vibes.  

I left my computer open for a couple of hours, and it solved blocks which are currently valuated for 50 cents each. Quite wild I'll say.

And if you have for example 100k tBTC4, then selling them for 0.02 BTC is really profitable, if all of that is just CPU-mined.

100k tBTC4 wouldn't take more than 5 days in my computer. Effectively, I would have converted a few dollars worth of electricity to $1200. I just can't believe it.

Now, you have mining pools, which can mine future blocks, so it is much harder to compete.

What's a "future block"? Another way to say reorg?

I can notice there is a problem. My cpuminer has mined several blocks in the last few minutes, but none of them has reached mempool.space's node: https://mempool.space/testnet4/address/tb1qh022086je57mu0klkyakdgcea5ywg300cp0ddy.

Edit: Someone sent me 0.016 tBTC4 the moment I posted. I cannot explain how this happened.

Edit #2: Someone has setup a bot that monitors this thread and funds it when a new address is posted. I really don't understand what's going on.

[garlonicon]

The "flaw" is that other miners can make it very difficult for anyone to get testnet coins. It should be possible to get some testnet coins at any time when you need them, so there's no need to hoard them already.

You can do it, if you apply testnet rules, on top of mainnet. Then, you mine some mainnet blocks on CPU, you do your tests, and then, your blocks are invalidated, so there is no chance, to get any value out of them. The whole concept is called "weak blocks", because you produce a regular block, in exactly the same way, as ASICs would, but you stop, after reaching some lower difficulty (for example equal to one, if you use your CPU).

Or infinite inflation

If coins will not be stale, then they will be traded anyway. Note that testnet4 is still below block number 210,000. Setting the block reward into 50 tBTC4 constantly, and disabling halvings, wouldn't change anything.

or doublings instead of halvings

Then, you will quickly go outside 21 million coins, so you will re-introduce Value Overflow Incident (or worse bugs). Also, as in the previous idea, we are still before the first halving, and it is very likely, that test coins will be traded sooner, than after 4 years, so any halving rules are irrelevant. Also note, that there are more testnet4 coins, but testnet3 is valued more, for example because the old chain is faster, and can confirm more spammy transactions per second.

testnet is supposed to be more or less equivalent to Bitcoin

If you want to reach mainnet conditions, then you should follow mainnet mempool. It is that simple. And you can produce weaker blocks, if you want to just test, if something is valid or not.

I assume the block hashes with many zeros are ASIC blocks, right?

Eight leading hex chars means 32 leading zero bits, so if you can see 8-9 zeroes at the beginning, then it is probably a CPU-mined block. But: you can always just check the difficulty, if it is 0x1d00ffff (CPU block) or not (ASIC block), and filter it by that.

If that's correct, testnet4 has barely any ASIC miners.

ASIC miners can also mine CPU blocks. And after 20 minutes, they are forced to do so, by consensus rules.

Do I understand correctly that CPU mined blocks still add to the difficulty at the next difficulty adjustment?

Exactly. If after one week, you have 2016 blocks, where 1008 blocks are CPU-mined, and 1008 blocks are ASIC-mined, then the difficulty should be the same (or almost the same). But it is doubled. Which means, that consensus rules push ASICs out, until reaching 10 minutes per block on average, no matter if it is 20-minute CPU block, or any-time ASIC block. Which means, that in the corner case, CPU miners can force ASICs to mine a single block per two weeks. But: in practice, there will be more ASIC blocks than that, because CPUs push block time 20 minutes forward, instead of 10 minutes, so it leaves some room for ASICs anyway (because for example if the average block time is 15 minutes, the difficulty will be decreased).

if I want to test things, it's very nice if it's compatible with others

It is compatible. Your blocks are valid. They appear in "getchaintips". They are just stale, but perfectly valid, and anyone can use "preciousblock", to pick your chain specifically, and mine on top of it.

If the rest of the network doesn't recognize your blocks, you can't test things.

If your blocks are not stale, then they are traded.

So a smart ASIC miner would also mine CPU blocks to get more blocks for the same hashrate?

Of course. After 20 minutes, they are forced to do so by consensus rules. But: it is more profitable, to just keep everything 2 hours in the future. And the best way is to have a long, local chain, and share things, that are within 2 hours window.

Does that mean the testnet (4) market is based on future scarcity expectations?

The price per coin was much higher in the past, but CPU miners just dumped it, when they sold something around 100k tBTC4.

Hoarding while it's cheap to sell later?

I don't think waiting is a good option, where the whole network can be resetted again soon. Also, testnet3 has higher price per coin than testnet4. And it will take some time, to reproduce the whole spam from testnet3 into testnet4.

What if it's ASIC mined?

Some blocks are ASIC-mined, some are CPU-mined. You can compare chainwork. Testnet3 has something around 2^75, testnet4 something around 2^70, and mainnet something around 2^95.

Testnet shouldn't be competing with real Bitcoin for ASIC power.

That's why I think all test coins should be just weak blocks, based on mainnet. But: people should try other ideas first, should see, how they fail, and then, maybe they will be convinced.

"Future blocks" shouldn't exist.

You can put any future timestamp you want inside your blocks, because sooner or later, clocks in other nodes will get there. Even if you mine mainnet coins, then still: nothing stops you from putting future timestamps. And if 51% of the mining power would set block times into 20 minutes intervals, instead of 10 minutes, then they could increase their domination for a while, and lower the network difficulty. Obviously, in that case, it will be lowered for everyone, so it will quickly increase again, when "honest" miners will use the current time. But still: putting future timestamps is profitable. Maybe not honest, but definitely profitable. In all networks, which share Bitcoin rules.

If someone doesn't use the correct time on his system, why not just reject their blocks?

Because when you download the history, then there is no way to tell, who put the right time in the past. You can judge it, if you witness it now. But if you have a history, then you can only view it in a way, which is relative to the current timestamp. Which means, that even if there would be a strict rule, to use the current time, with higher accuracy, then, you can still connect with some new node, and share a history with fake timestamps, because Proof of Work is the only protection in that case.

Also, a little inaccuracy is needed, because there are some delays, related to propagating blocks in the network. And if you make those rules too strict, then imagine losing a block, only because your time is different by one second, than in some other node. And imagine node A, rejecting your block (one second too far in the future, sorry, rejected), and then, node B, accepting your block (because now, one second elapsed, and it is correct).

But this should only happen if the last block was really 20 clock-minutes ago.

You can tell the current time here and now. But you cannot tell, if a block, mined one day ago, was honestly mined, or was it future-timestamped, or past-timestamped, for whatever reason.

[vjudeu]

What's a "future block"? Another way to say reorg?

You can check the current time now. And if your node is online, then you know exactly, in your logs, when you received a given block, and what time it declared. If it differs, then you can detect it, just by reading your "debug.log" file.

My cpuminer has mined several blocks in the last few minutes, but none of them has reached mempool.space's node

Exactly. The code, shared by Garlo Nicon, with 20 hours rule (instead of 2 hours rule) is now just a tool to fork other nodes out of the official chain. You can basically trigger a fork, at any time you want, and because you accept a wider range of block times, then you can just see more forks than usual. Surprisingly, some ASIC miners didn't even implement timewarp protections, so every time, when the difficulty is adjusted, you have a chance to fork some non-upgraded ASICs, for hundreds of blocks, if your chainwork is higher, than in the BIP-94 chain.

[LoyceV]

You can do it, if you apply testnet rules, on top of mainnet. Then, you mine some mainnet blocks on CPU, you do your tests, and then, your blocks are invalidated

That's going to be very difficult to send a test-transaction to, say, another developer.

It is compatible. Your blocks are valid. They appear in "getchaintips". They are just stale, but perfectly valid, and anyone can use "preciousblock", to pick your chain specifically, and mine on top of it.

It sounds so much more complicated than just "electrum --testnet" to receive a coin.

That's why I think all test coins should be just weak blocks, based on mainnet. But: people should try other ideas first, should see, how they fail, and then, maybe they will be convinced.

I've seen too many scams to think this is a good idea. If a coin pops up in someone's wallet, some people are going to get scammed if they're "weak" blocks.

Because when you download the history, then there is no way to tell, who put the right time in the past. You can judge it, if you witness it now. But if you have a history, then you can only view it in a way, which is relative to the current timestamp.

Good point. Satoshi really thought this through

Also, a little inaccuracy is needed, because there are some delays, related to propagating blocks in the network. And if you make those rules too strict, then imagine losing a block, only because your time is different by one second, than in some other node. And imagine node A, rejecting your block (one second too far in the future, sorry, rejected), and then, node B, accepting your block (because now, one second elapsed, and it is correct).

I was more thinking: now the difficulty drops to 1 if there is no block for 20 minutes. And the time can be up to 2 hours off. What if "no block"-time was more than the "time can be off"-time? Say 40 minutes and 30 minutes? That means normal difficulty mining will mine the large majority of blocks, and if they stop for some reason, difficulty 1 blocks can still continue.

Surprisingly, some ASIC miners didn't even implement timewarp protections, so every time, when the difficulty is adjusted, you have a chance to fork some non-upgraded ASICs, for hundreds of blocks, if your chainwork is higher, than in the BIP-94 chain.

That's kinda funny

[BlackHatCoiner]

I still don't understand how I am able to mine blocks if ASICs are dominating the network. Shouldn't difficulty rise exponentially?

You can check the current time now. And if your node is online, then you know exactly, in your logs, when you received a given block, and what time it declared. If it differs, then you can detect it, just by reading your "debug.log" file.

I understand that their timestamps are future, but I don't understand how this is relevant with my blocks getting rejected by other nodes. What's the difference with their Proof-of-Work?

[garlonicon]

That's going to be very difficult to send a test-transaction to, say, another developer.

Not that difficult, as you may think. For example: all nodes, which adopted my 20 hours rule, can see each other, even if they are detached from the rest of nodes.

I still don't understand how I am able to mine blocks if ASICs are dominating the network. Shouldn't difficulty rise exponentially?

1. You are mining blocks with CPU difficulty.
2. The difficulty is rising, but only for ASICs, that's why there are so many CPU-mined blocks. And then, the network reaches difficulty adjustment, and consensus forces everyone to mine with ASICs difficulty, so then, CPU miners are stuck, and ASICs can pick the right chain. That's why one of the latest difficulty adjustments took 4 hours, and not 10 minutes.

but I don't understand how this is relevant with my blocks getting rejected by other nodes

Your node accepts blocks, up to 20 hours in the future. The rest of the network accepts only 2 hours in the future. Each CPU-mined block pushes the current time 20 minutes forward. After six CPU-mined blocks, the network is waiting, and rejecting your future blocks.

So, your blocks are valid, but they are not accepted yet. And then, if you would broadcast your future blocks at the same time, as other nodes, doing it "honestly", then the first-seen-safe rule is applied, and sometimes they can win, but you can sometimes win, too, if you are just faster. And if you have this re-broadcasting implemented, then welcome to network propagation games!

What's the difference with their Proof-of-Work?

See block header. If the difficulty is set to 0x1d00ffff, then it is CPU-mined block, and you can challenge it with a CPU. If it is something different, then it is ASIC-mined block, and you need an ASIC, to reorg it.

And also, a single ASIC block can reorg a lot of CPU-mined blocks, and this is what developers will be doing in the future in programmatic way, through their new mining pools: https://github.com/bitcoin/bitcoin/pull/31117

[vjudeu]

I've seen too many scams to think this is a good idea.

Well, currently, testnet3 and testnet4 are just "official pump and dump coins", as Garlo Nicon said. If you will have any kind of "persistent chain", then it will be traded.

Also, receiving new coins in a coinbase transaction, should be suspicious enough. Because they have to mature for 100 blocks in the main network, and they will disappear from the test network, long before that. Not to mention, that no ASIC miner will follow the test chain, if the same power can be used for mainnet mining, and creating a stronger chain from scratch.

So, in practice, each test chain will consist of just one weak block, on top of some real mainnet chain. It is pointless to build a longer chain, because then, you will be mining on top of some block, which is invalid by definition (because of not meeting the mainnet difficulty).

Also, hashrate-based protection can be applied to any coins, even on mainnet, without any forks. For example, you have to grind 16 bits for each coin at this address: https://mempool.space/testnet4/address/tb1qk3endeq6x0xj4pjt4zwag8wf3a629rzqr8jxd7jnmlac902wa5ysqxm9wt (which means, that you need at least 2^17 hashes, to spend both coins, 2^16 distinct hashes for each input; because sighashes force signing the current input).

It sounds so much more complicated than just "electrum --testnet" to receive a coin.

If the new network will be built, with any new rules, then it could be called with "client --testnetN", and the rest could be handled by the client automatically. The "complicated" path, is what you need here and now, when nothing is built yet.

If a coin pops up in someone's wallet, some people are going to get scammed if they're "weak" blocks.

1. Any new coins will land inside a coinbase transaction, and will have only a single confirmation.
2. If any existing transaction will appear, it will be as safe, as any other zero-confirmation transaction.
3. If weak blocks will be used as a method of sharing mempools, then other ASIC miners could really pick those transactions, and make them real. The only "fake" thing is some testnet coinbase, with a single confirmation, which will always vanish. And only there, you can see any test coins. Everything else will be real, in the worst case, it can be only unconfirmed or non-standard (but always valid).

[LoyceV]

That's why one of the latest difficulty adjustments took 4 hours, and not 10 minutes.

Isn't that because many ASIC miners are stuck on the wrong chain? Because of this:

Surprisingly, some ASIC miners didn't even implement timewarp protections, so every time, when the difficulty is adjusted, you have a chance to fork some non-upgraded ASICs, for hundreds of blocks, if your chainwork is higher, than in the BIP-94 chain.

I'm tempted to compile that version again, just to see how long that different chain is.

And also, a single ASIC block can reorg a lot of CPU-mined blocks, and this is what developers will be doing in the future in programmatic way, through their new mining pools: https://github.com/bitcoin/bitcoin/pull/31117

How about the scenario in which there are no new ASIC blocks for a day, and CPU blocks continu as intended. Would those blocks all be invalidated once the next ASIC block is created?

[vjudeu]

Isn't that because many ASIC miners are stuck on the wrong chain?

No. It is because of this:

If after one week, you have 2016 blocks, where 1008 blocks are CPU-mined, and 1008 blocks are ASIC-mined, then the difficulty should be the same (or almost the same). But it is doubled. Which means, that consensus rules push ASICs out, until reaching 10 minutes per block on average, no matter if it is 20-minute CPU block, or any-time ASIC block. Which means, that in the corner case, CPU miners can force ASICs to mine a single block per two weeks. But: in practice, there will be more ASIC blocks than that, because CPUs push block time 20 minutes forward, instead of 10 minutes, so it leaves some room for ASICs anyway (because for example if the average block time is 15 minutes, the difficulty will be decreased).

I'm tempted to compile that version again, just to see how long that different chain is.

Let's see:

Code:

  {
    "height": 50964,
    "hash": "000000000a2d036b18198f795cee83b0dfe2ab4dc372bcc8cc2a4be32a7c3b16",
    "branchlen": 565,
    "status": "valid-fork"
  },
  {
    "height": 50944,
    "hash": "0000000000000aa8cc2837c40e584cb60f8eb6f5b055694d2600dd6eaaa6a668",
    "branchlen": 545,
    "status": "headers-only"
  },
  {
    "height": 50926,
    "hash": "00000000001f8051d1bca675e649570098bd018e82df17a4fba243e1c5ae1f94",
    "branchlen": 527,
    "status": "headers-only"
  },
  {
    "height": 50925,
    "hash": "00000000007331d3d4aac2d019a17cfd43ce125f135207bfa71ec915ad31833e",
    "branchlen": 526,
    "status": "headers-only"
  },
  {
    "height": 50924,
    "hash": "00000000001c329e13bdef05d3641470592bc9381c5ec0d12b37f15c8df70a7d",
    "branchlen": 525,
    "status": "headers-only"
  },
  {
    "height": 50923,
    "hash": "00000000004541baae59083f1e99be701a4031c74cab2f89c75feee92f89bac3",
    "branchlen": 524,
    "status": "headers-only"
  },
  {
    "height": 50922,
    "hash": "000000000021ae976d77590589bf5e80c582a4ae3693fbf4e4c0f9f28935eec4",
    "branchlen": 523,
    "status": "headers-only"
  },
  {
    "height": 50921,
    "hash": "00000000006ef1390c4fe995c32fa86f4495774e10ebafc28fd6f4f43602b0cc",
    "branchlen": 522,
    "status": "headers-only"
  },
  {
    "height": 50920,
    "hash": "000000000004a8393478109a8150599dc46f073add33ab7f78df891c308df1e1",
    "branchlen": 521,
    "status": "headers-only"
  },
  {
    "height": 50917,
    "hash": "00000000000f8d2b42eefe733238c96897fb2b9433747ede0d7d3d9a5e39e11a",
    "branchlen": 518,
    "status": "headers-only"
  },
  {
    "height": 50914,
    "hash": "0000000000c97ee7e42be796add774c6c16ce0e177eb621b9e97271e648a8d3f",
    "branchlen": 1,
    "status": "headers-only"
  },
  {
    "height": 50909,
    "hash": "0000000094b3d386ef94cf49d37cb029459770758e6482ee027385df741f7e7f",
    "branchlen": 510,
    "status": "valid-fork"
  },
  {
    "height": 50895,
    "hash": "00000000aa61c65763c734330a6af3579b715821b309f1fabf6133518d706575",
    "branchlen": 496,
    "status": "valid-headers"
  },
  {
    "height": 50895,
    "hash": "0000000000017bfbb6bcc490cef844c22187a8620b4d5ceb810dda905942b078",
    "branchlen": 496,
    "status": "valid-headers"
  },
  {
    "height": 50893,
    "hash": "000000000015cc08d3505b27493be16482ab774e1df01d31dcdf55b7914b0eef",
    "branchlen": 494,
    "status": "valid-fork"
  },

Would those blocks all be invalidated once the next ASIC block is created?

It depends on this particular ASIC. It can keep the whole chain, and reorg only "future blocks" (for example: the last six blocks, from the 2 hours future time window), or it can reorg everything. In general, ASIC difficulty is the true difficulty, and ASICs can rule this network. CPU-mined blocks are just an exception, which is present only in testnets. Even signet doesn't have that rule.

[BlackHatCoiner]

1. You are mining blocks with CPU difficulty.

Pardon me for asking, but is the source code most of us run in this place altered by you? Are you the one who set difficulty=0x1d00ffff (including the 20 hours rule) and distributed the source code? Are you testnet4 Satoshi, or did testnet4 began prior this alteration?

And if you have this re-broadcasting implemented, then welcome to network propagation games!

So how do I do that? Do I just let it run, and expect to stand lucky, or is there a constant re-broadcasting every few seconds that takes place, which gives me advantage?

[garlonicon]

but is the source code most of us run in this place altered by you?

Just check, if you have my changes, or not: https://bitcointalk.org/index.php?topic=5496494.msg64205870#msg64205870

Are you the one who set difficulty=0x1d00ffff (including the 20 hours rule) and distributed the source code?

Yes, see the link above. And also note, that I didn't provide any binaries, only sources, and instructions. Which means, that if you have a working binary, with my changes, then you either built it by yourself, or got it from someone else.

Are you testnet4 Satoshi, or did testnet4 began prior this alteration?

My change is compatible with testnet4. You can use the official version, to have a working node, or you can use my version, if you want to mine blocks on your CPU.

So how do I do that?

1. If you call "generatetoaddress" or any other "generate" command, it will return you the hash of the block, when it is successful.
2. ASIC nodes produce a new block, with CPU difficulty, when for 20 minutes, there is no new block. This is when you should broadcast your block to the rest of the network.
3. You mine your block upfront, and just release it, at the right time. Nothing else is needed. If your block is first-seen, then you won. If not, then you lost. It is that simple.
4. I didn't yet write the code for network propagation wars, because I mined enough coins without it. But I know the theory behind it. However, I think about other ways of CPU mining, for example using OP_SIZE on signatures, because in case of testnets, developers will soon patch this CPU-mining hole, so it is not worth it, in the long term.

Do I just let it run, and expect to stand lucky, or is there a constant re-broadcasting every few seconds that takes place, which gives me advantage?

1. You prepare a block in advance, and keep it somewhere.
2. You schedule sending a P2P message to the network, at the right time.
3. You avoid all kind of "already seen block, nothing to be done" cases, where your own node will do nothing, because it already has that particular block.
4. You make sure, that you are connected with the original network, and not only with a bunch of nodes, enforcing 20 hours rule.

So, if I would do that, then I guess I would use at least two connections: one for the 20 hours node, to be a block producer, and one "proxy-only", to just serve the right blocks, at the right time.

But, as I said, I don't think it is worth the effort in the long term, so I didn't touch those parts of the code yet.

Are you testnet4 Satoshi

1. I am not Satoshi, that should be obvious.
2. As you can see, anyone can make changes. And then, users decide, which chain they want to run.

And, knowing the whole context of what happened in testnets, you can read this post again: https://bitcointalk.org/index.php?topic=5513595.msg64645672#msg64645672

Definitely, I didn't expect that ASIC miners will follow my changes. I didn't expect triggering over 500 blocks chain reorganization on testnet4 either. But well, I learned many new things, so I think it was worth it. Also, this is the purpose of testnet: to learn things. And my code allows that learning, by letting you to construct your local chain, and see, how much mining power you have, is your non-standard transaction valid, how chain reorganization works in practice, and so on.

But obviously, all of those CPU-mined blocks will vanish soon, when ASICs will adopt new rules for picking the right chain, to build new blocks on top of. And that's why I think about different models, because the path for CPU mining will be soon closed again (which is also expected; I didn't plan to be a CPU miner forever, and I knew, that it is just a nice hack, which will expire sooner or later, when ASIC miners will adopt those strategies as well, and bring the situation back to normal).

[LoyceV]

developers will soon patch this CPU-mining hole

Still, this doesn't feel right: testnet coins shouldn't only be mineable by ASIC, making developers ask for handouts. But I can't think of a solution, switching to ASIC resistant mining would make testnet too different from Bitcoin.

Scheduled testnet resets may work against gaining value, say every 6 months, but that would mean testnet will never experience any halvings again.