Fixing Testnet4: proposal

[BayAreaCoins]

I have completed the technical brief of the softfork: https://batmanbytes.github.io/testnet4-softfork/. I've tried to keep it clean, short and descriptive enough. This will be read primarily by miners, so we don't want to make it difficult to read by over-explaining the technical details.  

I believe the next step is direct outreach via email.

In theory, what if I or my service AltQuick.com don't get an email? (or perhaps we are lazy or don't care or whatever)

Nothing at all?  People keep testing?

[stwenhao]

what if I or my service AltQuick.com don't get an email?

Well, new blocks are compatible with the old network. But old blocks, mined by CPUs, are incompatible with new rules. Which means, that as long as ASICs will keep enforcing the new rules, then all blocks with minimal difficulty will be reorged in all nodes. And new nodes will accept only ASIC blocks after activation.

The only case I can see, where the chain would split, is if ASICs will build blocks on top of CPUs, which would detach the old nodes from the network. But even then, it will be a matter of hashrate, which means, that the new nodes will constantly try to build ASIC-only chain. And if it will be stronger, then old nodes will be later forced to accept it, because it will be seen as a chain reorganization on their side.

Nothing at all?  People keep testing?

Old nodes can be tricked into accepting a chain with CPU blocks for a while. But if the majority of ASICs will keep reorging them, then it will work.

Also, because of the changes in the mining code, people can start enforcing new rules today. The only thing, which would happen at block 151,200, is hard-rejecting CPU blocks. But if enough miners will upgrade here and now, then the network difficulty can start falling now, which would reduce the amount of min-difficulty blocks produced today. And then, if there would be a lot of ASIC blocks, produced every 10 minutes, then there will be no CPU blocks, long before block 151,200, if enough miners will upgrade.

[hmbdofficial]

Also, because of the changes in the mining code, people can start enforcing new rules today. The only thing, which would happen at block 151,200, is hard-rejecting CPU blocks. But if enough miners will upgrade here and now, then the network difficulty can start falling now, which would reduce the amount of min-difficulty blocks produced today. And then, if there would be a lot of ASIC blocks, produced every 10 minutes, then there will be no CPU blocks, long before block 151,200, if enough miners will upgrade.

I believe chain stability and reorg depth for old now and any other non- upgraded clients will be Accepted by the CPU mined as valid only if it has most cumulative work. But if the large portion of the hash rate still remains on old software the CPU chain could just pull ahead substantially in terms of of chainwork before enough ASICs switch over right? Why do I think it may cause double spending, and wallet confusion as well,because Reorging a deep chain is extremely disruptive. How do you handle that?

[stwenhao]

Reorging a deep chain is extremely disruptive. How do you handle that?

This is just testnet. Previous testnets had literally hundreds of reorged blocks.

it may cause double spending, and wallet confusion as well

Which is why exchanges like AltQuick require 100 confirmations. Also note, that the only reorged thing is related to CPU blocks, so regular users are unaffected. And coinbase transactions below 100 confirmations can be always reorged, even in mainnet, just because they are unspendable before reaching it.

In general, I think BlackHatCoiner handled it correctly. As long as it affects only testnet4, and nothing else, like mainnet, it should be safe to use. And it is definitely better than nothing, now it is just a matter of convincing miners to use it. If the difficulty will start dropping, then users will no longer have to wait an hour for ASIC blocks, and could get things confirmed every 10 minutes, as it should be.

But if the large portion of the hash rate still remains on old software the CPU chain could just pull ahead substantially in terms of of chainwork before enough ASICs switch over right?

Only ASIC blocks affect chainwork in a meaningful way. A single ASIC block could reorg millions of min-difficulty blocks. Also, splits are rarely 50/50, so it is more likely to see 10/90 split, or similar. And then, the question is: where the hashrate majority would be? Transactions made by users are only confirmed in ASIC blocks anyway, so reorgs will mainly affect only miners. It is very likely, that transactions made by users will land in both chains, so they will be confirmed everywhere.

[LoyceV]

The only case I can see, where the chain would split, is if ASICs will build blocks on top of CPUs, which would detach the old nodes from the network. But even then, it will be a matter of hashrate, which means, that the new nodes will constantly try to build ASIC-only chain. And if it will be stronger, then old nodes will be later forced to accept it, because it will be seen as a chain reorganization on their side.

Let's say "BHC's chain" gets a higher hash rate, and "old" nodes follow that chain. Does that mean that, say, 2 months from now, those nodes will think the latest block is weeks in the past, and all ASIC miners on that chain instantly produce thousands of CPU blocks each with 20 minutes in between on top of it?

Which is why exchanges like AltQuick require 100 confirmations.

If my scenario above is correct, that's going to be fun

[stwenhao]

Does that mean that, say, 2 months from now, those nodes will think the latest block is weeks in the past, and all miners on that chain produce thousands of CPU blocks each with 20 minutes in between on top of it?

No, because they will accept ASIC blocks, produced by the new chain.

In theory, the chain could split for a while. But later, a chain reorganization will just solve it. Old nodes will have some ASIC blocks, and some CPU blocks, while a new chain will have only ASIC blocks. If the new chain will reach a bigger chainwork, then it will overwrite the old chain.

Also note, that the code for mining things in a new way can be used today, without any soft-forks. The soft-fork part is only about marking CPU blocks as invalid. But mining ASIC blocks with 20 minutes delay can be done here and now, which would lower the difficulty.

[BlackHatCoiner]

In theory, what if I or my service AltQuick.com don't get an email? (or perhaps we are lazy or don't care or whatever)

If you do not upgrade, then your node's chain will periodically experience reorgs. You won't miss the soft fork chain. You will just consider the CPU miners' blocks valid until an ASIC miner sends a block with real difficulty which reorgs all of them.

For you specifically, you should upgrade your AltQuick's node for the user experience. If a user has deposited coins to your exchange, and his transaction reaches 10 confirmations, and an ASIC miner reorgs the past 10 blocks, then the transaction will be back to 0-conf or 1 confirmation. That is just bad UI.

Reorging does not mean replacing. If blocks 130,001 to 130,010 are min difficulty blocks, and an ASIC miner ignores them (because he is running the soft fork), he's mining block 130,001 with real difficulty, and once he does, those blocks will no longer be valid in the non-upgraded chain.

[stwenhao]

For you specifically, you should upgrade your AltQuick's node for the user experience. If a user has deposited coins to your exchange, and his transaction reaches 10 confirmations, and an ASIC miner reorgs the past 10 blocks, then the transaction will be back to 0-conf or 1 confirmation. That is just bad UI.

They require 100 confirmations, so they should be safe.

Reorging does not mean replacing.

From the perspective of a node, working on a minority chain, it looks exactly like that. But fortunately, only coinbase transactions are "replaced" in practice, everything else usually ends up being confirmed by all chains. In the worst case, some transactions could go back to zero confirmations, if some miner will decide to include some double-spends, but still: that miner would need to take part in that transaction. You have to sign your input in a different way, to actually make a double-spend, so if users are just sending transactions between themselves, then they will be safe even in that case.