Topic: [ANN][CRW] CROWN (SHA256) | Platform | Governance | Systemnodes | Masternodes | - page 150. (Read 317079 times)

No that's BS
Every time this coin look like it has progression it gets hard forked, you are not going to be able to take it to the next level fixing things that are not broken.
Do you realize how annoying it is to update to the new client only for it to be re updated days later then log in and see that your master nodes are not on the correct fork . You guys know damn well I support this coin but I also am going to give you honesty.

Hardforks are a sign of progression. Doing it improperly is a sign of inexperience -_- we still have some things to learn. But at least we're not afraid to admit it

ffs I'm going to be honest. Stop hardforking.
edit: you guys keep trying to fix something that isn't broken.

The intention was to have everyone updated to the new chain, and the theory was that enforcement wouldn't quickly enable. allowing blocks from the 0.9.5(70020) clients to be accepted by the new nodes. when enforcement turned on(which was unexpected) it started denying them and that's when we started to see the forks. then as new clients connected to the longer chain and to more 0.12.0.60(70030) nodes people start their thrones, and BOOM another fork. and so on and so on. so there was probably a few more forks than both of us saw even. but c-cex/infernopool were the original fork.

with the new protocol version 70040, it only connects to the 70030/70040 nodes. so as the 70030 nodes go offline, the 70020 nodes will go with them.
protocol version 70040 nodes have enforcement disabled, but still accept blocks from the old 0.9.5(70020) nodes that are connected to 70030 nodes that dont have enough thrones to enable the enforcement.

Alert keys were invalid, and explained incorrectly to parts of the team by previous developers which is definitely no fault of their own. I helped to explain that issue as well. and update all of the spork/throne/alert keys correctly. Now we can alert the network if there is issues, as well as disable/enable sporks without forcing a new client version.

In short it was a shit show absolutely nobody was expecting, and something that wasn't noticed during testing, since we only had a small number of thrones running during the test.
But it's fixed now ! So we're on the right track. Sometime in the next week most likely I will enable the enforcement again. once everything seems stable.

hmm.. but your theory is still not right..
it seems that now all clients are on the "long", "new" chain.. ( not on the old one, wihich was the intention )
but whe have 6/4 blocks AND 5/5 blocks.. so new and old clients..
i did not loose the coins of the 8 hours.. indeed, i did not even need to stop mining..

nevertheless, we have a network that is on one state. so this seems to be done..
mining again now.. ( different address )
auxminingaddr=1KVdipnBtM4hH1uRsCeisQSJtxN7caQzHJ
( pool has no Name, call him Fred )

-Yupp you are correct in saying that after swapping to the new client you still had issues because the blocks were still technically there.

Enforcement is a bit tricky and im still learning a bit about it myself, but basically as the masternodes come online they have consensus of which node needsto be paid to keep everything even. all of these nodes have to agree on the node to pay. if there is a client that doesnt agree. they will disconnect from that part of the network, and usually end up forking. all thrones should agree on the next node to pay, otherwise they get removed. atleast that is my understanding of it all.
(and you seem to have a pretty good understanding of most of it. the biggest thing being the enforcement issue.)

-ccex was one of the first ones to update. so they in turn jumped onto the new client before enforcement was enabled. and once it did enable it didn't affect them at all


Currently with the protocol version 70040 client it will not connect to any 0.9.5 nodes, so eventually they will get cutoff from the network once the protocol version 70030 nodes update to remove enforcement.

hmm quite good summary, but some points are wrong
- i was on the longer chain with the old client, but then also was on the same chain after updating to the new client ( maybe the problem was, that i did not delete all files, so the chain was traferred to the new client? )
- i dont understand enforcement completely.. but i think its an team play of blockchains and masternodes.. so it might be even more complex, with an old node supporting the new chain and vice versa.. so we were maybe even spilt in 4 subnets ( old nodes, new nodes, old chain, new chain )
- finally i don't understand why c-cex was on the shorter chain? ( you said they had updated and the client always takes the longer chain.. )

Merged mining always has its own limit.

It it hard to overcome..

From wan.

All lost funds will be compensated from our DEV fund. Please everyone send me a PM or paste it here.

Send me an address to refund some of the CRW that was mined, and you should be able to connect and get back on the correct chain now. Both blockpioneers and chainz reporting the same block, with c-cex updated and infernopool mining. Working on getting xpool online.
Again if you could set auxminingaddr= and provide that address for block statistics that would be greatly appreciated

Working on building the new clients now. If you build your own clients please update NOW. MINERS ! Please wait until we've figured out the forking issue before starting to mine.


Wallets coming online now. https://github.com/Crowndev/crowncoin/releases/tag/v0.12.0.61

You'll notice that the protocol version has been increased
    "version" : 120060,
    "protocolversion" : 70040,

pi@raspberrypi:~/.crown $ crown-cli getblockhash 1246157
60d4bc8a12731505e889940a367cb48cfca3c69be6cb4e2771be36a12d282e31

For a list of already updated nodes confirmed to be on the right chain. More will be added as they come online.
https://www.whatsmydns.net/#A/crw.infernopool.com

ARM - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.1-arm-linux-gnueabihf.tar.gz

32bit windows - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.3-i686-w64-mingw32.tar.gz

64bit windows - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.4-x86_64-w64-mingw32.tar.gz

32bit linux - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.5-i686-pc-linux-gnu.tar.gz

64bit linux - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.6-x86_64-unknown-linux-gnu.tar.gz

OSX - https://github.com/Crowndev/crowncoin/releases/download/v0.12.0.61/crown-177.7-x86_64-apple-darwin11.tar.gz

Alright to get through this fork issue, i'm going to be working with xpool and mmpool to try and get all of us on the correct chain. @mmpool could you please update to the latest version on github? the update disabled enforcement as well as cuts off 0.9.5 nodes and updates the alert keys to the proper keys.

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....
 

Thank you for understanding, I'm doing my best now to get everything back in line. mergedmining.com is on the right fork. and im getting infernopool there now. once we pass the old fork it will be much easier for miners to reconnect to the correct chain and start mining successfully.

no, its merged in my own pool software, i can not switch to other pools on the fly
the explorers show an actual difference of 2154 CRW for these 8 hours
plus additional time we need until the solution

but because of the netsplit, etc.. it think 50% of this will be fine..
and i also don't want a "refund", just a bounty, so maybe 10% will be perfectly ok..

You could instead point that 1Ph to a pool that's mining the short chain?
If not, please work out an estimation of your losses.. Thanks

verifymessage 17iZgAE3cSEYxynXa1g5GmbxFEj1HPpLDc IPEuwZKPEEZrh3mvqCXLPiph9v8nonFVGqeyqIHJPJ4aVkQfenG4c/sqlNmk5AixEbQTiDEtUiU/r/YEsgSMGYM= "I stop mining now in favour of the short blockchain. i control around 1 PH. so i loose at least 8 hours of mining. a compensation would be nice: 17iZgAE3cSEYxynXa1g5GmbxFEj1HPpLDc"

crackfoo, would it be possible to direct the 2 x 300th to mergemining pool of sixoffive? We give you a bounty   We know this pool got it right

Correct (mergemining.com)

Mergedmining is this your pool? 600 th s?

https://chainz.cryptoid.info/crw/extraction.dws?3.htm