Stahp

in #hive2 years ago

Hive needs to stop all the hardforking. I don’t mean that hive blockchain developers need to stop trying to create new hardforks. I mean hive witnesses need to stop activating them.

image.png

At some point, we need to prove that we can stop changing the code by using DPOS as intended. Right now, DPOS hasn’t been proven all that much. I’m sure you can show situations where DPOS saved the day. But we need to go long stretches of time with a looming change that can’t be activated because it’s blocked by a group of opinionated stakeholders hell bent on stability for the sake of stability.

Does it have to be now? Why not? No time like the present. It’s not like someone is waiting for HF28 to start investing.

The only place for Hive to grow is in the long tail. Remember that?

This idea doesn't necessarily preclude security fixes, but it very well could. An overstated security fix should be blocked.

In theory, DPOS can have higher stability than other consensus algorithms. Demonstrating this stability is pretty important. Probably more important than any individual feature in a hypothetical hardfork moving forward.

If someone says, "Hey, why doesn't Hive have multiple assets, besides HIVE and HBD?" We should be able to truthfully say, "Well, we could. The code exists, but the witnesses won't activate the change because they value consensus immutability more than a multi-asset blockchain, right now."

I think that would be a real feather in our cap.

Maybe it takes 10 years of immutability for us to finally come around to the next change. We made our point, then. At that point in the future we now value a change to consensus more than the immutability because life has become untenable to go without this change any longer.

As it stands, we've settled down to about one per year. But even then, we haven't ever really had an intentional denial of a hardfork being offered, except perhaps HF17/18, for a short period.

In addition, it is my opinion that if the next hardfork release notes are as bad as HF26/27, nobody should take that hardfork seriously. Regardless of how well implemented the code is, if the developers can’t be bothered to write any kind of release notes for a hardfork, nobody should consider deploying it on the mainnet.

See: https://archive.ph/ON8EN

That was the worst. I don’t know how witnesses could ever accept such a poor display. Rather embarrassing, to be honest.

Sort:  

A multi-asset blockchain would definitely make Hive more competitive and marketable to folks. Yes. And damn, we are all tired of getting the jab from those hard forks.


The rewards earned on this comment will go directly to the people( @inertia ) sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.

I agree, having a hard fork every year is detrimental. The Hive price will tend to crash up until the hard fork, and then crash again after. If the devs could do a really meaningful hard fork I wouldn't mind though, i.e. instant powerdowns, or accelerated power downs in exchange for a small hive burn would be awesome. The fact is someone out there will always come up with some hair brained idea that they will want to change, and as long as they get a few witnesses behind it, all the rest of the witnesses will fall like dominoes, and voila, HARDFORD approaching.

In theory, the problem is only one "team" working on hive code. If multiple would work on it, there would be more conflict.

And more "competition".

I think hardforks on hive are more like auto updates. I'm sure most of the witnesses in total don't look over the code. Even in top 20 I think it's not common to look line by line at the code and try to understand it.

I would really wonder if an HF gets rejected.

Yeah, if there were multiple teams working on it simultaniously, it would likely be a different process. Both teams would work on their own branch and try to offer two different, probably very small implementations, with probably very different priorities.

Then, if one branch is activated, the other team will have to merge that branch into theirs, or adopt the winning branch, which will likely knock them out of contention for a very long time.

This will fall on blind eyes.

Perhaps. I just thought the premise of the meme was funny, so I wrote an argument around it.

In addition, it is my opinion that if the next hardfork release notes are as bad as HF26/27, nobody should take that hardfork seriously. Regardless of how well implemented the code is, if the developers can’t be bothered to write any kind of release notes for a hardfork, nobody should consider deploying it on the mainnet.

Agreed and I've mentioned it to those writing them. One thing that Steemit did properly was write reasonably good release notes for all new versions, not just hardforks. Release notes should be more informative and written well enough for people to understand. Most people still do not understand the new curation rules and that is, in part, due to poor documentation and release notes.

Are 30 witness votes at full strength democratic, or does this promote a decentralized construct?
And
Is it even possible to run a decentralized blockchain with expensive full nodes?
I don't think so.
there is still a lot to do

Amen

Might be more possible now.

Yeah, wow 😯

Hard forking sounds to close to hard fucking for me.. leave that shit on PornHub