Fixing Testnet4: proposal

[LoyceV]

The only problem I can think of, is that, since bits are the same, the old nodes' chain will not get immediately reorged by the new chain, as CPU miners can generate min-diff blocks more often than miners can generate real-diff blocks. The old chain will be reorged when an ASIC miner mines a block with a timestamp less than 20 minutes than the previous one, as it must use real-diff bits in the old field.

ASIC miners can do that already if they want. So it comes down to the same problem: convince some ASIC miners to wipe out CPU blocks. And if you have to convince them to make changes anyway, isn't it much easier to go with a hard-fork?

[hmbdofficial]

Technically doable, and I tried similar ideas to test cases, when SHA-256 would be broken. Basically, even if the block header says 0x1d00ffff, then still, you can require meeting the real difficulty, and reject the block, if it is not the case.

In your testing scenarios I mean when imagining SHA- 256 being broken, how did you handle the chainwork? Did you adjust it manually, or did you keep the legacy calculation and rely on the new validation rule?.

[BlackHatCoiner]

But then, the contribution to the chainwork will be still calculated in the old way.

Why not configure the new nodes to calculate chainwork using the new field after the fork height? It will only appear outdated in the old nodes. New nodes' chainwork will be rendered correctly.

ASIC miners can do that already if they want. So it comes down to the same problem: convince some ASIC miners to wipe out CPU blocks.

The problem is the timestamp. If they consider the CPU blocks invalid, and try to mine a block with real difficulty, but with >20 min timestamp than the previous block, old nodes will reject it because of bad-diff-bits. What we want is for the old nodes to follow the new chain without having to update.

Wiping out CPU blocks works if they replace the CPU blocks with their min-diff blocks, but this can be a very complicated and inconsistent solution. Invalidating blocks with >20 min timestamp (road C) and introducing a new bits field (road D) are the only consistent softfork proposals that have a chance of actually working.

[stwenhao]

how did you handle the chainwork?

By expanding it to 512 bits. Because if you can produce any SHA-256 result, then all following blocks could hash into zero. Which means, that you will then have the current chainwork as it is, and the new chainwork somewhere else. And then, a new hash function could be executed on the same data, so it would be difficult to produce again.

did you keep the legacy calculation and rely on the new validation rule?

The legacy part would just contain the low 256 bits, and the new part would contain only the upper 256 bits of 512-bit chainwork.

Why not configure the new nodes to calculate chainwork using the new field after the fork height?

Well, you can do that.

It will only appear outdated in the old nodes.

Which is tricky, because then, one ASIC block, valid in the old network, could potentially reorg a lot of new ASIC blocks from the new network, because their chainwork would be weaker. Which means, that technically, it could be a soft-fork, but it has a high chances of leading to chain splits, even if you will have hashrate majority on your side. Just because the blocks perceived by "strong" in the new network, won't be counted as such in the old network.

It is similar to switching from the longest chain to the heaviest chain: new nodes follow the new rules, but old nodes can still be tricked, to accept a weaker chain. The difference is, that this time, having hashrate majority is not enough, to get all nodes on the same chain, if they count things differently.

Invalidating blocks with >20 min timestamp (road C) and introducing a new bits field (road D) are the only consistent softfork proposals that have a chance of actually working.

Honestly, I think the longer you would think about possible solutions, the lower chances you would have to actually deploy something.

If you would have a plan, like "just hard-fork, and don't care", then you know, what to do, and how to do it.

If you would start making a lot of different solutions, then you wouldn't know, which solution is better, and you will endlessly invent new ones, instead of deploying anything, and moving forward.

[BayAreaCoins]

Honestly, I think the longer you would think about possible solutions, the lower chances you would have to actually deploy something.

If you would have a plan, like "just hard-fork, and don't care", then you know, what to do, and how to do it.

If you would start making a lot of different solutions, then you wouldn't know, which solution is better, and you will endlessly invent new ones, instead of deploying anything, and moving forward.

I agree with this.


I spoke to someone more technical than me...  He explained the softfork on a low level that I understand.

I support the soft fork as proposed.  Though, I still think a hardfork is cleaner and I do think the difficulty of it is over estimated.

We can start with a soft fork IMO and the hard fork remains an option... perhaps not being so heavy-handed is the best route.


ACK Soft fork

[BlackHatCoiner]

Honestly, I think the longer you would think about possible solutions, the lower chances you would have to actually deploy something.

Agreed. We will start with road C, which is disabling >20 min timestamp blocks. Do you think I should create an entirely new PR, or edit the current one? I'm thinking that having all this history in git might be confusing now that I'll rebase it and make completely new changes.

Another good reasoning behind the softfork is to see the willingness of the mining pools. If they don't care to upgrade, there's no need to discuss anything. I hardly doubt Bitcoin Core will ever merge this if there's no support from miners for an extended period.

[stwenhao]

I think the easiest route is to go with the hard-fork, and see, if it will succeed. And try soft-forking later, when hard-fork will fail, or will be rejected by the majority. Because in that case, the code is ready, so it can be done here and now. Then, it is a matter of getting support for what you already have, instead of making yet another solution.

We will start with road C, which is disabling >20 min timestamp blocks.

You can do it on a separate branch, to see, if it would be better, than the current implementation. Because you don't want to break a working code, that you now have. And if the hard-fork will succeed, then it won't be needed.

Do you think I should create an entirely new PR, or edit the current one?

I think the code should be pushed on some branch first, and then you can think about editing the Pull Request, and picking the right branch. Because Pull Request is just attached to some branch, and that's all. Changing Pull Request from that branch to another is easy. The hard part is writing the code.

So, if you will have each version on a separate branch, then later, it would be a matter of picking the right branch, and making a Pull Request.

I hardly doubt Bitcoin Core will ever merge this

I agree. They wanted to start testnet5 completely from scratch. And now, they are testing things on signet, and don't care about testnet3 or testnet4.

Note that testnet4 was first created, and then merged into Bitcoin Core, when it was up and running, and already produced around 40k blocks. Which means, that if you want to fix testnet4, then you should first deploy it, and then try to merge it. Because from the Core's perspective, testnet4 is no longer worthless, so they are no longer interested in using it for testing. So, it is now yet another altcoin, and all fixes are just for AltQuick exchange, and some remaining users, it is basically yet another altcoin, which could be even deprecated in some next version, just like testnet3 is scheduled to be dropped.

[BayAreaCoins]

I think the easiest route is to go with the hard-fork, and see, if it will succeed.

I feel like you're just dead set on being a pain in the ass.

and all fixes are just for AltQuick exchange

Fixing what for AltQuick?  Last I checked we are doing just fine... it's the rest of you poor bastards.

1400 TBTC4 in the faucet too while giving 0.01 every ten minutes to users (often 0.02 due to affiliates)... Which is the point of Testnet also.  How many coins do you have in your public-facing faucet?

[BlackHatCoiner]

No, the softfork is the easiest route, because it requires the least disruption in the network. It is only a handful of miners that need to point their hashrate to their new nodes. Everything else can stay the same. The hardfork should be the last resort, and must be initiated when we know there is at least some significant support from miners as well.

I'm almost done with the code. Super simple. I will create another PR soon.