Requesting Testnet4 tBTC

[LoyceV]

Then it can work. But currently, I had some cases, where I had six future blocks in a row, and then needed to slow down my miners, so I am not planning to get more power out of it, because after passing two hours limit, the risk of getting your block reorged is increased (because if you don't re-submit your block properly, then it won't be broadcasted automatically, if you mine it too fast).

Someone figured out how to break Something broke garlonicon's code changes. My node is stuck on block 42335:

Code:

2024-09-02T05:25:52Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999425 cache=0.3MiB(16txo)
2024-09-02T05:25:52Z 0 block-relay-only anchors will be tried for connections.
2024-09-02T05:25:52Z init message: Starting network threadsâ¦
2024-09-02T05:25:52Z dnsseed thread start
2024-09-02T05:25:52Z Waiting 300 seconds before querying DNS seeds.
2024-09-02T05:25:52Z net thread start
2024-09-02T05:25:52Z addcon thread start
2024-09-02T05:25:52Z opencon thread start
2024-09-02T05:25:52Z msghand thread start
2024-09-02T05:25:52Z UpdateTip: new best=00000000ccf137e3823d03c9f23c1623ae3ce25fe29048e31674cfe4d3e47a98 height=42335 version=0x20000000 log2_work=70.828749 tx=781367 date='2024-09-01T21:49:09

This was after I restarted it.

Checking older logfiles, this happened last night:

Code:

2024-09-02T02:06:09Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:06:09Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:04Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:07:59Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:08:54Z CreateNewBlock(): block weight: 23257 txs: 22 fees: 6573 sigops 465
2024-09-02T02:12:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 16722 seconds ago)
2024-09-02T02:22:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17352 seconds ago)
2024-09-02T02:33:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 17982 seconds ago)
2024-09-02T02:43:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 18612 seconds ago)
2024-09-02T02:54:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19242 seconds ago)
2024-09-02T03:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T03:04:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 19872 seconds ago)
2024-09-02T03:15:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 20502 seconds ago)
2024-09-02T03:25:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21132 seconds ago)
2024-09-02T03:36:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 21762 seconds ago)
2024-09-02T03:46:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 22392 seconds ago)
2024-09-02T03:57:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23022 seconds ago)
2024-09-02T04:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T04:07:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 23652 seconds ago)
2024-09-02T04:18:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 24282 seconds ago)
2024-09-02T04:28:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 24912 seconds ago)
2024-09-02T04:39:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 25542 seconds ago)
2024-09-02T04:49:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 26172 seconds ago)
2024-09-02T05:00:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 26802 seconds ago)
2024-09-02T05:02:24Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T05:10:40Z Potential stale tip detected, will try using extra outbound peer (last tip update: 27432 seconds ago)
2024-09-02T05:21:10Z Potential stale tip detected, will try using extra outbound peer (last tip update: 28062 seconds ago)
2024-09-02T05:24:59Z tor: Thread interrupt
2024-09-02T05:24:59Z Shutdown: In progress...
2024-09-02T05:24:59Z addcon thread exit
2024-09-02T05:24:59Z torcontrol thread exit
2024-09-02T05:24:59Z msghand thread exit
2024-09-02T05:24:59Z net thread exit
2024-09-02T05:25:02Z opencon thread exit
2024-09-02T05:25:02Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat started
2024-09-02T05:25:02Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)
2024-09-02T05:25:02Z scheduler thread exit
2024-09-02T05:25:02Z Writing 39 mempool transactions to file...
2024-09-02T05:25:02Z Writing 0 unbroadcast transactions to file.
2024-09-02T05:25:02Z Dumped mempool: 0.000s to copy, 0.029s to dump, 13558 bytes dumped to file
2024-09-02T05:25:02Z Flushed fee estimates to fee_estimates.dat.
2024-09-02T05:25:06Z Shutdown: done

As far as I understand the code changes, it changes the "window" from 2 to 20 hours. And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

I wiped the testnet4 blockchain and restarted it, with the same result:

Code:

