A few weeks ago, Bitcoin Gold was announced to the world. To many novice Bitcoin users and investors, this seems like a repetition of what happened with Bitcoin Cash, essentially giving you “free coins”. However, some things are different this time around and it is important to fully understand what is going on to determine if you should be happy about it. In this article, I’ll try to explain how blockchain forks work, and what I evaluated about Bitcoin Gold as a specific example of why you should be careful.

Back to the basics: How do blockchains work?

In order to understand blockchain forks, it’s imperative to first understand a few basics about blockchains. There’s a lot of interesting resources to discover this, best of all the original Bitcoin whitepaper by Satoshi Nakamoto. But since the full whitepaper might be a bit overwhelming, I’ll try to cover the basics in this paragraph.

The process of finding a new block to extend the blockchain is called mining. A block in the (Bitcoin) blockchain is secured by a system called Proof-of-Work. Proof-of-Work systems use cryptographic hashing algorithms to make the act of mining a block a complex computation.

Each block has a header that contains a hash value that is derived from the hashes of all included transactions using a Merkle Tree. This makes the block itself tamper-proof, because changing anything to a transaction, or removing or adding one, would lead to a different Merkle Root.

The header also contains the hash of the previous block, to secure the chain's integrity. This way it is impossible to “insert” a new block in between, or move the block to another point in time.

Lastly, the miners have to find a random value that they included in the header, which makes the computed hash over that header a value below a particular target. The lower this target is, the longer it will take to find the right random number. So this target influences how many hash operations are needed to find a correct hash.

Tampering anything in the block header (the previous block’s hash or any transaction) would make the hash invalid. This is how the chain and its contents are secured.

The mining process follows a set of consensus rules. In case of Bitcoin Core, these rules are:

The block’s Proof-of-Work hash is calculated using the hashing algorithm SHA256

The target block time is 10 minutes

The difficulty target is adjusted every 2016 blocks

The block cannot be bigger than 1MB

As long as new blocks follow these rules, and the rules don’t change, there will be no fork in the blockchain because all clients will accept the new block.

What is a fork?

So next is the term “fork”. To add to the possible confusion, a fork can be done on two levels, so i want to explain both of them properly.

Fork of the source code (software)

Because Bitcoin is open source software, anyone that has a potential improvement to it can do two things with his contribution. He or she can submit it to the original Bitcoin Core project and request the developers maintaining Bitcoin Core to merge their changes into a future release of Bitcoin Core.

The other option is that they create a fork of the source code (essentially a copy of it), and include their changes in the copy. This way, they are not bound by review from the Bitcoin Core team, and they can release the altered software as a separate product — as long as they credit the original creators and adhere to the licensing terms.

Many of these forks of Bitcoin’s code exist and are called “altcoins”. However, almost none of these forks also fork the blockchain.

Fork of the blockchain

Even when you have forked the source code, you don’t have to fork the blockchain. You can start your new and improved cryptocurrency from its own Genesis block, essentially beginning a new coin. Other Bitcoin source-code forks have done this, including Litecoin, Vertcoin, Dogecoin, and many others.

So none of these altcoins also fork the Bitcoin blockchain. Forking the blockchain is something different. A fork in the blockchain is caused by introducing a new set of consensus rules at a particular block height.

An example — Bitcoin Gold

Bitcoin Gold wants to change one of the consensus rules in Bitcoin, namely the Proof-of-Work algorithm. Their new consensus rules dictate that the Proof-of-Work algorithm should no longer be SHA256 but be changed to Equihash. The rest of the rules stay the same. So blocks are still 1MB, and difficulty adjustments happen every 2016 blocks.

Now what happens when miners start mining using these new consensus rules, is that they will broadcast the block they “solve” (when they’ve computed the random number that makes the blockhash matches the target) to a Bitcoin Core node. This node will reject the block because the SHA256 hash of the header most likely doesn’t match the intended target. But Bitcoin Gold nodes will accept the block because the Equihash hash does match the target.

