Strictly speaking you are very wrong.
The blocksize was capped at 1MB and what you are referring to is the "soft cap"
and is neither a hardfork or a softfork. You are very wrong that a block made larger
than the soft cap would have been invalidated, in fact, some miners made larger blocks
while other still mined at the lower soft cap levels.
Ah, I thought that it was a mutually respected rule, sorry then. I didn't know that during the period when the "soft cap" was 500 KB, there were miners making larger blocks. Why did miners restrict themselves then to 500 KB ? You are saying that it is pure ignorance/incompetence on their side ?
No, the only rule is 1MB (protocol) and the "soft cap" is the miners own code on their
own miner. As blocks became more full, people asked the miners to raise their
"soft caps". Prior to this act, most miners didn't know they could raise their soft cap.
The question here is simply: does the soft cap only apply to the own produced block, or does it also enter into account to checking which blocks are considered valid by others ? If it is an own produced block, it is not a fork ; if it also applies to the validation rules of other blocks, it is a fork.
On systems as large as Bitcoin, you want something safe like 95% to ensure that no
second chain will survive. At 75%, and a contentious proposal, 25% loss is not safe
and could allow the "old chain" to survive.
If it is a true soft fork, no. The 25% will not survive, it will be orphaning itself all the time, as I explained further. 95% is a wise rule, however, if you want to have no contention, but purely dynamically, 51% is enough.
A soft fork, by definition, is a change in *de facto protocol* that makes potentially correct blocks under the old protocol invalid under the new protocol, but is such that all potentially correct blocks under the new protocol are also correct under the old one. For instance, black-listing an address is an example of a soft fork. Rejecting any block that contains a transaction with that address, while before, such a block would be accepted, is typically a soft fork.
I don't know if I agree. A blacklisting as you describe doesn't need a soft or hard fork.
[/quote]
Of course it is a soft fork. A block containing that transaction was valid before, and isn't any more, and will hence be rejected.
Forking has to do with *protocol*, not with *software* per se. It has to do with the set of accepted and non-accepted blocks, no matter what is the mechanism of acceptation, whether this is in the "core software", or an extra selection script, or whatever. It has to do with the *actual practice* of miners that decide *on which previous block to build* and *which blocks to reject/orphan/....* (not build on it). Whatever is the mechanism of that choice, doesn't matter. The actual choice is what is the actual protocol.
The miners could just have a list of UTXOs that their government deems to be illegal,
and it would be illegal for them to accept that UTXO into their blocks. Thankfully, in
this case, mining isn't fully centrlzied within one nation, so in theory, that UTXO can
be moved by a miner who is not under that country's jurisdiction.
It would nevertheless be a genuine fork, and the dynamics of forking would apply. If a majority of miners would reject all blocks containing that address, then this soft fork would be imposed upon the network, simply because if other miners (minority) make such a block (include such a transaction), the majority hash rate will not build on their block and it will be rejected/orphaned. As the other miners do accept the black-listing miners, the "orphaned chain" will not grow, because they will continue building on the longest chain. Hence, if 55% of miners decide to blacklist addresses, these are EFFECTIVELY blacklisted.
The difference between the two (softfork v unilateral hardfork) is that verifying nodes
do not need to upgrade under a softfork, but do need to under the hardfork.
But, as I think I pointed out, "verifying code" doesn't matter if you're not a miner. If there's only one chain out there, you accept it, or you stop. That's your choice as a "verifier". You know that the unique chain out there is not in agreement with what is required by your verification, and that's it.