If humans count their age in years, is it ok for blockchains to count it in hard forks? I guess it's yes and no, because according to such a metric, the bitcoin network would still be a baby, while Hive would be an adult already, if we were to link the number of hardforks a blockchain went through with the human age.
At the same time, each hard fork is a milestone in the evolution of a blockchain, which may not correspond well to how much time has passed between them, but they do show technological progress that network went through from the initial version to a stable, mature product, often on what may resemble a logarithmic curve, with more hard forks in the beginning, and fewer later on (at least that was the case with Hive).
I know the consensus changes needed on Hive have taken a background stage compared to development of non-consensus tools and infrastructure, but sometimes I wonder if we should keep having relatively regular hard forks for a number of reasons:
- it's a way for core devs and Hive witnesses to collaborate to make sure the HF is successful (as this one seems to have been—congrats for that!); I know it's hard work for a period, so they can't be too often either
- it's a way for newer Hive witnesses to experience a HF and be "baptized through fire"
- I tend to believe that—although I have no evidence for it—they attract attention of the crypto community more than non-consensus development
There are also risks. A hard fork that goes wrong could be bad publicity, plus the inconvenience for the existing users. Exchanges need to update their nodes too. But still, it could be worth it.
I'm sure by now you know what the main changes introduced by HF28 are. I'd like to go over them with my impressions too.
Voting Mana Depletion Change
How it was before? Voting mana depleted with a fraction of the full vote value, depending both on the vote weight and the current voting mana. That means that a 100% vote at 80% mana had a lower value than a 100% vote at 90% mana.
How it is now? Voting mana is depleted only based on the vote weight, disregarding the current voting mana. That means that a 100% vote at 80% mana has the same value as a 100% vote at 90% mana.
My impression about this change: makes things much easier to understand and explain to newcomers and voting mana can be easier managed by depleting it to lower levels if you expect not to be active for a couple of days, without losing any curation.
Inflation Reduction
How it was before? HBD in DHF was included in the calculation of inflation for all types of rewards, which increased inflation the lower HIVE price went compared to HBD.
How it is now? HBD in DHF is excluded from the calculation of inflation for all types of rewards (including curation and posting rewards), which effectively reduced inflation by ~25% at the time of the HF.
My impression about this change: it was necessary! Whether or not this will lead to less selling pressure, the stabilization of the HIVE price and later turning back up we will see. Right now, it is hard to see its effects on the price when the crypto markets are still going down. But likely you see the effects on your rewards.
Stricter Key Enforcement
How it was before? Someone could sign a transaction that required the posting authority with a higher authority key, like the active key or even the owner key.
How it is now? Someone can only sign a transaction with the private key type required (i.e. posting key if the posting authority is needed).
My impression about this change: Very good for security reasons. It makes no sense to sign a transaction with a private key with a higher authority than needed.
Multiple Recurrent Transfers to the Same Account
How it was before? From my understanding, if you wanted to add a 2nd recurring transfer to the same account, it simply edited the existing one.
How it works now? You can now have multiple recurrent transfers set toward the same account.
My impression: The way it worked before was very restrictive. With this update, it finally makes sense for businesses (or even individuals) to set up funnels using Hive recurring transfers.
Extending the Transaction Expiration Time Limit
How it was before? A transaction not broadcasted after 1 hour expired.
How it is now? The transaction expiration limit was extended to 24 hours.
My impression about this: This change was specifically introduced to make Hive multisig transactions easier to handle by key holders located across the globe. It is both a security enhancement (since more Hive businesses may start using multisig), and an ease of use feature for existing users of multisig accounts, thus a welcomed feature. I imagine this could be useful for something like Magi too, and also for the 2nd layer protocol Blocktrades will work on.