Earlier this week, in an analytical column entitled “How SegWit2x Replay Protection Works,” Bitcoin developer and Paxos principal architect revealed the motive behind the development team of SegWit2x to integrate opt-in replay protection rather than strong two-way replay protection as the Bitcoin Cash development did in July.
SegWit2x Hard Fork in November and the Different Types of Replay Protection
In his analysis, Song noted that replay protection prevents attackers from creating duplicate transactions on a new blockchain network that is created upon the occurrence of a hard fork. For instance, if the fork to a 2MB block size occurs without replay protection, hackers will be able to take public transactions between two wallets processed on the Bitcoin blockchain and create identical transactions on the SegWit2x blockchain.
Song explained:
“Opt-in replay protection means that transactions from chain X need to do something special to be invalid on chain Y. That is, by default, transactions are exposed to replay attacks, but if you manipulate your transaction in a certain way, the transaction won’t be valid on chain Y. Opt-in replay protection is more like a door you have to remember to lock, because otherwise the transaction may escape chain X and get into chain Y.”
Ahead of its November hard fork, developers behind SegWit2x led by former Bitcoin Core developer Jeff Garzik have implemented opt-in replay protection instead of strong two-way replay protection, which Bitcoin Cash executed prior to its fork.
One significant difference between strong two-way replay protection and opt-in replay protection as explained by Song is that with the former, transactions in the Bitcoin network will be made invalid in the SegWit2x network automatically. Hence, bitcoin wallet users that hold the cryptoasset before the fork will be able to claim their B2X coins if two-way replay protection is implemented.
But, developers have implemented opt-in replay protection because it requires users to take a specific approach in settling transactions – which would be challenging for casual users – to ensure that the transaction made in the Bitcoin network is invalid in the SegWit2x network. The process of ensuring that the transaction in the Bitcoin network remains invalid in the SegWit2x network requires a small amount of bitcoin to be sent to 3Bit1xA4apyzgmFNT2k8Pvnd6zb6TnwcTi.
“This address was chosen because it’s somewhat easy to see visually (starts 3Bit) and is easy enough to spend since the private key is well known,” wrote Song.
He added that the motivation of the SegWit2x developers to add opt-in replay protection was to prevent the Bitcoin Cash situation wherein wallets have had the choice to either support Bitcoin Cash or leave the process of claiming Bitcoin Cash to their users to do it manually. If the hard fork includes opt-in replay protection, for the interest of their users, bitcoin wallets and exchanges will be forced to support SegWit2x to prevent transactions from being duplicated in the SegWit2x network.
“When BCH forked on August 1, there were almost no wallets that supported BCH specifically because their replay protection scheme was strong and because wallet developers hadn’t had a chance to code in the adjustments required to make transactions valid on BCH. It looks like SegWit2x is trying to avoid this by making transactions work with current bitcoin wallets, merchants, and services that exist,” Song explained.
BitGo Engineer Jameson Lopp: Can be Considered as an Attack on Bitcoin
BitGo Engineer Jameson Lopp was especially critical of the opt-in replay protection, stating that he could consider it as a type of attack on Bitcoin:
“My thoughts on SegWit2X’s recently added replay protection. It’s so bad I could see it considered a type of attack.”
He particularly emphasized that opt-in replay protection is not practical and beneficial for users because it could still lead to miners breaking the replay protection with ease. Lopp went as far to say that he will not be able to recommend BitGo to implement support for SegWit2x with the current replay protection in place. Lopp noted:
“Given the side effects it will have upon the whole network, I don’t see how I can recommend we implement this at BitGo. Even the hacky nLocktime and coinbase tainting methods seem to be less disruptive to the network than this method.”
Btcmanager.com is author of this content, TheBitcoinNews.com is is not responsible for the content of external sites.
Our Social Networks: Facebook Instagram Pinterest Reddit Telegram Twitter Youtube
