How I Helped Save a Cryptocurrency

Note: This is a repost of the article that appeared on Medium. It is being reposted here, unaltered except for this message, to ensure the article is forever available on a blockchain, rather than a central service that could disappear overnight. The original article is available here.

And, in the process, reduced the impact of one of Satoshi Nakamoto’s consensus mechanism’s greatest flaws

TL:DR- I helped implement interchain linking of the GameCredits blockchain with the Komodo blockchain, greatly reducing the impact of the double spend attack. The KMD chain actively witnesses the GAME chain and notes down block hashes, while the GameCredits client refers to the Komodo chain for consensus on history.

Edit: A previous version of this article had an erroneous dollar figure in the title, which was leftover from my draft. My apologies for this oversight. It’s been removed.

What is GameCredits?

GameCredits is a Proof of Work based cryptocurrency using the Scrypt algorithm. Network hash rate on average for the last few weeks has been 2TH. Overall, the cryptocurrency is pretty small but has a dedicated user base as it is a niche currency for gamers to use to buy games and in-app purchases.

Due to its low network hash rate, it has been a target of 51% attacks and double spends recently by one or two actors (based on tracing the beneficiaries’ public keys of the attacks)

My Role with GameCredits

As an open source developer, I helped the team execute various changes to their network in the past couple months. These changes include: backporting a hard fork to the old 0.9.x client to bring back integrity to the network, update their codebase to match Litecoin’s 0.15.x branch, and help close off a vulnerability that was introduced in March 2015 but not exploited until March 2018. All of this within a span of about 5 months.

The Attack

In May of 2018, the team and I noticed an attack on the GameCredits network. This attack was not a vulnerability within the code. Rather, it was a vulnerability at the consensus level — a miner was able to amass several times the network hash rate to force his own chain onto our system. He was able to do this by creating valid forks. He mined up to a certain block on the public chain, then set his nodes completely private — isolated from the internet and the public chain, but peering with each other. At the same time he executed a Sybil attack on the public network causing a delay in the next block and a difficulty spike. While this occurred, the miner was successfully mining blocks on his own valid fork in the private network. After some time, he turns his private network public again — while deploying up to 250 new nodes (AWS use is suspected). The large number of nodes caused legitimate nodes to believe his chain had consensus in the network and blocks were rolled back on the legitimate chain. As of this writing he has been able to roll back a total of 243 blocks at separate intervals, essentially executing a double spend attack on the network.

Why this worked: not only was he able to get the quicker block for the initial block of the fork (sometimes by just a second), but his private blockchain had more blocks than the public one. Nakamoto consensus states that assuming all other variables are in consensus, the blockchain with the longer length is the true chain. In bitcoin, this makes perfect sense. In smaller cryptocurrencies utilizing PoW, which don’t necessarily have the defense that bitcoin does (e.g. the network hash rate), its application is questionable at best.

To give a visual example of this, let’s take a look at figure 1.

Figure 1. Nakamoto Consensus Example

Also, this type of attack is very expensive to execute but achievable because GameCredits hash rate is relatively low — only 2 TH/s at its best. The attacker used up to 5 TH/s — more than twice the current hash rate — to attack the network.

The attacker left his signature on these attacks as well. All of the blocks mined by this entity are “version 3” blocks, which was a version that was never introduced to public. We believe he was using a modified 0.9.6 client.

To implement a fix to stop the attacker from succeeding so often, we needed:

• To ensure that legitimate blocks gain priority in the consensus system and cannot be overwritten in this type of attack.

• To add extra security to prevent further attacks like this.

• To do it quickly and transparently to the end user to prevent services from having to add extra code or logic to their systems.

A little note on 51% Attacks

A 51% attack is something that occurs on Proof of Work networks where one entity gains significant hashrate (51% of the total) and gains control of the chain. The entity can accept, change, or reject blocks at will, obviously giving his or her own blocks the priority. In what is supposed to be a decentralized network, this type of attack brings centralization by giving one party the ultimate control of the blockchain.

We had a handful of options available to address this:

1. We change the network from a Proof of Work to Proof of Stake, or some hybrid network

2. We convert the coin into a token and forget mining and our own chain all together

3. We interlink chains with another network to provide extra defense against these attacks and maintain Proof of Work

We didn’t want to convert to an ERC-20 token. We also didn’t feel ready to convert to a Proof of Stake setup… we wanted something that was minimally invasive. We began exploring option 3: interchain linking.

Unleash the Dragon

After researching the sphere, two projects were identified as candidates to help stop this bad behavior on the network. We evaluated both, and settled on the one that was most promising and ready to address our needs. That project was Komodo.

The Komodo platform offers notary as a service (NaaS). Utilizing NaaS, the GameCredits blockchain is queried at a predetermined interval for its block height and the hash of the block. Each Komodo notary node does this with a local copy of the GAME blockchain. In total, there are 64 notary nodes, so each of these is doing this processing to determine what the peers of that node are stating the correct chain is. The Komodo chain then finds a consensus among the 64 notaries in which chain is correct. It notes down the block hash and height of the correct chain and submits a transaction on the Komodo network with a hash of this information. This process is the first half of the notarization. This data is stored as a message in the transaction, which eventually gets included on the Komodo blockchain. The transaction ID of this is then sent to the GameCredits blockchain for storage — fulfilling the second half of the notarization process. By doing this the GameCredits blockchain makes a reference to the Komodo chain and the Komodo chain makes a reference towards the GAME blockchain.

Komodo also notarizes itself against the largest Proof of Work blockchain in existence: bitcoin. Komodo’s chain is secured by this notarization process. To successfully attack Komodo and reverse blocks, one must successfully attack and reverse blocks on bitcoin- a near impossible task to execute currently. Near impossible because any big party with the financial and technology resources could probably do it, but no such party exists today.

Therefore, notarizing GAME against Komodo means we indirectly notarized against bitcoin.

With this implementation, any time the consensus of older blocks is challenged on the GameCredits network, like it is in a double spend attack, the client has logic to check against the notarization value that was most recently stored. If the blocks don’t match the notarization values, the newly formed chain is rejected. This changes the consensus from longest chain to publicly witnessed chain. Even if the attacker mines a longer chain, the fact that the attacker’s older blocks were not witnessed publicly is grounds for rejection of his fork.

By having a frequent interval of this process happening, we greatly reduce the number of older blocks that can be overwritten in such an attack. An attacker can only overwrite blocks that have not been notarized. And, if our interval is small (such as 10 blocks), that means that theoretically a bad actor can only lay claim to the most recent 10 blocks before a notarization occurs to lock those blocks in.

Let’s visualize in figure 2 how this changes the block acceptance compared to figure 1.

Figure 2. New Consensus Mechanism due to Komodo Notary implementation

Wrapping up

GameCredits is the first coin to implement this system outside of the Komodo system, and I strongly believe it will become a reference implementation for other small, upcoming projects that want to secure their chains against double spend attacks.

I’m also glad that I could bring this solution to the GameCredits team and that we worked together with the Komodo team to implement it. To utilize the client that has this integration, download GameCredits 0.15.2 from the project’s official Github account at https://github.com/gamecredits-project/GameCredits/releases

You’ll notice my name in the release notes and the commit history as further proof that I am an active consultant with the team.

Disclaimer: All opinions in this article are my own and do not represent those of the GameCredits team.

I’m available on the following social platforms: Twitter and LinkedIn

Further reading on this can be found at the links below (to be updated as new articles come out):

https://medium.com/gamecredits/gamecredits-network-update-0-15-2-komodo-integration-d6eda64ea368