At the time both clients are operational, they will start rejecting each others’ blocks and at that time a fork is formed. Bitcoin Gold clients will only accept blocks valid according to its Equihash based consensus rules, and Bitcoin Core clients will only accept blocks valid in their SHA256 based consensus rules.

“Free coins”

Because both blockchains followed the same consensus rules up until the moment of the fork, the coin ownership before the fork is also the same. So, if you owned Bitcoin before the Bitcoin Gold fork happened, you’ll also have the ownership of the Bitcoin Gold. And if you spend your Bitcoin after the fork happened, you will not have spent your Bitcoin Gold (because your transaction is in a block that is rejected by the Bitcoin Gold clients).

This seems like “Free coins” and this is why people seem to be happy with the Bitcoin Gold (and other) forks.

Red flags in Bitcoin Gold

However, in my analysis i found a few red flags to Bitcoin Gold that should make you suspicious:

Bitcoin Gold’s fork is not public —According to code activity and comments on Github, the developers forked the chain (or will fork the chain) from a particular block height they call a “snapshot”. They will release the chain to the public at a later date, in stead of immediately. This “downtime” will give them the capacity to mine on it privately , which is a giant red flag.

—According to code activity and comments on Github, the developers forked the chain (or will fork the chain) from a particular block height they call a “snapshot”. They will release the chain to the public at a later date, in stead of immediately. This “downtime” will give them the capacity to mine on it privately , which is a giant red flag. Pre-mine — Before releasing the chain to the public, the developers have decided to privately mine 16,000 blocks giving themselves 200,000 Bitcoin Gold as block reward. This is not only completely unnecessary but also purely devised to enrich them. It’s also unclear if the creators will include transactions from the Bitcoin chain into these pre-mined blocks — the transactions since the snapshot might therefore not be present on the Bitcoin Gold chain.

— Before releasing the chain to the public, the developers have decided to privately mine 16,000 blocks giving themselves 200,000 Bitcoin Gold as block reward. This is not only completely unnecessary but also purely devised to enrich them. It’s also unclear if the creators will include transactions from the Bitcoin chain into these pre-mined blocks — the transactions since the snapshot might therefore not be present on the Bitcoin Gold chain. Replay protection is not created (yet) — Replay protection in a hard fork situation protects you from losing coins on either side of the fork. Essentially replay protection should ensure that a signed transaction on one side of the fork is invalid on the other side. Otherwise someone can take your (signed, valid) transaction from the Bitcoin Gold chain and publish it again to a Bitcoin Core node (since transactions themselves have no Proof-of-Work they are formatted equally). If this is done, your “normal” Bitcoins get sent to the same address as you transferred them to on the Bitcoin Gold chain. Until replay protection is in place, never ever use it or you risk losing coins.

— Replay protection in a hard fork situation protects you from losing coins on either side of the fork. Essentially replay protection should ensure that a signed transaction on one side of the fork is invalid on the other side. Otherwise someone can take your (signed, valid) transaction from the Bitcoin Gold chain and publish it again to a Bitcoin Core node (since transactions themselves have no Proof-of-Work they are formatted equally). If this is done, your “normal” Bitcoins get sent to the same address as you transferred them to on the Bitcoin Gold chain. Until replay protection is in place, No test-net — Normal blockchain development first launch a test-net so that the quirks can be ironed out and the software is proven stable before public launch. It seems the Bitcoin Gold team is in a big rush getting their software out, and the lack of running on a testnet for some time gives me an impression that the quality will be suboptimal.

Conclusion

Even though I think the idea behind Bitcoin Gold isn’t bad at all — the idea of reducing the centralization of mining is very decent — I’m afraid the execution of Bitcoin Gold is poor and overly rushed putting people’s money at risk.

Besides that, there’s already a cryptocurrency that pledges to the same goal of miner decentralization, which is Vertcoin. This currency has been operational since 2014. So the idea isn’t even new.

Full disclosure: I’m also a (volunteer) member of the Vertcoin Development Team.