Thank you, I wasn't aware of this. But to make it work, a consensus between the
majority of miners and the developers would have to be reached. Or a cartel of miners that
∂ has the required hashing power could hire their own developer team
and replace the current team, like a miner's coup?
Someone would have to implement that change; but it does not have to be the Core devs.
The changes would not be too big (compared to the whole of the code); the miners could
easily find programmers able to implement them.
Again, a soft-fork type of change to the protocol becomes effective as soon as a majority
of the miners starts mining by the new rule. The other players need not download
a new version, and would not even notice the change.
In practice, the cartel will probably want to warn at least the other non-cartel miners, and
provide them the modified code, so that they don't waste effort mining blocks that the cartel
will orphan.
For the change to have an economic impact, it would still be necessary for some part of the user
base to download software that incorporates it. However. that does not have to occur before
the change is activated (as would be the case with a hard fork). Old clients would still operate
normally for a while, and would interoperate with new clients to some extent.
It is hard to be more specific about the process without specifying the change, and its
context. There have been several soft forks already, that users for the most part were not
aware of: they eventually adopted the changes, mostly without knowing, when they downloaded
newer releases of Core.
Specifically, for a change that creates additional coins (beyond the normal block reward schedule),
the miners would start accumulating those rewards immediately; but anyone running the old
software would not see those extra coins, because they would be in the new extension part of the blocks.
In order to sell the "extra" reward coins, the miners would need to convince an exchange to run
the new software. At the moment, any majority cartel would have to include the top Chinese miners,
so the big Chinese exchanges (that are very closely connected to them) will probably accept those
coins too. Those exchanges would then provide the new wallet software to their clients, and
urge them to upgrade.
A user or merchant running the old software will only notice that something is amiss
when he fails to receive coins that someone else claims to have sent him. That will
happen if the sender is using the new software, and the coins that he sent were tainted
by mixing with the new "extra" reward coins at some point. When that happens,
the receiver would have to download the new wallet software to get access to those coins
(even if only to return them to the sender).
There are many reasons why a mining cartel would not
want to do such a change, of course.
However, those obstacles would also stand in the way of the same change being deployed by
a hard fork. The soft-fork option just removes
one big obstacle: the need to inform
all users beforehand, and to convince them to accept the change and upgrade, before the
change is activated.
A hard-fork change that is adopted by a majority of the miners also creates a permanent split
of the coin. Normally one expects the minority to adopt the change too, so the minority branch
will immediately die. However, if a significant minority of the miners insists in rejecting the change,
each client will have the option to refuse it too, and continue using the "old" coin. Or use both
coins, independently, by running both versions of the software.
With a soft-fork, users do not have this choice. Even if 45% of the miners hate the change to the
rules, they cannot force a split of the chain, and must adopt it. The users will have to accept it too,
whether they are aware of it or not.