In the event of a soft fork we have:
1.) The old chain exists with a more permissive set of rules.
2.) The new chain exists with a more restrictive set of rules.
In a hard fork we have:
1.) The old chain exists with a more restrictive set of rules.
2.) The new chain exists with a more permissive set of rules.
This is a cool explanation.
There is no difference between the dangers of a soft fork and a hard fork.
- snip -
So they look exactly the same during a chain split.
But there is no chain split on a soft fork.. That's the WHOLE point ?
There is a chain split if there is a division of hash power between old and new rule sets. The only difference is that a soft fork is backwards compatible with older node software, whereas a hard fork isn't.
In the event of a successful soft fork, older nodes continue to operate as normal.
In the event of a successful hard fork, older nodes become unsynced and have to upgrade.
In the event of a contentious fork, hard of soft, it becomes an economically damaging clusterfuck until the winning fork is determined (the longest chain) or a bilateral split occurs (the minority chain implements replay protection).
A hard fork which is hacked as a soft fork (where backwards compatibility is an illusionary hack), the soft fork functionality has to be sufficiently locked in before activation to prevent the backwards compatibility hacks from being exploited. In this case, an older node appears to operate as normal, but it really isn't because it is being fooled by filtered hacked data.