Sounds like a crazy conspiracy theory 😉 I mean, maybe there was a plan to use that for circumventing blockade of ninjamine account(s), however the feature is one of the early features of legacy chain. Here is the initial commit that introduces it, and here the one that renames it to current name. Both from June 2016.
Also I'm not sure it was actually a soft fork that was used to block transactions during that time (it was marked as minor version though) - calling @gtg who might actually know the details. When you have nontrivial stake, soft fork is easy to circumvent - a single backup witness is enough to push your transaction through. Also as far as I know the goal was also different - to vote in enough top witnesses controlled by JS, so he could single-handedly dictate the fate of the network. Selling the ninjamined stake would be contrary to that.
In fact the routes can be split up in as many different ways as the user wants.
...as long as it is no more than 10 ways 😀 Allowing unlimited routes would be an attack vector.
This is not accurate because it only takes 16 consensus witnesses to enforce this soft fork and roll back blocks that include ninjamine ops.
I never said it wasn't an early feature.
Did you think I was implying that it was built for this exact purpose to circumvent a blockade?
This was not my intention.
This was one big concern but the main point of contention is that the ninjamine was always promised for network development. Sun did crazy things like leak videos of himself saying he was going to absorb the community and the token into the Tron blockchain, and then he'd delete it and act like it never existed. We tried to talk to him directly and he refused to communicate and it make witnesses extremely nervous.
Ah ha good to know I wasn't sure if there was an explicit limit.
Of course the limit can be implied by a minimum unit (1% = 100 limit, 0.01% = 10k limit)
It could never be infinity under any circumstance even without a set limit.
A question of definition. Formally you are right - dropping blocks containing transactions that violate new rules still qualifies as soft fork under this definition, however for me any change that affects previously valid blocks is a hard fork change. It is because, unlike in PoW chains, in DPoS such change of rules might lead to Catastrophic Network Split™️ where the result is a creation of two separate chains with their own sets of witnesses, own users (users can actually be on both chains simultaneously, sending conflicting transactions to each of them) and, most importantly, own versions of irreversible blocks - such chains can never converge without manual intervention (which means dropping at least one version with all its transactions since the split). Because of that, the only way to introduce new rules that make certain blocks invalid is to include them in a hardfork. That's why changes such as RC becoming consensus requires hardfork, even though it would be "backward compatible" according to the definition.
There is a way to introduce "soft hardfork", that would allow enforcing stricter rules without official hardfork only when there is actual consensus for it (therefore safe for the network), but it is a terrible idea easily exploited as a tool for covert censorship - see here (tl:dr censoring witnesses stop confirming contested blocks, but actually drop them only after making sure the block is also problematic for next scheduled witness).
As for Catastrophic Network Split™️ scenario, it may happen naturally after Internet is temporarily divided as a result of some natural disaster (you know, like "a huge red dragon with seven heads, ten horns, and seven royal crowns on his heads. His tail swept a third of the stars from the sky, tossing them to the earth" 😉). There is an idea for a countermeasure that could work (namely witness changing signing key or becoming one of the top only going into effect after the change becomes irreversible under non-OBI rules), it is not implemented though, because it has cons that are much more likely to show than the scenario they are supposed to prevent.
Yes, that's how I read it when you said about "testing it". Ok, my bad.
Oh, there was an official task to check Tron to see if migration is technically possible, so I never knew the idea was contested. It didn't strike me as something to worry about, if it was done properly. Granted I didn't knew all that much about "vision behind Steem" at that time, only about some of its severe technical problems.