Hardfork 24, codename Eclipse has been feature ready (which means there will not be any changes other than bugfixes) for quite some time now. With all our testnet procedures and constant bugfixes pushed by @howo and @blocktrades' team, it is going well. If you would like to know about the last status, you can read @blocktrades' last post here.
With the HF24 approaching to our chain slowly, I think it is somewhat time to start pondering about potential changes in the next hard fork. If this is the Eclipse... Next fork could be called "Supernova" following the naming scheme.
Anyways...
The thing I want to share my thoughts and ask yours is about the witness votes. It has been surely discussed for a very long time even before HF23, but I think it is time to act on it. At a quick glance, we can see that we have a lot of stale witnesses in the Top 100 or witnesses that have disappeared from the public eye completely, leaving us unable to witness their witness actions. Unfortunately, a quite considerable number of accounts voting for witnesses and/or proposals at the moment might've left Hive, lost their accounts, forgotten their keys or even don't want to bother with changing their votes and I don't think this is a nice thing for our governance system. The same thing goes for proposals.
But how do we fix this?
What I am proposing, in this case, is a vote expiration with notifications to the users, months in advance.
User A, approves/votes User C for witness on 7th of September, 2020.
User B, approves/votes User C for witness on 7th of October, 2020.
User A gets a notification on the 7th of February 2021. - their vote will be removed, unless confirmed, next month.
User B gets a notification on the 7th of March 2021. - their vote will be removed, unless confirmed, next month.
The expiration duration for this example is 6 months.
Frontends such as the condenser, Ecency, PeakD, dApplr etc. Can have a notification system set up for this specific thing. It won't be a notification that you can ignore. Notifications can start 2-3 months prior if need be.
Basically, a month prior to the actual expiration of the vote the user would get a notification that is near impossible to ignore on the frontends, giving the user 2 options.
Option 1 - Change witness/proposal votes accordingly and confirm.
Option 2 - Confirm directly.
Option 1 would effectively change their votes hence renew the 6-month duration while alternatively, they can just confirm their active selections and extend the duration for an additional 6 months.
This is a pure discussion with what I had in mind to solve the problem of our governance. Feel free to share your ideas.
@timcliff used to have objections for this notion and he always gave the reasons for why he thought it would not be a good idea.
Likewise, this could be a great opportunity to hear the objections and discuss them. Tim has always been open minded and open to discussion, no matter what the subject/topic is.
Tim, please jump in, this is too important for your voice not to be heard on this.
You know that I have been lobbying for this for over 2 years now, but now that it is possibly being put on the potential "To Do List", please jump in with any opposing views you had or maybe still have on the subject matter.
@jackmiller - Thanks for tagging me on this! It is indeed an important issue, and one that I've been quite passionate about :)
There are a lot of good discussion points about it in this old GitHub issue/thread:
https://github.com/steemit/steem/issues/953
The idea being proposed in this post is not as unreasonable as many of the ones that have been brought up in the past. The six month period, as well as the proposed notifications and process to "renew/re-confirm" a vote make it palatable.
There are still some valid concerns about it, mainly on the security end:
There are trade-offs with every choice though, and given that it is proposing a six month renewal period - it is not something I would fight against.
Two other related ideas that I have brought up before and will mention again here for consideration are:
(1) A witness could have their votes removed if they have been inactive for a period of X days and N hardforks (for some large X, and N >= 1).
(2) A stakeholder's votes could be removed if they have not used their active/owner key in a period of N days (for some very large N).
These proposals attempt to deal more directly with inactive witnesses/abandoned accounts without trying to force a specific voting agenda on stakeholders.
I agree with this. I think expiring votes is a good idea, and 6 months+ does make it more palatable.
However, the 2 other proposed solutions are also interesting 🤔
1). This is a good idea in case witnesses go inactive
2). And this solution is good for stakeholders that go inactive.
I think maybe these things, combined with a longer overall expiry period could make for an interesting idea.
If solution 1 and 2 are both implemented, and then an overall re-vote in, say, 3 years or 5 even...it could help voters decide to look into their votes consciously again after a long period, yet keep their voting generally maintenance free during that period, aside from potentially serious problems.
I'd recommend extending the time to a year. 6 months just feels like too short of a time period for users to be "verifying" their proof of activity.
Can be done for sure, 6 months was just an exemplar from me.
Yes, I think having to re-cast a vote too often will lead to highly undesirable behaviors - like voting for the sake of getting rid of the notification rather than voting for supporting a governance matter! This can have big implications for governance.
There is some causal relationship between the UI/UX and the governance decisions people make, and to my mind that relationship has to be minimized so that the governance votes are as much as possible cast in support or opposition to governance matters rather than cast due to UI/UX conditions.
I wouldn't want to see Witness voting and Proposal voting lumped together like this.
Witness voting is all about code versions. Issues here can lead to successful attacks against Hive.
Proposal voting is granting funds to projects and so forth. It can be an inconvenient drain if abused, but it won't break the chain.
Lumping them together is akin to placing the engine on the same service schedule as the food tray.
I agree with @deathwing that it should also be applied to proposal votes, as they also can suffer from the same "stale" voting problem.
I also think it's worth pointing out that this would only affect proposals that have long durations, which is exactly where it's most important to have periodic reviews, IMO. This mechanism will encourage such periodic reviews of the proposal's value proposition.
Exactly, this was basically my thought while adding it. Imagining a long-standing proposal that was active for a year and has an additional 3 years left, an inactive account with 2M HP is voting for it and causing the DHF to fund it. The person/organization whose being funded turns malicious and does not do whatever their proposal promises and basically reaps the rewards off of the DHF by doing nothing.
Currently, with the Return Proposal, it might not cause an issue but I believe it is a nice precaution. I am sure, as @blocktrades said, this could even potentially increase the responses and exposure a proposal might get as users would regularly check the proposals to ensure their value at the time.
1 - Verifying proposal's value at the time of vote renewal. The user decides whether it is worth funding the project anymore.
2 - Being able to discover new proposals by checking the active proposals, leading to better discoverability for DHF in general.
3 - Preventing any potential inactive whale account causing problems.
Of course, if anyone has a better idea to implement a similar thing for proposals, that can be considered. All thoughts are welcome.
This is something that indeed regularly comes up for discussion and you're right, between ghost accounts and stale witness servers there is clearly a problem that leads to a status quo situation when it should not.
As for putting forward possible attacks that this would generate, it might be time to think about a system where at the time of the vote a percentage (non-cumulative) is specified as for the votes of a post.
Let me explain, let's take for example an account with 100 million VPs, he votes for a first witness or proposal up to 10%, then he has 90 million VPs left for his other votes and so on.
In this way it's impossible, even if you spread your Hive over several accounts, to return to a situation like the one we experienced at the time of the Justin coup d'état.
By recording the percentage and not the value as his account increases the values are recalculated accordingly. Compared to the current operation this just adds an additional calculation condition and value to store. As a result, it considerably reduces the risk of successful attacks on the super majority or the forcing of a multitude of proposals from the same source.
As @rishi556 I'm more of a minimum 1-year supporter but I also know that it's extremely hard to get people to vote. I'm convinced that if we could calculate the participation rate (I mean from normal users such as bloggers) of both witnesses and proposals, we would be shocked.
In order for this to work, it would be necessary that support be provided by accounts whose voice carries and is not drowned in the blockchain by organizing, for example, an annual debriefing/voting week for both the proposals and the witnesses. Even there, I'm not convinced that the impact is significant, in almost 3 years of presence I have only seen movement for the witnesses when it was necessary to counter the puppets and for the proposal system only at its implementation (again, I mean normal users such as bloggers).
Yes I know I'm boring with my normal users but they are the Yang of investors 🤣
Witness FR - Gen X - Geek 🤓 Gamer 🎮 traveler ⛩️
Don't miss the Hive Power UP Day! more info here
Yesterday was a holiday here in the US. I actually just finished it a few minutes ago, about to post after it gets a final review.
I honestly thought about this but then came to conclusion of how this could prevent abuse as well. Inactive, forgotten accounts voting on a random inactive/bad proposal that lasts 3 years. While the chances aren't high, their vote could be the deciding factor whether the proposal is funded or not.
It's a difference in impact. Maximum abuse of proposals is about $5k a day loss that will replenish itself as by design. Maximum abuse of block production is an irreversible $5k a minute loss, and I'm being highly generous here.
If there's enough inactive accounts to be the deciding factor on a single proposal(these unlike witnesses do have expiration dates), others who have voted for the proposal might want to unvote if its not being met. 22 million HP is quite a bar to reach to start getting funded. And if a proposal is getting funded but its work is being met, then theres no problem with that, no matter where the votes come from. It's like autovoters on posts to me.
That is a valid point in ref. to the DHF being open to attack.
However, the proxy expiration could eventually affect the proposal votes, but never to the point that the funds allocated for the DHF are put at risk.
I will have to agree with @guiltyparties in ref to the DHF voting.
For fixing the stale witnesses, I put in an issue onto the gitlab and @gtg responded in a way that would help fix it. https://gitlab.syncad.com/hive/hive/-/issues/50
The basic idea is that if a witness hasn't signed a block with the latest HF and the last time they signed a block was over 30 days ago, then the stale witness should become auto disabled.
To be honest, if vote expiration was implemented. We might not even need to automatically disable the stale witnesses as people voting for them would either stop and/or inactive accounts' vote would expire anyways.
We might not need to, but theres still the chance(while very low) that they get assigned a block and it gets missed. If that can be avoided, is there not a reason to do so?
Of course, extra precaution is always welcome.
100% agree with your wording of the proposed changes.
Expiration of votes and proxies, based on time.
Notifications on UIs (front ends and in wallets)
& if I may make a suggestion, that the term (time length of vote validity) be 365 days.
That seems to have been a rather amicable figure when mentioned in various witness chats in the past. Although no exact time frame was ever agreed upon by all people in those public live podcasts.
Fully support you putting this out publicly, openly and transparently.
If applied in HF25, would you be in favor of retroactively applying it or do you think it should start counting 1 year from HF25's date?
In order to ensure the safety of the chain, the datestamp of the cast vote, namely the day and month (not the year) should be the date from which the ticker starts its countdown after HF25.
i.e. if a vote was cast on 01 August 2017 then the ticker will retroactively start its countdown on that one witness vote from 01 August 2020. (assuming HF25 is done before 01 August 2021)
So "retroactively" is the answer, but in no way all from the same date, as that could risk the chains existential security in 365 days from that common date it started.
There needs to be vote decay for witness votes. But it needs to be longer. I don't want to be confronted with continual witness vote campaigns.
I am thinking about 1 to 1,5 years.
If you think that's long, we have an unstake period of 13 weeks.
I don't think we need it for proposals as well, since extra long proposals will cost a lot more to submit after the fork.
In the spirit of keeping things simple, we might still want to apply the same method to proposals as to witness votes. Mostly because it won't make a difference.
Hive is already extremely complicated for newbies (5 keys, Hive, HP, Vests, RC, Downvote Power...)
General consensus out of the replies to this post seems to be about 1 year, and of course, it seems like a nice period to send a heartbeat to the chain, verifying you are alive and keeping track of what is changing within the chain.
I would agree with this, but decay after a year. I often wonder how much of our structures are held up by lost/idle accounts, I've never actually bothered to check, I cba to write code for that 😂 I am also in favour of this for proposal voting as well.
I really would like to see this implemented.
Proposals already have an expiration date. So they should have no need to be included here. Can see them being counted down by days.
However Proxies to another account should also expire. Not much point to an expiry to the witness if proxies still stand.
For the first term of the change . Adding the expiration. This should be a period of no longer than 3 months. Shorter if possible. After that first vote of 3 month a term of 1 year can be implemented.
Notification to an account that its vote will expire in one month is enough. Adding a decay to that is ridiculous and just adds to code needing to be wrote.
Implementing the same decay for proxies is a good point.
I strongly agree witness votes need to expire, and notification is essential. Not just a notification a month in advance, but also two more weekly notifications, and during the final week, daily notifications - until they recast their witness votes.
Thanks!