2024-09-02T07:07:59Z UpdateTip: new best=00000000a5b18671cb77a85ed98cf64a3a9f97d3c5a3f661465f6bbe1e97a250 height=42327 version=0x20000000 log2_work=70.827931 tx=781321 date='2024-09-01T21:08:13Z' progress=0.999277 cache=75.7MiB(589834txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000000e2daf4ee59372be354ac640a9e6686794f6ac68254b8d451c height=42328 version=0x2f296000 log2_work=70.828095 tx=781328 date='2024-09-01T20:51:02Z' progress=0.999257 cache=75.7MiB(589837txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000e853d1dd75ac2a1c424d6c90730897038074d85a0c374a73ac2322e9 height=42329 version=0x20000000 log2_work=70.828095 tx=781332 date='2024-09-01T21:11:03Z' progress=0.999281 cache=75.7MiB(589835txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004cd3ea3324d8bdfdf64eda9ef324e27103cfa98afcbd9bb65e height=42330 version=0x323a8000 log2_work=70.828258 tx=781342 date='2024-09-01T21:06:38Z' progress=0.999275 cache=75.7MiB(589834txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004c3233c6a02aed84e01aef09fc0c1bd74615d0bbd19e32eb92 height=42331 version=0x20000000 log2_work=70.828422 tx=781348 date='2024-09-01T21:11:50Z' progress=0.999282 cache=75.7MiB(589832txo)
2024-09-02T07:07:59Z UpdateTip: new best=0000000000000000b7059720cb0394af824c1eff5139c7d7396c51145ea5692c height=42332 version=0x2d752000 log2_work=70.828585 tx=781355 date='2024-09-01T21:21:38Z' progress=0.999293 cache=75.7MiB(589837txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000b5108be963a280da486ee21860bfdc931af42564c6a165d8dcfb387a height=42333 version=0x20000000 log2_work=70.828585 tx=781359 date='2024-09-01T21:41:39Z' progress=0.999318 cache=75.7MiB(589836txo)
2024-09-02T07:07:59Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999302 cache=75.7MiB(589839txo)
2024-09-02T07:07:59Z UpdateTip: new best=00000000542792e54a720567ba66157d48cdae7bfd01c1b678d0f07a2ed56e99 height=42335 version=0x20000000 log2_work=70.828749 tx=781367 date='2024-09-01T21:49:09Z' progress=0.999327 cache=75.7MiB(589843txo)
2024-09-02T07:08:17Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42391, peer=19

Mempool.space is at block 42391 already.

What happened here?

[garlonicon]

And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.

Also, if you mine any block, which is moved forward beyond those two hours, then when it will fall back into two hours window (because time is naturally moving forward), then you probably have to re-submit such block, because it won't be submitted automatically.

So yes, in general, if you are further than two hours in the future, then there is a huge risk of mining a chain, which will be reorged anyway. But: if you want to measure your mining power, then you need some way of doing that, and by having a secret, longer chain, you can measure, how many of your CPU-mined blocks will be reorged, when a single ASIC block will appear. And also, if you have a GUI version, then you will see all of those blocks as "stale" or "generated, not confirmed", or something like that.

Mempool.space is at block 42391 already.

The funny thing is that if you have a full P2P node, then you should also notice, that mempool.space is not some centralized source of truth anymore. If you have only CPU blocks in conflicting chains, then you should probably see, on top of which chain, you have more chainwork, and more ASIC blocks. Because for example, I thought that "mempool.space confirmed? Then safe", but I stopped thinking in that way, when I successfully reorged mempool.space, and when ASIC miners started to build new blocks on top of my history, and not theirs. If you are a node runner, then you are really P2P peer, and you should focus on chainwork, and not "just some centralized block explorer".

[LoyceV]

And other nodes reject blocks with a time more than 2 hours in the future, so the chain forks locally?

Yes, it should be probably reverted back into 2 hours, if your goal is to have a stable environment, running 24/7. I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that. However, if you will change it into "2 hours 20 minutes" or "3 hours", then it may work better. I guess "20 hours" is definitely too much. But it was fine for me, because I didn't put enough mining power, to really reach those limits.

I didn't think my mining power was causing it (but I can't be sure). I'm recompiled an unedited Bitcoin Core:

Code:

2024-09-02T07:52:57Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=0
2024-09-02T07:52:58Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=1
2024-09-02T07:53:04Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=2
2024-09-02T07:53:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=3
2024-09-02T07:53:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=4
2024-09-02T07:53:13Z P2P peers available. Skipped DNS seeding.
2024-09-02T07:53:13Z dnsseed thread exit
2024-09-02T07:53:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=5
2024-09-02T07:53:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=6
2024-09-02T07:53:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=7
2024-09-02T07:53:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=8
2024-09-02T07:53:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=9
2024-09-02T07:53:26Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=10
2024-09-02T07:53:27Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=11
2024-09-02T07:53:28Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=12
2024-09-02T07:53:34Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=13
2024-09-02T07:53:35Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=14
2024-09-02T07:53:35Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=15
2024-09-02T07:53:36Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=16
2024-09-02T07:53:37Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=17
2024-09-02T07:53:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=18
2024-09-02T07:53:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=19
2024-09-02T07:53:44Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=21
2024-09-02T07:53:45Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=23
2024-09-02T07:53:46Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=26
2024-09-02T07:54:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=28
2024-09-02T07:54:05Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=29
2024-09-02T07:54:16Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=31
2024-09-02T07:54:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=33
2024-09-02T07:54:24Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=34
2024-09-02T07:54:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=35
2024-09-02T07:54:25Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=36
2024-09-02T07:54:31Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=37
2024-09-02T07:54:43Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=38
2024-09-02T07:54:49Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=39
2024-09-02T07:54:49Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=40
2024-09-02T07:54:51Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=41
2024-09-02T07:54:57Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=42
2024-09-02T07:54:58Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=43
2024-09-02T07:54:59Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42397, peer=44

Some nodes are stuck at 42335, most are at 42397. Shouldn't it reorg on it's own to follow the longest chain?

Also, if you mine any block, which is moved forward beyond those two hours, then when it will fall back into two hours window (because time is naturally moving forward), then you probably have to re-submit such block, because it won't be submitted automatically.

So you'll kinda need to "manually" keep track and upload them?

So yes, in general, if you are further than two hours in the future, then there is a huge risk of mining a chain, which will be reorged anyway. But: if you want to measure your mining power, then you need some way of doing that, and by having a secret, longer chain, you can measure, how many of your CPU-mined blocks will be reorged, when a single ASIC block will appear. And also, if you have a GUI version, then you will see all of those blocks as "stale" or "generated, not confirmed", or something like that.

I don't want to measure mining power, I just wanted to feel the fun of mining blocks that I missed out of in 2009

Mempool.space is at block 42391 already.

The funny thing is that if you have a full P2P node, then you should also notice, that mempool.space is not some centralized source of truth anymore. If you have only CPU blocks in conflicting chains, then you should probably see, on top of which chain, you have more chainwork, and more ASIC blocks. Because for example, I thought that "mempool.space confirmed? Then safe", but I stopped thinking in that way, when I successfully reorged mempool.space, and when ASIC miners started to build new blocks on top of my history, and not theirs. If you are a node runner, then you are really P2P peer, and you should focus on chainwork, and not "just some centralized block explorer".[/quote]
I used mempool.space as an example, because I always assumed Bitcoin Core would follow the longest chain automatically. I'm still surprised it got stuck that many blocks in the past.
I've wiped my .bitcoin directory again, to see if the unpatchedk Bitcoin Core now goes for the longest testnet4 chain.
Update: it doesn't:

Code:

2024-09-02T08:04:19Z UpdateTip: new best=0000000000000021760623041a7a1b78f92d80beec504f43a46edf27a8993787 height=42326 version=0x2c94e000 log2_work=70.827931 tx=781320 date='2024-09-01T20:48:12Z' progress=0.999185 cache=75.7MiB(589833txo)
2024-09-02T08:04:19Z UpdateTip: new best=00000000a5b18671cb77a85ed98cf64a3a9f97d3c5a3f661465f6bbe1e97a250 height=42327 version=0x20000000 log2_work=70.827931 tx=781321 date='2024-09-01T21:08:13Z' progress=0.999209 cache=75.7MiB(589834txo)
2024-09-02T08:04:19Z UpdateTip: new best=000000000000000e2daf4ee59372be354ac640a9e6686794f6ac68254b8d451c height=42328 version=0x2f296000 log2_work=70.828095 tx=781328 date='2024-09-01T20:51:02Z' progress=0.999189 cache=75.7MiB(589837txo)
2024-09-02T08:04:19Z UpdateTip: new best=00000000e853d1dd75ac2a1c424d6c90730897038074d85a0c374a73ac2322e9 height=42329 version=0x20000000 log2_work=70.828095 tx=781332 date='2024-09-01T21:11:03Z' progress=0.999213 cache=75.7MiB(589835txo)
2024-09-02T08:04:19Z UpdateTip: new best=000000000000004cd3ea3324d8bdfdf64eda9ef324e27103cfa98afcbd9bb65e height=42330 version=0x323a8000 log2_work=70.828258 tx=781342 date='2024-09-01T21:06:38Z' progress=0.999208 cache=75.7MiB(589834txo)
2024-09-02T08:04:19Z UpdateTip: new best=000000000000004c3233c6a02aed84e01aef09fc0c1bd74615d0bbd19e32eb92 height=42331 version=0x20000000 log2_work=70.828422 tx=781348 date='2024-09-01T21:11:50Z' progress=0.999214 cache=75.7MiB(589832txo)
2024-09-02T08:04:19Z UpdateTip: new best=0000000000000000b7059720cb0394af824c1eff5139c7d7396c51145ea5692c height=42332 version=0x2d752000 log2_work=70.828585 tx=781355 date='2024-09-01T21:21:38Z' progress=0.999226 cache=75.7MiB(589837txo)
2024-09-02T08:04:19Z UpdateTip: new best=00000000b5108be963a280da486ee21860bfdc931af42564c6a165d8dcfb387a height=42333 version=0x20000000 log2_work=70.828585 tx=781359 date='2024-09-01T21:41:39Z' progress=0.999250 cache=75.7MiB(589836txo)
2024-09-02T08:04:19Z UpdateTip: new best=000000000000004ac75332dec3b2ed28f2e94a2a2a978b9373b9dd3e9e1dfa11 height=42334 version=0x27ba0000 log2_work=70.828749 tx=781363 date='2024-09-01T21:29:08Z' progress=0.999235 cache=75.7MiB(589839txo)
2024-09-02T08:04:19Z UpdateTip: new best=00000000542792e54a720567ba66157d48cdae7bfd01c1b678d0f07a2ed56e99 height=42335 version=0x20000000 log2_work=70.828749 tx=781367 date='2024-09-01T21:49:09Z' progress=0.999259 cache=75.7MiB(589843txo)
2024-09-02T08:04:23Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=26
2024-09-02T08:05:10Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=30
2024-09-02T08:06:49Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=37
2024-09-02T08:13:06Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=55
2024-09-02T08:13:35Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=56
2024-09-02T08:13:46Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42335, peer=57
2024-09-02T08:15:07Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=59
2024-09-02T08:17:07Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=62
2024-09-02T08:19:30Z New outbound-full-relay v2 peer connected: version: 70016, blocks=42401, peer=66

The weird part is: the generatetoaddress thing also doesn't find block 43336. I would have expected that to continue, but clearly I'm missing something.

I needed this change mainly for testnet3, because it was normal, to have six future blocks, which made it impossible to CPU-mine any block on top of that.

At the moment, testnet3 doesn't have 6 blocks in the future, it has someone who mines a block 2 hours ahead all the time:

(source)

The ones with the long Coinbase tag look like ASIC miners. The ones with the short Coinbase tag have a Timestamp about 2 hours in the future. It looks like the ASIC Timestamp is also ahead, but less.
It looks like this 2 hour ahead thing blocks your code changes.

[vjudeu]

Shouldn't it reorg on it's own to follow the longest chain?

Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.

So you'll kinda need to "manually" keep track and upload them?

Only those, which are above two hours. And only if you use different settings, than most of the network. Because if 99% nodes would use 20 hours rule, then it would be "de facto standard", and if the heaviest chainwork would be there, then 2 hours rule would simply be lifted. Because there is no centralized source of time: if you have a brand new node, and it tries to download the whole chain history, it doesn't know, if the chain with 2^70 chainwork contains many years of history, or are there just two 2^69 blocks, with today's timestamp (and a lot of smaller ones, to adjust the difficulty).

I just wanted to feel the fun of mining blocks that I missed out of in 2009

After reaching two hours limit, you have those options:

1. Stick to two hours rule, and stop mining, waiting for some ASIC block, to put the current time.
2. Stick to two hours rule, and still try to mine something, but with ASIC difficulty on CPU, which will likely just burn that power for nothing.
3. Produce a secret, longer chain, and do your testing, knowing that after a while, a new ASIC block will come, and destroy your chain (but in the meantime, you will have a fully working playground, to test non-standard transactions, mining power, or anything else).

Also note, that when there was almost no competition, and we were mining CPU blocks alone, or with a few friends, or when it was "my first node vs my second node" or even "garlonicon's node vs vjudeu's node" then we didn't need to think about all of those consequences, and implications of those rules. But now, when more bitcointalk users will try CPU mining, we will probably encounter more issues, than we found, when we were alone, or with some small, closed and well-coordinated group of friends. We simply didn't put enough CPU power, to test some corner cases, like "more than 51% of blocks, mined by CPUs".

To sum up: it is nice to see some competition: if more bitcointalk users will start mining testnet coins, then maybe some people will get some knowledge, for example "how hard is to CPU-mine things at difficulty one".

[garlonicon]

it has someone who mines a block 2 hours ahead all the time

Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged. So, if some CPU miner will send one block with "20 minutes 1 second", and second block with "40 minutes 2 seconds", then those two blocks will knock out that "1 hour 59 minutes 59 seconds" block.

So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets.

Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks.

[LoyceV]

I started my default bitcoin-qt on testnet4:

Code:

Number of blocks left: Unknown. Syncying Headers (42335, 99.8%)...

I know it's testnet, but doesn't this mean it's broken? Could it be the code changes that removed the "block storm" created something unexpected, that makes standard nodes unable to keep syncing?

Shouldn't it reorg on it's own to follow the longest chain?

Maybe some developers are testing "7200 seconds rule" or "600 seconds rule"? If CPU miners push the time too much into the future, then after Median Time Past (MTP), miners have no chance to adjust the time backwards, and put the current time in their blocks. Which can cause some additional inflation, if it happens around difficulty adjustment.

I've been wondering for a while what happens if most Bitcoin miners adjust their clock to the future.

Only those, which are above two hours. And only if you use different settings, than most of the network. Because if 99% nodes would use 20 hours rule, then it would be "de facto standard", and if the heaviest chainwork would be there, then 2 hours rule would simply be lifted. Because there is no centralized source of time: if you have a brand new node, and it tries to download the whole chain history, it doesn't know, if the chain with 2^70 chainwork contains many years of history, or are there just two 2^69 blocks, with today's timestamp (and a lot of smaller ones, to adjust the difficulty).

This goes right over my head. It's amazing Bitcoin has been working without major problems all those years.

After reaching two hours limit, you have those options:

1. Stick to two hours rule, and stop mining, waiting for some ASIC block, to put the current time.
2. Stick to two hours rule, and still try to mine something, but with ASIC difficulty on CPU, which will likely just burn that power for nothing.
3. Produce a secret, longer chain, and do your testing, knowing that after a while, a new ASIC block will come, and destroy your chain (but in the meantime, you will have a fully working playground, to test non-standard transactions, mining power, or anything else).

I think the 20 * 60 * 60 code changes did #3 by default, right? But then why doesn't it find new blocks anymore after block 42335?

Also note, that when there was almost no competition, and we were mining CPU blocks alone, or with a few friends, or when it was "my first node vs my second node" or even "garlonicon's node vs vjudeu's node" then we didn't need to think about all of those consequences, and implications of those rules. But now, when more bitcointalk users will try CPU mining, we will probably encounter more issues, than we found, when we were alone, or with some small, closed and well-coordinated group of friends. We simply didn't put enough CPU power, to test some corner cases, like "more than 51% of blocks, mined by CPUs".

It's interesting to see though. I'm still flabbergasted my standard testnet4 node is stuck because of what looks like miners running non-standard code.

To sum up: it is nice to see some competition: if more bitcointalk users will start mining testnet coins, then maybe some people will get some knowledge, for example "how hard is to CPU-mine things at difficulty one".

Considering how long it still takes to mine a block at difficulty 4 on a 5 years old Xeon CPU, this must have been much longer in 2009.

it has someone who mines a block 2 hours ahead all the time

Yes, I put "20 minutes and 1 second" for a reason: in this case, you can mine six CPU blocks for two hours. However, if you put instead "1 hour 59 minutes 59 seconds", or something like that, then your single CPU block will knock every CPU miner out, for the next 20 minutes. But: there is a catch: if someone will mine more CPU blocks in a row, then that single block will be reorged.

Doesn't that mean you'd have to adjust your code to mine 2 blocks starting from the previous block, instead of mining on top of the 1:59:59-ahead block? So it requires more code changes, right?

So, it is a game of CPU-mined chain reorgs. But: winning the game, and picking an optimal strategy, is a big challenge. Because the default implementation is definitely not the best one, and can be beaten by someone, who will write a better code, specifically for testnets.

Do I get it right that this only works on testnet because of the difficulty drop after 20 minutes? Wouldn't it be better to change the default rules, let's say the difficulty drops only after 3 hours, so normal mining isn't affected? Or reduce the time difference between miners to no more than 10 minutes instead of 2 hours?

Edit: One more thing: any CPU miners can be easily stopped by ASIC miners, if they will simply change their strategy, to fully fill the queue of easy blocks, and only then mine their ASIC blocks on top of that. The fact, that CPU miners still have some chances, is a signal, that ASIC miners are just sticking with unmodified Bitcoin Core, and are not trying to get the maximum number of blocks, out of it. Or: maybe they don't have enough knowledge, to write a better code, and they don't want to risk mining invalid ASIC blocks.

Thanks for the explanation. I'm still amazed people have been burning ASIC power on testnet for years.

@garlonicon's signature: I still can't wrap my head around dealing with private keys in descriptor wallets, so brainwallets aren't really an option at the moment. I'll give it a try when Electrum supports testnet4.

It turns out I did mine block 42335. How come multiple nodes can't get passed this block?

[vjudeu]

I think the 20 * 60 * 60 code changes did #3 by default, right?

It starts with #3, and then, it rejects your own blocks, which is the same, what happens, if you run out of two hours. By changing from 2 to 20 hours, you just accept more blocks, but in general, if they are CPU-mined, then there is a huge risk, that they will be reorged.

But then why doesn't it find new blocks anymore after block 42335?

Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain.

So: do you want to disable 600 seconds rule?

Code:

if (consensusParams.enforce_BIP94) {
    // Height of block to be mined.
    const int height{pindexPrev->nHeight + 1};
    if (height % consensusParams.DifficultyAdjustmentInterval() == 0) {
        nNewTime = std::max<int64_t>(nNewTime, pindexPrev->GetBlockTime() - MAX_TIMEWARP);
    }
}

I really wonder, if ASICs will follow that kind of timewarp fixes. Because there is a risk, that people may ignore 600 seconds rule, or you may have some nodes, with MAX_TIMEWARP of 600 seconds, and some with 7200 seconds, and then there will be some competing chains.

For now, I simply use some version without those timewarp protections. I don't know, what will happen after block 42335: maybe the current chain will be reorged, or maybe it will be grandfathered in, and the activation of all BIP 94 rules will come later. Who knows, time will tell.

So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing.

[LoyceV]

Because the difference between block 42335 and block 42336 is 11 minutes and 6 seconds. And if you enforce 600 seconds rule, then this ASIC block doesn't meet it. Which means, that if you enable BIP 94, then you land on a shorter chain.

I take it BIP 94 is enabled already by default. I read bip-0094.mediawiki:

To protect against the time warp attack, the following rule proposed as part of The Great Consensus Cleanup[5] is enforced: "The nTime field of each block whose height, mod 2016, is 0 must be greater than or equal to the nTime field of the immediately prior block minus 600. For the avoidance of doubt, such blocks must still comply with existing Median-Time-Past nTime restrictions."

I won't claim to understand it entirely, but it looks like the problem arose because 21*2016=42336. And that block gets rejected.
But, if that's the default, how come most nodes continue nonetheless? I guess this does explain why mining 20 minutes in the future is no longer possible.

So, if you want to switch to a longer chain, then upgrade your master, switch MAX_TIMEWARP from 600 to 7200, or use some version, where it is entirely disabled, like probably mempool.space is doing.

I guess this is the path to go. I don't want it to be stuck until someone changes something.

Code:

vi test/functional/mining_basic.py
MAX_TIMEWARP = 1200

src/consensus/consensus.h
static constexpr int64_t MAX_TIMEWARP = 1200;

Update: my testnet4 node is now processing blocks again. Let's see if it mines blocks again

[sjors]

The timewarp attack mitigation for testnet4 requires the first block of a new difficulty adjustment period to have a timestamp later than that of the last block of the previous period.

Initially there was a 7200 second (2 hour) grace period. This was changed to 600 seconds (10 minutes) two weeks ago: https://github.com/bitcoin/bitcoin/pull/30647 (matching the original Great Consensus Cleanup proposal).

This change is effectively a soft fork on testnet4, but with no activation mechanism.

Anyone who runs the v28.0rc1 release candidate, or a very recent master, will enforce it. Anyone who runs an older version won't enforce it.

My guess is that most miners on testnet4 haven't updated yet. Even if they did that today, the node won't automatically go back to validate old blocks.

If enough miners switch to v28.0(rc...) and call `invalidateblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` followed by `reconsiderblock 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 ` they will reject the block at height 42336. This will lead to a one day reorg, or more if it's done later.

An alternative approach would be to change Bitcoin Core to enforce the modified timewarp rule from a certain flag height in the future, but that seems like a lot of complexity for a test network that hasn't even been released yet.

As an aside: the SegWit soft fork did have a mechanism for handling this situation. If a user upgrade their pre-segwit node to a segwit node sometime after activation, it would roll back the chain and check everything again.

[sjors]

By the way, I think what happened here is that someone tried to CPU mine coins on testnet by setting their clock > 20 minutes into the future.

Such a block would be accepted by all nodes (upgrade or not). But v28 nodes then require the next block to be >10 minutes in the future, whereas before they would allow 1 hour and 50 minutes in the past (which includes the present).

v28.0rc1 contains a fix for the Bitcoin Core miner code (getblocktemplate, etc) that ensures timestamps are adjusted: https://github.com/bitcoin/bitcoin/issues/30614

---

Update: the above invalidateblock / reconsiderblock sequence won't work.

The only way to get an upgraded node to re-check the timewarp rules is:

Code:

bitcoind -tesnet4 -reindex

[LoyceV]

I'm not sure what's the best thread, so I'll just post it here: testnet3's mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time.
Amazingly, that means testnet3 can now actually be used again for testing

[vjudeu]

testnet3's mempool is currently empty

It's nothing new. There are waves of transactions: sometimes mempools are full, sometimes they are empty. And the cost to fill up the whole 300 MB is quite low.

And note that even if mempool.space shows you a fully filled mempool, then it doesn't mean, that you have to pay that much. For example: if some CPU mining node is just starting up, then it could have an empty mempool, and fetching all of those transactions in P2P way is quite slow process, and if you can see a low block health, then it doesn't always mean censorship: it could mean as well, that this particular miner just turned on its node, and it was turned off recently, for whatever reason. And during that time, you can get your transactions confirmed cheaper, if you send it to that particular node. Which means that again: the default fee estimation is far from being optimal, because it doesn't consider such details.

that means testnet3 can now actually be used again for testing

You can always mine future blocks, and prioritize your own transactions. And you can pay zero fee in your own transactions, if you are a miner. And even if there is some opportunity cost, then statistically, sometimes blocks are not fully filled, and in a general case, it makes a lot of sense to send and mine your own transactions with a low feerate (also because if you use less than 1000 sat/kvB, then you can "cancel" that easier, in case of mistakes).

Also note, that if you want to mine some coins, then you can do that on signet, too: https://delvingbitcoin.org/t/proof-of-work-based-signet-faucet/937

[ercewubam]

Amazingly, that means testnet3 can now actually be used again for testing

Not only that. It also means, that mining testnet3 is now less profitable, and switching into testnet4 is a better idea. But a short while before that, it was the opposite, when it was not certain, if testnet4 will be reorged or not. Now we know, that those, who consider 00000000000000263393ce5f648afd53676f13d360cc9f264b89351623bf1242 as a valid block, are simply mining coins, which will vanish, after upgraded ASICs will mine an alternative chain, on top of 0000000000000016be66ab39af9f97e1294080c94d0a34cc304e391794a481bd.

In general, we are about to see at least 360 blocks reorg, at the time of writing. I guess it could be 500 blocks reorg, or even 1000 blocks reorg, depending on how many people will mine blocks, when using some older version.

[ABCbits]

I'm not sure what's the best thread, so I'll just post it here: testnet3's mempool is currently empty. For the past months, mempool was full and fees where high. It looks like the "data spam" suddenly stopped, while ASIC miners and "20 minute miners" have halved the block time.

Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value.

Amazingly, that means testnet3 can now actually be used again for testing

Although i wonder how easy is it to obtain testnet3 coins now (aside from mining). Tesnet faucet was abused on many occurrence.

[LoyceV]

Weird, since yesterday testnet3 was busy where mempool.space recommend over 500 sat/vB for high priority TX. I wonder if most ordinal/rune created on testnet3 no longer have value.

Just like I've speculated about it on real Bitcoin, I think here the ordinal spam also comes from only one person. That explains why all transactions are in the same style, and start and stop at the same time too.