My thoughts on Bitcoin Gold and SegWit2x hardforks UPDATED

My main goal with this article is to inform people about the upcoming forks. If you believe there is any misinformation or mistakes, feel free to leave a comment or to contact me on twitter. I’ll be updating this post now and then.
I suggest the reader not to take this publication as advice. Try to inform yourself about the risks involved in a hardfork event prior to acting or making decisions.

1. HARDFORK
A hardfork stands for a substantial change to the protocol of a blockchain network, which results in a protocol replacement and a divergent break from the preceding chain. It enables to create a new version of the software (or a new blockchain). When a hardfork takes place, the previous blockchain is copied to create a second one with a different set of rules. All nodes and users will be able to follow the old path (Blockchain A) or the new path (Blockchain B) (Fig. 1). However, either paths requires user adoption and mining support in order to survive. Furthermore, to run the new version of the blockchain, users are required to upgrade their software protocol.

Hardforks are usually executed when part of the community does not feel contented with the current blockchain protocol, leading to the creation of a new one (with a new set of rules). They can also be used to add new functionalities or during emergency situations in order to replace a problematic or unreliable protocol.

Thus, hardforks can be used to change or improve an existing protocol (possibly leaving the old version behind) or to create a second independent protocol that runs in parallel to the original one. If both chains have sufficient users and miners support, there will be two active running protocols with distinct rules (and possibly distinct communities, coin name, developers, and so on).

2. REPLAY ATTACK
Considering the cryptocurrency blockchain context, the replay attack consists of a network attack where a valid (and signed) transaction executed on Blockchain A is replayed and validated on Blockchain B. In order to prevent replay attacks, any hardfork should implement a replay protection — negating any possible conflict between distinct networks.

Whenever a new protocol is created by a hardfork, the new blockchain will have the same ledger history as the old one until the exact moment of the fork. In other words, the pre-fork data is identical for both chains (Fig.1). Due to this shared history, the pre-fork existing data from Blockchain A will be cloned on Blockchain B, causing both chains to have the same copy of the ledger (identical past transactions, balances, keys and addresses). That is the reason why Bitcoin (BTC) holders got the same amount of Bitcoin Cash (BCH) during the hardfork of August 1st, for example. However, the shared pre-fork data is also the reason for some vulnerabilities that may arise when hardforks are not efficiently protected. Different hardforks deal with replay attacks in different ways. If a hardfork occurs without proper replay protection, post-fork transaction could be equally valid on both chains and someone could pick up a broadcasted transaction validated on Blockchain A and replay it on Blockchain B. Note that there is no need for the attacker to know your private keys, since both chains share the same pre-fork data and the transaction was already signed by you on Blockchain A.

For example, if Bitcoin Cash hardfork did not have a strong replay protection, any post-fork transaction using Bitcoin could be a target of replay attacks. If that was the case, sending 5 BTC from one address to another would create a valid transaction on BTC Blockchain that could be replayed and validated on Bitcoin Cash blockchain as well, causing not only 5 BTC to be sent but also 5 BCH (from/to the same addresses, using the same private keys signatures). Fortunately, Bitcoin Cash successfully implemented a Strong Replay Protection, greatly reducing the potential for disruption for both networks.

2.1. STRONG REPLAY PROTECTION
A Strong Replay Protection aims to make transactions valid on Blockchain A invalid on Blockchain B and vice-versa. This is done by adding some kind of marker on each transaction, ensuring that they can only be validated on their respective original chain. Taking Bitcoin Cash hardfork as an example, a Strong Replay Protection was implemented in order to make Bitcoin transactions invalid on Bitcoin Cash network and vice-versa. When this type of replay protection is implemented, both chains are automatically protected and there is no need for users to take any additional steps nor to be concerned about replay attacks.

2.2. OPT-IN REPLAY PROTECTION
Unlike the Strong Replay Protection, the Opt-In Replay Protection requires additional steps in order to prevent your transaction from being replayed. In other words, there is no automatically implemented protection. Any post-fork transaction would be vulnerable to replay attacks by default, unless you take the necessary steps to prevent them. In this case, it is up to the user/sender to make the required manual adjustments in order to be protected.
PS: Any address generated after the hardfork will be exclusive to its own chain and will not be duplicated.

