Quote from: AngryDwarf on May 03, 2017, 12:24:43 PM

Quote from: hobbes on May 03, 2017, 12:10:26 PM

Quote from: AngryDwarf on May 03, 2017, 06:12:51 AM

Quote from: The One

Wouldn't segwit hard fork be better than soft fork?

2.) There will be less technical debt by implementing segwit as a hard fork. The software kludges implementing it as a soft fork also creates huge maintenance risks in the future (segwit keys are 'anyonecanspend').

You are wrong here. Exchanges pointed out the need for replay protection for even slightly contentious hardforks a while ago. Replay protection is quite difficult and would cause more technical debt than SWSF. This makes SWSF the currently superior solution.

Absolute bollocks. If SWSF becomes a contentious soft fork, you would still need replay protection. When there is a contentious fork, it makes no difference if that fork is hard or soft. You only need to implement replay protection if you want to cause a bilateral split, otherwise people will eventually unite behind a single chain, the one which has the most proof of work. The uniting behind one chain will happen sooner rather than later otherwise it is a complete clusterfuck.

Maybe it was not clear but of course I am assuming a significant hashrate majority. Then there is no need for replay protection because the chain will always converge to the new chain. If you still disagree please explain.

Quote

Segwit has its merits. However as a soft fork it is a dangerous software engineering hack which will burden the protocol forever. It cannot be reversed since it would be an 'anyonecanspend' free-for-all. And the potential for future developers to fuck this up is quite high. That's right, the high lords who developed segwit as a soft fork won't live forever.

Of course a hardfork is cleaner but the amount of tech debt the softfork causes is acceptable and it more than makes up for it in risk mitigation.