The forking attitude of fears and wishes

in OCD5 months ago

Eclipse, HF24 should be going live tomorrow (October 14th) and these are always a little bit exciting (despite there not being much hype on this one in particular), as it is a large and complex operation and lots of things can go wrong, with a minor code error resulting in major usability issues, as we have seen in the past a couple of times. Hopefully, it will go smoothly, but if it doesn't, we will see how quickly the disinterested get interested.

The next Hardfork should be more interesting and I was glad to hear that @blocktrades is already looking forward to HF25 and will start floating their ideas for inclusions in the rollout package toward the end of the week, depending on how tomorrow goes of course. Part of the Hardfork complexity is that exchanges have to upgrade also, which means taking wallets offline, so having them too often creates additional work for exchanges, meaning that with low volume tokens, it can be costly to continually upgrade their nodes.

Because Eclipse is a lot of technical cleanup work to remove references and legacy from the past and bring more alignment into the future, there was very little community discussion surrounding it. However, HF25 should include more community orientated features and as such, will hopefully become a point where Hive users are willing to participate, make suggestions and build conversations upon.

For those who are interested in learning more about blockchain, community and the directions of the future, Hardforks are a valuable information source and if open, everyone can have a say of some kind, regardless of size of stake. Of course, influence also depends on approach and what I have observed in general is that those who get aggressive and too combative in their delivery, generally get discounted or dismissed altogether. I think that people who work in a functional office environment will have a better understanding of this, over those who are more the lonewolf types.

Remember that a Hardfork is about consensus and this means that there has to be agreement on points in general, even if not every point is agreed upon by all participants. While the consensus witnesses have the final say in the upgrade, the community is able to influence Hardfork candidates through the discussion, but this requires active participation in areas of visibility, the places where things are actually discussed. In the past, I have seen many posts complaining about aspects of a hardfork, which is great, but that is not really enough, unless the account has visibility on it. What this means is that a couple of people might agree with the complaint giving the sense of credibility, but it becomes an echo chamber as the conversation becomes very one sided since it isn't open (through network) to an actual discussion.

The value of building a social network is being able to open up and encourage a robust discussion, but that also requires participants to be open and charitable in the discussion. If you are paying attention, there are a number of people that will always be positive or negative regardless of what is proposed, which essentially means that they are not credible, since nothing is always positive and, nothing is always negative. But especially the negative side, tends to get supported as it plays on potential loss and fears, which generally overpower the positives.

On Hive, I generally take the positive approach about various aspects and the potential in the future, because there is already a massive amount of fear, uncertainty and doubt (FUD) on the Hive blockchain and in crypto in general, as it makes our risk exposure far more transparent, creating us to be more sensitive to daily fluctuations without seeing the long-term trends. Inversely, I am generally accused of being too negative at work, as I tend to point out potential risk factors, when everyone else is feeling positive. It is about balancing the environment in a way that optimizes for improved results and sometimes, playing devil's advocate is necessary.

I believe that the naysayers on Hive and in the industry in general, do far more harm than they do good, as they are playing on people's fears in order to win short-span attention and validation for themselves, at the cost of the community in general. What they are likely doing, is voicing their own fears and inability to cope in uncertainty so as to garner support to give themselves the snese of stability, albeit in the negative. In general, these people are able to gather social support around themselves, but are far more like populist politicians, than active, value-generating members of the community.

Whatever happens tomorrow and in the future for Hive as a technology and community, depends on us as the people who drive the development of both the tech and social aspects involved. Through good discussion that informs direction and improves implementation, the Hive blockchain can maximize more of its potential as both the base-layer foundation and second-layer solution for beautiful communities to form and thrive upon. By beautiful, I mean in simplest form, so that function is smooth and robust and the communities we build are antifragile in that they get stronger under pressure - and that pressure is mounting daily, as the world is breaking along many fault lines, making what we are doing here, increasingly relevant.

There are many ways to participate in the discussion, but one thing is pretty certain, unvoiced ideas have little value, voiced ideas have little value if no one is listening. It is all about communication.

What are you hoping to see included in Hardfork 25?

[ Gen1: Hive ]


What are you hoping to see included in Hardfork 25?

  • SMT

Be patient mate - it has only been four years :D

Well. I really want to hear ideas AND reasons. I'm really looking forward to the discussion, and there is no doubt I'll chime in a little.

My first priority would be a voting overhaul. I don't in any way, shape or form want to see stake voting changed, I think it's a just system (if not always fair).

These are a couple of ideas:
1: End decay voting. This will not be a popular idea as it will "take away my rewards" for some and "take away my guaranteed witness spot" for others. I think if you haven't logged into the system in a month you aren't an active member and your vote should be cancelled until you log in again.

This would encourage active participation in witness selection AND in the rewards pool. It would also considerably change the 'minimum' limit for the DHF and possibly encourage app developers.

