Author

Topic: Replay protection (Read 264 times)

full member
Activity: 139
Merit: 100
October 10, 2017, 02:34:12 PM
#5
I do not understand what protection is being used whether it is useful or not because I have not understood it, and want to know more.
hero member
Activity: 770
Merit: 500
Bazinga!
October 06, 2017, 06:44:13 AM
#4
In the case of Ethereum, which side added the replay protection.

haha, ethereum developers have been so incompetent that they didn't even think about protecting against Replay Attacks. they were only focusing on doing the roll-back faster to get their money back.
and as a matter of fact there has been a lot of issues caused by this. and a lot of money were lost. you can simply google "Ethereum hard fork Replay Attack" and find the articles of that time.
http://www.coindesk.com/rise-replay-attacks-ethereum-divide/

and the issue was severe only because the fork was without consensus and both sides had a large enough support to sustain them.
full member
Activity: 224
Merit: 100
October 06, 2017, 06:26:37 AM
#3
Oh that makes sense. I thought there are some other "hidden" implications to being the side adding the replay protection.

In the case of Ethereum, which side added the replay protection.
hero member
Activity: 756
Merit: 502
CryptoTalk.Org - Get Paid for every Post!
October 06, 2017, 06:04:12 AM
#2
I have been reading about why replay protection is important. What I don't understand is why Core can't add it? Why do they want 2X to add it. Can someone please explain that to me?

Adding replay protection requires a hard fork. It requires a change, such as to address format, that invalidates transactions on the alternate fork. Segwit2x is already hard forking. It would be fairly trivial for them to slightly alter the address format to achieve strong replay protection and therefore make transacting on both chains completely safe post-fork.

Core has consistently stood against hard forks, so it doesn't make sense for them to hastily hard fork now just because Segwit2x exists. If the Segwit2x camp wants to fork off, they should go ahead and do so. That shouldn't add any burden for Core; it's only proper etiquette to fork in a way where users won't lose money. That means adding replay protection to your fork. The only ones forking are Segwit2x, so it's incumbent on them.

And from a practical standpoint, it's far too late for Core to release an update that would be adopted widely in time for the fork. It would be a contentious update, and the fork is only several weeks away. Much of the ecosystem won't have adopted the update. Segwit2x, on the other hand, has very few nodes on the network. It would be much more trivial for these few nodes to update than the entire Core ecosystem.
full member
Activity: 224
Merit: 100
October 06, 2017, 05:47:42 AM
#1
I have been reading about why replay protection is important. What I don't understand is why Core can't add it? Why do they want 2X to add it. Can someone please explain that to me?
Jump to: