At this point we don't know if SegWit will be activated. I mean code is already implemented but it will be miners who will decide if they want support SegWit or not.
We need consensus of 95% miners to activate SegWit and I heard that new Chinese mining pool ViaBTC won't support it and they control roughly 9% of hash power.
In worst case scenario bitcoin won't be forked at all.
Topic: SegWit HF vs SF (Read 334 times)
Segwit as a hard fork is nearly the same as segwit as a soft fork. As a hard fork, it means that the witness commitment would be part of the block header. However, this is not desireable because the same data can be put into the coinbase transaction with no additional overhead and would make it a soft fork.
Other proposals to make it a hard fork would make deployment a nightmare. One such idea is to implement all of the changes that segwit does but instead of creating new output types, the definitions for the current output types would be changed. This means that the scriptsigs would be excluded from the transaction id calculation and the sighash preimage algorithm would be changed. This introduces a huge issue with deployment: what happens to all of the unconfirmed transactions at the time of the threshold passing? Those transactions would instantly become invalid. If those transactions are timelocked where the transaction was signed and then the key thrown away, then those timelocked Bitcoin become lost forever. This deployment would not work, and would really only be effective on a completely new blockchain.
Other proposals to make it a hard fork would make deployment a nightmare. One such idea is to implement all of the changes that segwit does but instead of creating new output types, the definitions for the current output types would be changed. This means that the scriptsigs would be excluded from the transaction id calculation and the sighash preimage algorithm would be changed. This introduces a huge issue with deployment: what happens to all of the unconfirmed transactions at the time of the threshold passing? Those transactions would instantly become invalid. If those transactions are timelocked where the transaction was signed and then the key thrown away, then those timelocked Bitcoin become lost forever. This deployment would not work, and would really only be effective on a completely new blockchain.
Hard fork means everyone on any older version gets kicked out off Bitcoin. Upgrade to the new Bitcoin, or you can't use anything about it any more.
Soft fork means that all the old features works the same, and so all the old versions of Bitcoin can stay on the network, doing all the old features just the same as the those with the new version doing new features. Obviously, the old versions can't do new features because they don't know how.
Soft fork means that all the old features works the same, and so all the old versions of Bitcoin can stay on the network, doing all the old features just the same as the those with the new version doing new features. Obviously, the old versions can't do new features because they don't know how.
I've been searching around can't find much information on the decision to have the implementation as a Softfork vs a Hardfork. It's been noted around the community that it was initially intended to be added as a HF but was changed. Can anyone enlighten me on this subject, the advantages or rationale?
Jump to: