DEV: Please reply to Suchpool's PM, both of us are having the same situation with the wallet and we need a solution for this as our miners can't withdraw their coins.
Every update breaks things even further, yesterday's update pretty much made the wallet not sync properly, and previous updates.....
If you can contact me with the final audit numbers I'll see what I can do to help. I personally don't have very many seeds, but I can buy them off the market once we can get bittrex online. They still haven't opened the wallet, which at this point may be a good thing. I'll contact them shortly.
As I stated above, we will NOT be fully auditing the 2000+ blocks.
Given the price of the coin, I don't have any interest into spending a ton of hours auditing the whole thing. I will just buy them back myself, my time is worth much more than the cost of this.
What I am looking for an explanation into what happened with all these forks and where did those coins go?
Also, we noticed that by comparing our blockhashes, they would sometime be different then on a second checkup they had changed and were now matching, hinting there couldve been auto-corrected forks. Is it possible the network tried to auto correct forks as they occured?
I understand.
Here's what happened with each fork:
Fork 1) (v1.0.0 - fix without revision update) Update included a small piece of test code that slipped by the date check. The test code validated all blocks prior to the time check, but new stake blocks were minted improperly. Without a block explorer, it was difficult to tell what the problem was, but I saw a hole in the code that allowed for blocks from the future to be minted, and so I thought that may be the problem, and I attempted to fix it.
Fork 2) (v1.0.1) Fork caused by clocks that were out of sync. A block was minted seconds too soon for some clients to confirm it. The code prevented clients from resyncing to the proper chain, because the fix I chose to solve the previous issue checked against the current time instead of the block time.
Fork 3) (v1.0.2) This one was actually pretty clean. Everything sync'd properly and the changover was relatively smooth. 1.0.2 effectively confirmed everything on the 1.0.1 branch, but checked the best block time instead of the current system time.
Fork 4) (v1.0.3/v1.0.4) I created a testing repo on github and sync'd the code for 1.0.3 accidentally to the master branch. Recognizing my error I switched over to the testing repo while testing this release. The 1.0.3 code had changeover times that were set too early to check that the current chain would be loaded as valid in the new code, but conversely allowed blocks to be minted with the new code before the changeover was set to take place. The 1.0.4 code updated the timings, and I sync'd those changes to github and produced the wallets based on that code. I then announced everything and told everyone to update, not realizing that my github sync had gone to the testing branch, and not the master branch.
The only people effected by this particular fork were linux users and servers. There were only 4 running this code that I ever saw. All windows wallets were correct, and everyone running windows wallets were on the correct chain.
Current:
I've double and triple checked that the github source is the same as the wallet source, and the changeover times are 100% accurate and correct. I've checked that the wallets sync properly, though they do take pause through some areas of there chain where there was significant forking. I've checked for all bugs I can think of forwards and backwards, examining the limits on both sides of the 64 bit integers that the code depends on. I've found a few bugs that I can't fix without risking more problems, and so I have chosen to just tell everyone about the bugs I've found that will only exist while the staking interest is 269% daily, and will no longer be a factor once the growth period is over.
The changeover will be as smooth this time for linux users and server administrators as the windows wallet transition was for windows users - as the problem the last time was slightly different code. I guarantee the code is identical this time, and I apologize for the mixup. I've been humbled and mortified and I'm doing everything I can to try and make sure nothing like that happens again, ever.
As for chains autocorrecting themselves, yes I'm sure they did, since each iterative update considered blocks from the all previous updates as valid, and the blocks generated by the new updates could have been orphaned. So blocks that would be valid in the new code were orphaned in the dominan blockchain produced by the older code. This is why there's the syncing issue, because there are orphans that the new code would consider valid, but because most of the code was on the previous version at the time, the new code autocorrected itself to match the dominant chain created by the former version. Unfortunately, once this autocorrection started taking place, there was no natural fork for the subsequent new clients to take. The current code will only sync to the current chain now, but it will take some time to find the right chain. I plan on checkpointing through this period so that clients in the future will sync much more quickly.
As for the issue with different blockchains, there are still many old versions running on the network, each one updated at a different time and against different clients running different versions of the code. I've checked my nodes and there are still people running 1.0.2 connected to it, eventhough they couldn't possibly presently be on the correct chain. Syncing the blockchain solves the issue with the current client, but may grandfather in something that wont sync with the next client.
I personally haven't had to sync my blockchain on my home PC with the new 1.0.5 client, likely because I sync'd a fresh chain with the 1.0.4 client. But after loading the latest wallet, I did sync with the 1.0.5 wallet anyway, to be sure that the syncing process works properly. It takes about 5 minutes for my pc to sync up.