2: Considerably lower the number of witnesses one account can vote for. I think 5 is a good number, but that could easily change.

This will tend to 'spread the wealth' where witness selection is regarded. Large accounts (and small) will have to decide what they really want in a witness and a few really large accounts can't dominate the selection of ALL. They should surely be able to elect a few carefully chosen spots.

That'll do for now. I really am looking forward to HF25. After Eclipse I hope the next one isn't code named 'sunset'. :)

@fknmayhem added the decay as well. I am not sure what would be a good way to do it, but I think that it has to have some way to check that the "log-in" can't be easily automated. Perhaps forcing to actually vote on witnesss later in some way would be the alternative.

2: Considerably lower the number of witnesses one account can vote for. I think 5 is a good number, but that could easily change.

I have been pushing for this for over 3 years.

What do you think would be a good name for 25?

Easiest for witness voting decay would be check when your last witness vote was. If you didn't actively vote for a witness in last xx weeks (52?), your witness vote weight would be reduced over x weeks. That delayed reduction to avoid that for example exactly one year after the split a large number of consensus witnesses drop out in 24hrs only and the new witnesses don't have the infra required.

Yeah. I didn't say that, I think it needs to be phased in, maybe over a year or something. I agree, I don't want to see consensus change completely in a week or even 6 months.

Btw I didn't add lower number of witness votes because I recall a Discord chat with blocktrades, in the Governance channel, and he seemed very open to the idea of voting decay.

I would be absolutely pro 5 witness votes only and favor it over voting decay. But I think that may be much harder to achieve than voting decay.

Ahahahaha. Yeah, this is sorta like my 9yr old Christmas list. Make it big because I knew I wouldn't get it all...

You couldn't have thought of easier topics either, right? Simple things like SMTs and NFTs. Politicsfree topics. :D

SMTs are sorta like angles. They might very well exist but nobody has ever seen one. NFTs are working after a fashion on Hive Engine. Speaking of political :)

I like the idea of decay on rewards votes. That's an interesting one.

Would it result in automation and delegation?

Most of those accounts are automated. I think that's what @bigtom13 alludes to with

I think if you haven't logged into the system in...

I don’t think we currently have a method for that as even an automated vote is interaction with the chain. “Mark as Read” would be the most natural measure of activity but then again not everyone is OCD and not every frontend/dapp uses that.

I find it an interesting thought, but I don’t think I would focus on it as I see too many endless debates due to the chain not being able to track that. And I'm not sure we should design a specific tracker for that either.

Maybe tie it last witness vote?

All that said, with a layer 2 world upon us...

Perhaps delegation. I think it would be easy to have a 'vote' button in your profile that takes a log in to use. A captcha with the log in if necessary.

I think that would 'shape up' the rewards pool at least until the second level is ready to take over that segment on the chain. I think second level is the obvious long term answer, but the change over period is going to have some serious resistance. Particularly if there isn't an established 2nd level.


Thank you for your engagement on this post, you have recieved ENGAGE tokens.

I agree with the individuals that mentioned the Witness Vote Decay. I think we need to finish the foundation layer of Hive before moving on to changes of the reward pool and withdrawal rate. There have been a lot of post and discussions during the life of the Hive Block Chain that everyone should understand that the Witness retention system does need updating. It will be contentious, that is a foregone conclusion I think, but in the minds of many it does need to change.

The other thing I feel that would aid in the foundation layer is the completion of the SMT/HMT system. I am not a developer nor an investor, nor do I fully understand it. What I have been able to glean from reading about it is that it will provide a means for things like NFT's and Hive Engine style tokens to be developed and make it easier for game developers, front end developers, and others to provide a basic reward system to their users.

I do not feel that any changes to the reward pool or the draw down rate need to be included in the next HF (25). Any changes to it should be done on it's own stand alone HF, may HF 26 or 27, but any changes to the reward pool or the rate of withdrawal, (liquidity). Any changes to those should always be their own Stand Alone HF.

It seemed that steem chased the perfection of the reward pool/draw down rate with every hard fork. Changes that effect the perceived viability of the strength of Hive Token, should always be their own fork. This will let the investment market know that yes we have a longer term withdrawal rate than several other projects, however you can see that we also have a more stable reward system than other products.

I am ready for the next layer discussion, we all need to be involved if we want to maintain a place on the Hive Block Chain. WE being the developers, the game players, the social bunnies, the ROI chasers, all of us, we are a very diverse group and not all changes are going to be compatible with all of us. Such is life, lets see if the first possibly contentious HF (25), will be all cuddles and hugs or knives and shotgun marriage.

Nice comments and yes, I agree, it would be great to see some second layer work and see if we can attract a lot of devs to build upon it with the HDF.

While I would like to see a few tweaks with the economics (perhaps get rid of the curve) I think it can wait a little if too difficult to add in the next.

