RE: Hive Vesting Routes
You are viewing a single comment's thread:
a single backup witness is enough to push your transaction through
This is not accurate because it only takes 16 consensus witnesses to enforce this soft fork and roll back blocks that include ninjamine ops.
however the feature is one of the early features of legacy chain.
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.
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.
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.
as long as it is no more than 10 ways
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.
The result of contentious hardforks is super interesting from a technical level.
A lot can go wrong and create a total clusterfuck.
But also I don't know what to tell you because this is exactly what happened.
This is how we froze the Steemit Inc ninjamine.
It happened. That is a fact. Incontestable.
So unless you have some new information as to how this happened: what I said still stands.
The witnesses can drop a block for any reason they want.
There doesn't have to be a cited reason for why it's against the rules.
They just drop the block and get consensus, or don't.
The rest of the network follows that fork by default because those are the rules of consensus.
Dropped blocks are a totally normal thing and don't lead to a hardfork.
Only if that block was immutable.
If it's a droppable block and it gets dropped, that's not even a soft fork, let alone a hardfork.
The code to drop blocks has existed from day one by necessity.
DPOS witnesses don't need to give a reason for why they dropped a block; they just do it.
They are the ones in charge, which is the entire idea behind DPOS consensus.
This argument you're making reminds me of several downvote wars years past in which people tried to say that downvotes are committing literal violence and theft upon the 'victims'. That's not accurate, as an upvote isn't money until it pays out 7 days later. Just like a block isn't a block until it becomes immutable. A dropped block is never going to create a hardfork automatically because that would destroy the entire DPOS model. Devs would have to go back and craft that hardfork by hand and then replay the entire chain from scratch.
Yeah?
I've finally completed a reply - writing articles takes hellishly long time. I have no idea how you can write one every day :o)