Topic: [2017-09-25] Bitcoin Software Wars: The Case Against Replay Attack Protection (Read 2547 times)
September 25, 2017, 02:11:38 PM
Replay attention should be added by the weaker branch. Weaker in terms of value. If there is no replay protection after the Split, people will hesitate to deal in the weaker coin, lest they lose the stronger one as well.
September 25, 2017, 12:28:26 PM
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.
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.
https://news.bitcoin.com/bitcoin-software-wars-the-case-against-replay-attack-protection/
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.
https://news.bitcoin.com/bitcoin-software-wars-the-case-against-replay-attack-protection/
Jump to: