How GIN saved me from troubles with MARC’s Fake Stake Exploit
A few days ago the DLS from the University of Illinois published their findings regarding vulnerabilities primarily concerning Proof-of-Stake blockchains recycling code from Bitcoin and PIVX. Due to the amount of cross-polination of ideas and code reused across cryptocurrencies, this exploit affected at least 26 currencies, and most probably another dozen or more lesser lesser known coins.
The exploit enabled attackers to disengage honest networks nodes verifying transactions on the blockchain, without the attacker requiring to commit any stake or collateral to the network, meaning an attack could always have been carried out economically from an attacker point-of-view. A second attack using the same exploit variables could have enabled an attacker to fake his stake on the network, receive blockrewards and sell those on the exchange. The exploit effectively broke the tokenomics of the chains involved, and goes to show how Proof-of-Stake is still very much a research project, while Bitcoins Proof-of-Work has proven invulnerable to such attacks for more than 10 years now.
One of my favorite coins right now, MARC, is one of those coins having recycled code and adopt the vulnerability in its code base.
MARC wallet loading
On Sunday the MARC developers then released an updated wallet that was going to fix the vulnerability and make the blockchain secure again. I was quite happy to see a swift reaction from the team and went about the backup and update of my MARC wallet immediately. Though, this was my first time upgrading a blockchain wallet holding significant assets in locked coins, the process was straightforward, besides having to learn how to add networks nodes to the wallet manually.
My wallet update was done within an hour of work and research, and another 2 hours of waiting for the blockchain to resync. However, the update meant that all Masternodes on the network had to reboot and thus blockrewards would come in again only after another days wait. As this procedure was the same for all masternodes, I wasn’t too worried about an unfair disadvantage and just waited for my nodes hosted on GIN and Clicknode to restart properly.
However, my nodes hosted on Clicknode, and as far as I know nodes hosted on Zcore, have not updated their wallets and VPS fast enough, so that their hosted nodes ended-up on different diverging forks of the blockchains. This is due to the lost connectivity, causing nodes to be out of sync with each other and creating conflicting checkpoints, resulting in a chain split with stacked nodes.
In summary, I experienced the service on the GIN platform the fastest and most reliable among hosting platforms and moved my masternodes from competing cheaper platforms back to GIN this week. Quality service does not come free, and the $5 hosting fee per month once again seem well spent on GIN, especially considering that I would have missed out on blockrewards potentially worth more than $5 if I had stayed on platforms unable to restart the masternodes properly.