Crown June Fork Analysis Report

Overview

On Tuesday morning June 12th one of the community members noticed a split in the Crown network. Crown Developers started investigation. The network forked into two chains. The first analysis let us make conclusions that the sub-networks could not agree on which Masternodes/Systemnodes to pay and the nodes were rejecting blocks from each other. Further investigation revealed that two (supposedly) miners had built Crown Core software from not officially released version. The changes were partially merged to the master branch because the team was preparing the release soon. The new version had a different protocol version, consensus changes in the governance system etc. So eventually the nodes with different versions started rejecting each other and composed their own sub-networks with different lists of MN/SN to pay because that list is dependent on the previous blocks.

Fork Fix

Sporks administration, reindex of seed nodes and some other team controlled nodes helped to switch the network to one of the forks which at that point in time considered as the best-chain. Eventually it turned out that both chains had approximately the same difficulty and the same hashing power so the network had spitted evenly. The post-analysis showed that the ‘forked’ chain had the bigger amount of transactions than the ‘current’ chain but there was no effective way to determine that during the fork fix. Anyway, the half of all transactions propagated during the fork time were included in the both chains. The transactions not included in the current chain are reverted to the previous addresses.

Transactions List

People who can not locate their funds can find their transactions here. The page ‘forked-chain’ contains all the transactions not included in the current chain highlighted. The Bittrex transactions are highlighted with blue color. You can create a support ticket to Bittrex, the Crown team has refunded all the loss to them.

Actions to prevent forks in the future

- Create emergency guidelines in case of unintentional forks
- Implement forks monitoring mechanism, notify the team in case of possible forks
- Redistribute hashing power
- Implement alternative consensus protocol (PoS)