Bitcoin Software Wars: The Case Against Replay Attack Protection

The month of September is wrapping up, and the planned November Segwit2x (BTC1) hard fork is steadily approaching. According to the BTC1 roadmap, a block between 1MB and 2MB in size will be generated by miners raising the block size limit at block height 494,784. Over the past few months, Core developers and supporters have been vehemently against the block size increase but are also upset that the Segwit2x working group will not add replay attack protection. Also read: Bitcoin Software Wars: The Battle Between Nodes, Hashpower, and Developers

The Question Remains — Who Should Add Replay Attack Protection?

The Segwit2x hard fork is drawing near, and we may see another blockchain split in the near future. At press time the intention to upgrade the block size to 2MB is backed by 93.8 percent of the entire Bitcoin network hashrate. However, the 2MB increase is not supported by a particular group of Core supporters, and the Core client’s developers are also outspoken against the fork. One of the biggest controversies about the fork is the lack of replay attack protection, and bitcoin proponents have been quarreling about this issue for quite some time. If Segwit2x and the Core software side splits, all transactions, addresses, and balances will be a direct reflection of the legacy chain. This means Unspent Transaction Outputs (UTXO) can be verified by miners on both chains and an ‘attacker, ’ or unknowing investor can spend the “same” funds on both chains. Those who are against Segwit2x believe if the developers do not implement replay attack protection a malicious actor or group can replay transactions deceptively claiming coins on the other chain. In the case with the August 1st Bitcoin Cash hard fork, developers had implemented replay attack protection to avoid this problem.   Now, Segwit2x’s working group are not the only ones who can implement replay protection, as there are many who believe Core should add the safeguard. One of the biggest arguments happening across social media is which software should be ‘obligated’ to adding the protection. Further, the Segwit2x developers have added Gavin Andresen’s Opt-in Replay Attack protocol as a means of protection. Segwit2x developers believe the “OP_RETURN” implementation is good enough and that it essentially would block invalid transactions on that particular chain after a split.

Jeff Garzik: ‘A Whole Lot of For Thee, But Not For Me Going On’

Now that Opt-in replay has been added to the Segwit2x fork, many bitcoin proponents now believe if Core developers really want a better safeguard — they should be the team to deploy one. Two weeks ago Segwit2x lead developer Jeff Garzik asked bitcoin proponents why Core hasn’t contemplated adding any replay protections. “Any idea when bitcoin Core will add replay protection? There’s a whole lot of ‘For Thee, But Not For Me’ going on,” Garzik asks his Twitter followers. In another conversation over Twitter with Dmitry “Rassah” Murashchik and Blockstream CEO Adam Back, the former Mycelium employee asks Back, “Are you worried that the other chain would win? That’s really the only reason for replay protection.” This is after Back tells his followers that the lack of Segwit2x’s replay protection is “inexcusable.”      

Daniel Krawisz: ‘You Can’t Win With That Attitude’

Additionally, Daniel Krawisz provided his opinion about the situation in another episode of his Youtube series, “Bitcoin Stuff: Why I’m Against Replay Attack Protection.” Krawisz doesn’t think a bitcoin fork should implement replay protection because it’s a competition and doing so would be too “submissive.”   “The only way that a fork of bitcoin can be a good investment is if it’s trying to win — that has to be the goal,” Krawisz latest video explains. “If you are implementing replay protection that’s too submissive. To me, that’s like saying “Yes, you are the ‘real bitcoin’ and I’m just a fork so I will be nice and change the rules to make things more convenient for you,” No that’s not going to work, you can’t win with that attitude.”

You need to be saying, “ No I am the ‘true bitcoin’ I’m going to defeat you — You should implement replay attack protection against me.” Yeah, that’s how it should work.

Krawisz’s opinion reflects his past statements about hard forks and his thoughts about the Bitcoin Cash network and how investors are “Gods” who choose the best protocol in the end.   “To me, the bitcoin developers are like the Dynasty and investors are like the mandate from heaven,” Krawisz details. “Sometimes the Dynasty becomes corrupt, and there needs to be new blood, and a new family takes over the empire — Then they have the mandate from heaven. That’s what the investors do, so if bitcoin forks they choose which one wins.”

A Fork of a Different Color

With a significant amount of business support and a majority of the hashrate, the Segwit2x developers believe the fork will be the ‘true’ bitcoin. As Jeff Garzik stated in the past on the BTC1 Github repo, “The goal of Segwit2x is to upgrade Bitcoin — to be Bitcoin — not create an altcoin.” Whether this happens or not is a different story, and cryptocurrency enthusiasts will watch another historic moment in bitcoin history as this fork will likely be rather different than the one on August 1. What do you think about the hard fork that’s approaching this November? Do you think we will see another network split? Let us know in the comments below.

---

Images via Pixabay, Emaze, the Texas Bitcoin Conference, and Calvin & Hobbes.   

---

At news.Bitcoin.com all comments containing links are automatically held up for moderation in the Disqus system. That means an editor has to take a look at the comment to approve it. This is due to the many, repetitive, spam and scam links people post under our articles. We do not censor any comment content based on politics or personal opinions. So, please be patient. Your comment will be published. The post Bitcoin Software Wars: The Case Against Replay Attack Protection appeared first on Bitcoin News.