[Dev] The Path to Upgrading of Blockchain from V2 to v4
lizhi last edited by wrapper | Tip lizhi
It’s a pity that I failed today. I want to upgrade our blcokchain from version 2 to version 4. But I get a Orphaned Block at 1219055 .
Our 0.11.2 node accpet it ,but 0.9.3 node refuse it.
- are you sure, that version 4 is fully backward compatible to version 2?
- did you do that on the testnet before?
- did you test it with all versions currenty on the prod net active on the testnet? This means Wallet versions 0.8.7, 0.8.7.1 - 0.8.7.3 and 0.9.3, 0.9.3.1, 0.9.5.1 and eventually the 0.11.x versions!!
There is a high risk of forking the BC if that change is not implemented in a proper way. we need to be sure, that all clients on the production chain are able to handle version 4.
As you know we had a fork situation already to month ago, because some clients produced blocks, that where not accepted by older clients and it took big effort to solve that, not to mention the loss for a lot of miners, who where on the wrong branch of the block chain.
I’d prefer, if we could agree on a plan before implementing such drastic changes to the BC
Our problem is 0.8 and 0.9 accept version 2 only. Both stay in place for ever. So we need to obsolete old client.
0.11 can run with old protocol, but old version can not upgrade. This is a headache problem.
We need to do a well prepared switch over to version 4.
It will be a hard fork, but we can do it like we did for the neoscrypt fork.
We define a block height some month in the future, where we will start creating V4 blocks.
Then we announce that block number and the expected date/time for the block and give people a chance to update in advance.
We can test this process in the testnet and minmize the risk.
All the people stop the old version,use new version. I think it’s so.
Yes, but the new version needs to use protocol version 2 until a defined block is mined and then switch to protocol version 4.
The block that triggers the switch, must be at least 3 month in the future AFTER the new version is fully tested on the testnet, and prooved to be stable and safe
Today, I insert ACP into Core 0.11.2 . It work right.
@lizhi : great work
How did you test it?
This makes 0.11.2 the next release candidat. We ‘just’ need to plan the release and the corresponding hard fork carefully
I have closed the corresponding issue on github
Thanks for all the work integrating FTC specific requirements into the ongoing Bitcoin developments.
There is the point that it would be less work on going to continuously integrate the latest patches in to DEV version. They can be testable of new features, which we can choose to include or schedule hard or soft forks more sensibly…
Just a note that it might both looking at some other (alt coin) work (later) eg
regenerating the Genesis block - 2016 Doge : student project.
Today, I revert stealth address in 0.11.2
give-me-coins.com run 0.9.3 and accept transaction with stealth address .
I push a patch for 0.11.2, fix ACP issue.
I’ve just been reading about the changes in handling the Blockchain for the v4 database, particularly interesting was non contiguous blocks in the new format.
This is quite a big change which we need to careful and steady about implementing. There is no need to create additional problems by rushing it out now. FTC still has a release to finish off, test and improve with 0.9.3.X.
This is supposed to be financial software, we absolutely must go through a release procedure such that binary builds are checked and on independent, secure downloads.
There are enough people / time to do that, whilst @Lizhi has had to do it all himself, he need to bring people along now, by letting us catch up. For instance, we have fixed build instructions and such, there is no help for the new features, Alt-4 etc keys don’t work … all of which are fixable, test on v2 – move to v4 already with enhanced new features and tested.
I was just looking at Litecoins new forum / website and I note they thing 2.5 mins is fast enough transaction time and they don’t need v4 upgrade yet…