I am just catching up on what's going on -- been working at the job that pays the bills...
For those following this -- since it gets hard to follow from the stream and also in the internal Crown Slack, I will offer a summary of what I think happened and is happening. Other members of the Crown team are welcome to affirm or correct me if I miss something or get something wrong -- but I think some of the guys in Europe are getting some sleep after a long day.
SUMMARY
1. The Crown update which the team released had enforcement turned on -- meaning that the new nodes rejected connections from the old nodes.
2. In the process of testing the team had not discussed (to my knowledge) whether enforcement should be turned on or not -- because enforcement was one of the many features which hadn't worked in the old code.
3. The team's plan was to do a managed fork at block number set for approximately next Monday Feb 13th -- but instead has been working to manage the unintended fork which occurred as miners and thones began running on the new code release.
4. Due to the fact that large miners hadn't updated their wallets yet -- NOT THEIR FAULT -- they were told they would have some time, and I believe that not all of the pools had necessarily been contacted before the fork happened.
5. Due to enforcement being on in the release, the fork was a necessary result of the first miner who started running the new code. And because at that initial point, after the first mining installed the new code, less hashing power was working on the fork/network/blockchain which the new release mines on -- the fork which the new nodes and new code is running on has a shorter blockchain.
6. The default way that a node knows which blockchain is valid is by it's length -- so this un-anticipated fork has created a blockchain which is (or was until al little bit ago in my understanding) being mined by miners running the old buggy code. So as long as the blockchain mined by old-buggy code is longer -- it will be preferred as "valid" by the wallets. This is part of the logic of mining and wallets -- the longer chain is always the one which has more compute power invested in it and right... except...
7. BUT in this case the longer chain is running on old buggy code, and going with the longer chain would only punish the folks who updated their code, which includes CCEX, the exchange.
8. So some of the team members have purchased hash power and are aiming it at pools running the new code -- and the pools which hadn't updated (once again -- not their fault, but ours for having enforcement on in the release), have been contacted.
9. CURRENTLY:
Chainz & CCEX show the fork being mined on the new code:
https://chainz.cryptoid.info/crw Blockpioneers shows the fork being mined with the old code:
http://crw.blockpioneers.info/index.php The has rate for the shorter chain / new code is higher than for the old code / longer chain. So the new code chain is catching up.
10. The core team takes full responsibility for fucking up on the enforcement. No dancing around it. We didn't realize that infernoman was going to build a new codebase where things actually worked just like they were supposed to. And I think infernoman may have surprise himself.
11. I would like to thank the members of the core team who were working and sweating managing this process today.
12. There will always be mistakes and surprises and the key to this being a successful team and project will be in how we deal with the mistakes and surprises -- and how we communicate with the community. This fork was an unforced error on our part -- that is disappointing to us and no one should really be happy about it... but the team and community have responded constructively and pivoted -- and while the problem isn't resolved yet -- everything is moving in the right direction.
Hopefully that makes sense.
And for what it's worth, one of the lessons of all of this is that IN THE NEXT RELEASE ENFORCEMENT WILL BE TURNED OFF INITIALLY....