3. BITCOIN GOLD
Bitcoin Gold (BTCGPU) is a hardfork of the Bitcoin blockchain scheduled to occur on October 25th. According to their official website and open source repository, the fork will take place at block height 491,407 — giving birth to a new cryptocurrency. The new network will probably go live in early November. The new protocol will change the proof-of-work algorithm from SHA256 to Equihash (taken from ZCash project), making specialized SHA256 mining equipment (like ASICs) inefficient for mining the BTCGPU blockchain. The idea is to allow miners of the new chain to mine Bitcoin Gold using normal CPUs or GPUs, possibly leading to a more decentralized mining infrastructure.

After the fork, all Bitcoin holders are expected to receive the corresponding amount of BTCGPU. Post-fork transactions might not be a problem, as the project plains to implement a strong replay protection (yet to be done). Recently, they started a bounty of 300 BTG for replay protection implementation.

Users are recommended to keep control of their private keys during hardforks periods — i.e., not leaving your coins on exchanges. In case you do, however, make sure the exchange you use is supporting the hardfork and try to be aware of their statements and procedures beforehand.
There is a lot of discussion around Bitcoin Gold hardfork. Some claim it to be a dubious premined coin, which supposedly forked already at block height 487,427. A premine consists of mining coins prior to its launch and allocating certain amounts of currency credit to a particular address before releasing the source code to the open community. It is often justified as a way to incentivize the team and to pay for future development costs, but the crypto-community in general does not seem to like premined coins — especially in cases where the process is not totally transparent.

On October 10th, the Bitcoin Gold Developers published a Response to Recent Misinformation, addressing some of these negative claims.

When comparing the official code repository (Fig.2) to their main developer’s forked repository (Fig. 3), there are divergent information regarding the blockchain parameters (e.g., block height activation and premine window). This might be due to constant updates and changes as their work is yet to be finished.

EDIT (10/22/2017): They have now the same parameters for block height activation. Premine window is set to 8000 blocks (around 100,000 premined BTG).

Despite their statement that there is no premining ongoing, it is still unclear how exactly this hardfork will be executed and which parameters are going to be used. In addition, the major change from SHA256 to Equihash algorithm is yet to be completed and it seems they still have a lot of work to do until October 25th.

EDIT (10/22/2017):
• h4x3rotab says: “Yes, we will have a premine”.
• Their official website says “Bitcoin Gold has implemented full replay protection”. As far as I know, this is not true (yet).

EDIT 3 (10/23/2017):
Today, Bitcoin Gold Team published their roadmap. They also published a document in response to what they call Coinbase False Statement (referring to the recently published Coinbase Bitcoin Gold FAQ).

EDIT 4 (10/24/2017):
Apparently, what Bitcoin Gold Team called fork was actually a snapshot of Bitcoin’s blockchain (on block height 491,407). The launch will probably take place early November and they plan to implement SIGHASH_FORK_ID replay protection. You can find more info on their roadmap.

4. SEGWIT2X
On May 23rd, the Digital Currency Group published the Bitcoin Scaling Agreement known as the New York Agreement (NYA). It was made behind closed doors and signed by 58 companies (mostly big businesses and big miners) — it seems that no Core Developers were invited. The NYA was presented as a two-step plan aiming to increase the capacity of the Bitcoin Blockchain by addressing some technical limitations related to the rate at which transactions can be processed. The big debate around the possible ways to solve such limitations is known as the Bitcoin scaling debate. The NYA intended to reach a solution for this debate, since the community was divided between a group that wanted to scale bitcoin by increasing the block sizes and a group that wanted to scale it by using SegWit.

“The stated intention of the New York Agreement was to reach a solution to keep the community together. It has become clear in the past months that this is not possible if Segwit2x continues on its planned course” — from Seoul Bitcoin Meetup open letter.

On August 24th, the Bitcoin Core Developers successfully activated SegWit on the Bitcoin network, setting a new way of representing the data inside a block. It basically reallocates the transaction signatures inside the block in a way it frees up some space, allowing more transactions per block. SegWit was a softfork (backwards compatible with all previous versions of the software; no chain-split; supported by the community) and it is not related to SegWit2x hardfork (incompatible change that will likely cause a chain-split), which is supposed to take place at block height 494,784 (probably mid-November).

SegWit2x (S2X) is another name for the NYA and it is considered by some as a contentious hardfork project that wants to change Bitcoin consensus rules, even though there is no clear support from the crypto community nor the Bitcoin Core Developers. The team behind the S2X is led by Jeff Garzik and is called btc1. The software client associated with SegWit2x is also called btc1. However, btc1 team is not related to **Bitcoin Core and the btc1 software client is not the Bitcoin Core client (Fig. 4).