I know I am or seem to be in the minority, but I really think any change that could effect the value of Hive Token should be done in it's own stand alone fork. I feel this would allow the investors and developers time to adjust their flow for possible changes. It would also let the rest of the communities know that we are willing to let things settle down before we begin the tail chasing of the old steem days when it comes to the reward pool, curve, withdrawal rate, and inflation caps.

Very few people understand how the reward pool system works, and the reason is simple, it kept changing every 3 or 4 months. It would be nice to tell new users this is how it works for this year, next years hard fork may change it, but for now this is it. Then in April or May, of each year tweaks or changes to the financial portion of Hive Token, this lets everyone know well in advance of when the changes would happen.

Dreams for HF25:

  1. SMTs with internal market
  2. NFTs
  3. Witness vote decay

That is all (for now).
Well, maybe there’s one more thing: a commitment to target two HFS yearly.

Looks like a decent list to start things off :)

Two HFs a year would be a good goal, make sure that there is always something in development.

I would be happy with only that. I'm not sure whether NFTs were done already by previous crew, but at this time in crypto they are relatively vital to have for a base layer chain. But those top two items would take the chain to a whole new level.

2HFs yearly would probably lead to smaller forks, which isn't necessarily a bad thing, but also offer plenty of time: 4 months to code, 2 months to test and fix. And after HF25 you probably need a month of occasional updates to optimize too.

What happened this HF is unforgiveable in the sense that dapps operators should have been more accountable and tested more. The onus needs to shift more towards them (update your code or face user backlash) than the witnesses delaying to allow them more time.
A slightly more rigid release framework could IMHO help here.

Yep, vote decay would be a "nice to have" thing - top 2 are important.

What happened this HF is unforgiveable in the sense that dapps operators should have been more accountable and tested more. The onus needs to shift more towards them (update your code or face user backlash) than the witnesses delaying to allow them more time.

I agree - hopefully in the future there is the "list" of dapps that can sign off earlier - kjust as a check - but I think that part of the problem is that most users don't understand that if a HF happens and the dapps don't work - it is the dapp that is the issue - they think it is a failed fork.
Regardless, better processes need to be put in place.

I think there were issues on multiple levels, not just the dapp operators, like not enough updated nodes to test with. But those are flearns on the road to HF25, which will be only our second genuine fork after split.

But if that was an issue dapps should have raised that earlier. Or spun up an own test node (if they had the financial capabilities to do such). It shouldn't be the responsibility of only one dev shop to provide that infrastructure.

Is it possible for example, for me to run a node for the month prior to a HF for dapps to leverage ? Just thinking if we could croudsource a couple.

Yes, totally feasible. I do think @howo also asked for people to add to the test net infra in at least one post.

And now with snapshots replays would be less of an issue as well whenever updating, resetting the testnet node.

I don't know how to do it personally, but perhaps I could get a couple people together to fund a collective node for a short period of time prior to HF.

I would like to add one more thing that is powerdown period must be 04 weeks.

I didn't add that because I have no problem with the power down time. 13 Weeks is still much faster than when investing in most funds or in projects.

When FB went public, the investors couldn't even sell their shares in the first 90 days.

Most - not all - people who advocate for shorter power down time have zero clue about investing. At best they have a little trading experience. Your need for fast liquidity is not an argument of any value for the chain. The longer the power down, the higher the external trust factor. This chain started with 104 weeks of power down.

The 104 weeks is what set Steem apart; and one of the main reasons it caught my attention in the first place.

It's something Larimer still advocates. I would also love to see options with better rewards for longer staking periods: 1 year, 2 years, 5 years, aso.

You could still power down but your PD would be much longer as well.

Wholeheartedly agree. SMTs gives us scope to try these experiments; so hopefully that'll be the cornerstone of HF25.


Thank you for your engagement on this post, you have recieved ENGAGE tokens.

I'm just hoping Bittrex will bring the wallets back online. I have no idea if it because of the HF or not, but the Hive wallets have been down for quite a while. I bought some and I really want to stake it here.

I realize this has little to do with your question, but it matters to me.

Yes, most exchanges always turn off wallet deposits/withdrawals 2-3 days before intended fork date. Then wait a day or two after fork to see if the chain is stable and then update their own node (larger exchanges tend to run an own node for each chain). If the fork requires an additional replay, it will further delay when they re-activate withdrawals/deposits.

That's very much industry standard. So if you buy or need an upcoming transaction and you know there's a HF coming... do it while the exchange wallets are still open.

And then I read you replied :D

It is because of the HF, which was originally scheduled for last week, so the exchanges closed them. Hopefully will open soon after.

SMTs will let us run hundreds of experiments, instead of wrestling over this one (and being constantly forced to compromise).

I agree. I think it expands the usecase for Hive much more too for the same reason.

I agree that naysayers are always a bad influence. Nobody should ever listen to those.