Besides the technical discussion and the scaling debate, this controversial hardfork seems to be much more about control and power. However, Bitcoin is not ruled by miners. S2X is basically copying the original source code and making very little changes on it (e.g. naming btc1 where it was Bitcoin Core). It seems they are trying to take Bitcoin’s place, expecting to be the biggest blockchain (assuming they have the Hash Power) and behaving as they were the real Bitcoin (assuming they will have the majority chain). Some call it a corporate takeover attempt, since btc1 team is willing to take Bitcoin to another direction without Core Developers support. And they are trying to drag some people with them. Due to this controversial debate, some mining pools have already withdrawn their agreement on SegWit2x.

Some of the opposing arguments that claim SegWit2x to be a contentious and risky hardfork:

• NYA was forged by a small group at a closed doors meeting.
• No support from Core Developers;
• No roadmap;
• Lack of transparency;
• Intentional lack of a Strong Replay Attack Protection;
• Opt-In Replay Protection not user-friendly (users will likely lose money);
• Very small team (Jeff Garzik as the main active developer);
• Rushed hardfork right after SegWit activation (not really needed now);
• Hardforks are risky by nature and usually require much longer periods of tests (~1 year or more);
• Coin-split confusion: both chains claiming they are the real Bitcoin;
• Bigger blocks means increased resources requirements for operating a full node (may cause further mining centralization);
• Bitcoin’s consensus rules should only be changed with broad agreement from the entire community;

On the other hand, some of the arguments in favor of S2X are:

• Bigger blocks may lead to lower transaction fees and faster confirmations;
• Supposedly remove the power or influence from Core Developers;
• More than 80% of the miners are signaling support(not confirmed);
• Reneging on the NYA would be a betrayal;
• Opt-In Replay Protection is enough (if activated);

Regarding the replay attacks protection, btc1 developers initially decided to implement the Opt-In Replay Protection — it seems that it was recently removed and its implementation is yet to be confirmed. Unlike the Strong Replay Protection, the Opt-In Replay Protection requires additional steps in order to prevent your transaction from being replayed — which makes it non user-friendly for the vast majority. That means any post-fork transaction would be vulnerable to replay attacks by default, unless we take the necessary steps to prevent them.

In this context, the Opt-In Replay protection consists of manually adding an extra output to all transactions, making them invalid on SegWit2x blockchain network. The output was chosen to be a Pay to Script Hash (P2SH). In other words, anyone that want to send Bitcoins (BTC) on the Bitcoin Blockchain will have to simultaneously send a small amount to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi in order to make that transaction invalid on the SegWit2x blockchain. It is not about sending coins before or after, but simultaneously (with multiple outputs for the same transaction). People may not be aware of it, but Bitcoin protocol supports multiple outputs for a single transaction and the Opt-In Replay Protection is based on that.

It is important to keep in mind, however, that this procedure of Opt-In Replay Protection is only valid after the hardfork, and we cannot be totally sure if it will be implemented. Time will tell. Be careful.

A couple weeks ago, Bitcoin.org website (not to be confused with bitcoincore.org), published two statements denouncing S2X and warning users about the risks of a contentious hardfork without strong replay protection:

S2X claims to have replay protection, but their version requires extra manual steps in order to prevent loss of BTC. If you use S2X software without careful engineering, you are likely to lose any associated BTC.

They are also warning users about Bitcoin’s possible incompatibility with some major services:

The signatories of this agreement wrongly believe that the currency created by adopting this contentious hard fork will eventually become Bitcoin. Therefore storing any BTC on services such as Coinbase, Bitpay and Xapo is strongly not recommended. By storing BTC on these services, you could find that after the hard fork, your BTC has been renamed to something else or replaced entirely with the new altcoin (…).

(…) If the coins on the contentious hard fork have any value, there will be methods you can use to “split” your coins and have access to them. Pay extra attention to major Bitcoin communication channels and media shortly after the fork so you stay informed.

Hardforks are risky by nature and without consensus it results in chain splits. We will probably see many more hardforks in the future and hopefully Bitcoin will get stronger after each one of them.

Again, do not take my words nor this post as advice. Be sure that you know what you are doing before making transactions and do your own research.

This is my first crypto-related work. Feedbacks are more than welcome.
If you find this useful, please consider supporting my work
Thank you! :)

14w9tH4TatVKChZUMDHE1kGDpqJAmnKdZM

Follow my work @trauzk