Request: quality of life change with voting.

in HiveDevslast year

I'd like to request / propose a trivial yet impactful change with voting for posts.


The problem

"As everyone knows" voting power recharges at a pace of 20% per day. You can cast 10 full powered votes a day (I'll use only full powered votes in the text below), since each uses 1/50 of your voting power. There is a fine print though. It is true only if you cast your votes once every 144 minutes. That is because every time you use voting mana, your account temporarily becomes smaller. Upvoting is the only manabar that works this way. When you are using RC mana, you are consuming exactly the full cost of your transaction. When downvoting, as long as you keep upvote mana at full, all your 100% downvotes will be of the same power until you run out of downvote mana and start consuming upvote mana for downvotes. But when upvoting, the weight of your vote translates to power based on your current mana, not on your full power. If after one vote you don't wait for recharge, your next 100% vote won't actually be 100%.


made with meme generator

Imagine driving an EV covered with solar panels. It recharges slowly on its own, but while you drive and battery charge is consumed, your max speed drops. Who would want to use such vehicle?

There are some consequences of such behavior:

  • plankton accounts on the edge of dust votes have to always wait for recharge to not fall below dust threshold
  • minnow accounts that can assure their single vote pays enough for the comment to actually receive reward are in similar position
  • for every account: not only your HP and given weight of the vote but also order of voting influences its power; in particular, if you want your vote to be as strong as your stake allows, you have no option other than to wait for full manabar

All of the above can be avoided with use of bot. Instead of voting directly, just pass your chosen article to a bot and let it vote in your name once your mana is near full (or the voting window is about to close - whichever happens first). However I don't think users should be forced to use a bot to vote optimally.

There are consequences that cannot be avoided even with bots:

  • large accounts, even if they spam votes every block, stabilize at some point, when their per-block-recharge is bigger than cost of vote - that makes some portion of their voting power unusable; it is actually true for all accounts, but for small ones their stabilization point might be below dust threshold (all accounts stabilize at 1/2880 of their full power assuming one vote every block)
  • there are situations when there are more opportunities to vote on one day, while there is not enough on other days - for example #FungiFriday that I personally take part of; despite voting in four batches (Thursday night when first posts are published, then Friday noon and evening, finally Saturday morning for last posts), I still end up at 75% or less power, which means my "full powered votes" for last posts are only as strong as 75% votes on first posts, skewing the rewards away from authors that participated late in the event

Solution

The solution is very simple. Four new lines of code. Starting at next hardfork (1) use voter.get_effective_vesting_shares() instead of voter.voting_manabar.current_mana for calculating used_mana (2) - the same can be used for downvotes actually. The last line is in two copies - an assertion to stop use of mana the user does not have (3,4).

The change makes it so that:

  • all your votes of the same weight will have the same power as long as your stake did not change in the meantime
  • you can actually use all mana - some users might need to lower their vote weight in case they vote more than 10 times a day on average
  • without any adjustments to vote weight you will have less excess mana to burn on hbdstabilizer
  • you gain full freedom of when to use your mana within 5 day recharge window

That's all. Since the change is so trivial, even with tests it should not require too much time to add into code, therefore could still fit into HF28.

By the way, if anyone knows why upvotes work the way they do currently (@gtg?), I'd be very interested in that information. There might have been legitimate reasons to do it in such way and maybe those reasons still hold. Or maybe not, after all voting and reward calculation looked vastly different in early days of "legacy blockchain" (picked up this great term from @crimsonclad 😁).

Sort:  

It originally worked the way you describe. The reason for the change is described in a very old post from early in the Steem era (perhaps someone can find it). The idea is that if you vote 20 times per day with a default or 100% vote weight instead of 10 times per day, your votes will automatically end up being about half as strong each, rather than the first 10 votes burning all your vote power and the next 10 doing nothing (this is an oversimplification as the window is actually 5 days, but you can get the idea). It was to accommodate people at different levels of activity without requiring micromanagement of vote power.

It originally worked the way you describe

The great curse of blockchain code is that when it was ever used, it needs to be present forever. That however presents opportunity to "turn back time" and actually use it. For this reason I have full confidence that it never worked in described way.
In the process I've learned that manabars used to hold basis points instead of power values like they do today (up to HF20) - strange thing.
The rules of voting were vastly different but that aspect remains the same. Consecutive votes drop in power right of the bat like today, but it is even worse - due to lesser precision of basis points you can actually stop all mana regeneration by voting too frequently.

OK, I'm sure you must be correct and I misremembered something about the change that was made.

In any case, I correctly explained the reason for the current mechanism. It creates an equilibrium of sufficiently reduced votes when people happen to be more active and vote more often than the maximum rate of full power votes, instead of burning their vote power down to nearly nothing (without needing to micromanage vote power to do so).

Thanks, I couldn't remember why it worked this way...

Personally, I've still got no strong opinion one way or the other, both ways seem to have advantages and disadvantages.

Given the way I suspect people mostly vote when they vote manually, I think the original way (full vote each time) with a 5 day interval would no pose any issues for people, so I wonder if this wasn't someone's theoretical concern rather than an actual complaint that led to the current operation.

For people with smaller stakes, who don't use or IIRC don't even see the vote power slider, voting more than 10x per day would result in a lot of 'dead votes'.

I'd suggest making the change to blockchain as proposed but then offering an UI option, ideally as default, where vote power would automatically be scaled to mana percentage, which would replicate the earlier behavior at the UI level. Power users who want to "use all their vote power" and/or manually control vote power for whatever reasons would disable that option.

Seems like the best solution to me.

That seems like a cogent and reasonable proposal. Have you heard any compelling objections?

I've talked about it with couple of people, no objections so far. But that's why I've posted this proposal here - to check with broader audience. I think I'll try to make it relayed to developer chat tomorrow. After all, if this is ok, someone has to make it a reality 😉

From my understanding, upvotes are not unlimited, and the value decreases each time, so you have to think about what deserves votes and what does not.

This sounds interesting. But I still don't understand completely. At what rate or at what point will the value of the vote start decaying? If the votes never go down in value, we will have unlimited votes, which could be an issue, in my opinion.

I also posted about something similar, but it's more related to the curation window. It's the last post on my blog if you want to check it out.

You won't be able to use more mana than you are today (that's why there is the need for an assertion to stop use of mana the user does not have). The system just won't punish you and your chosen author for not waiting for full regeneration after each vote.

You can only think about what deserves votes between posts you already read, not future ones, and current system affects the latter. Let's assume you read a lot of posts worth voting for and therefore you did vote. But the next day even more/better content appears. Too bad your manabar is still regenerating. You have the mana, but the system won't let you allocate it to the deserving post just because you lacked clairvoyance and you used a lot the day before. After the change you will be able to vote freely, and only in case you get reckless for couple of days in a row you will be stopped by lack of mana.

Now I'm heading to your post, because you've touched interesting subjects :o)

Oh, I see. You would have ten votes per day (if you vote all of them at 100%), and when you use all of them, you won't be able to vote, or the value will be greatly reduced.

I think that would be great because, as you mentioned, sometimes we vote for a post, and it gets great value, but then we see another post and will get less for a vote with the same %.

Today, I saw that the core devs mentioned this at the meeting, and even an issue was added to the GitLab.

I am by no means an expert on how these things are calculated but I do know there is a fixed limit to the amount of hive awarded based on curation. i.e. the rewards pool is a fixed size. Therefore, if you effectively increase the voting power at which everyone is voting then it will just take more voting power to be worth the same amount. In other words, I'm not sure this would result in much net change.

Also, in the long run, I'm not sure that is important that you consume all your voting power. If you simply don't allow it to reach 100% then I don't think you really lose out in terms of APR.

My understanding may be flawed but I don't think what you are asking for would really make much difference (if any) in terms of either vote value or earnings. Given that the rewards pool is a fixed size, I don't see how it could.

It is not my intention to affect earnings. The change does not let you vote more. It is hard to predict effect of something that might influence how people react to change, however my guess would be that there will be very slight shift of rewards towards regular posters at the expense of hbdstabilizer and other mana-burn content, since by letting people more freely allocate voting power to posts they actually want to support, they will be left with less excess mana to burn. It will also be easier to avoid reaching 100% and wasting mana regeneration.
After the change current behavior can still be achieved, f.e. if now you voted 100% for post A and then post B, after the change you'll still be able to vote 100% on A and 98% on B, getting exactly the same results. I doubt anyone will be willing to do that though. The change simply gives you more options on when and where to use mana you already have. After all users are (mostly) not bots, therefore they are constrained by things such as sleep, work, hobbies, social interactions and other entertainment - they are not slaves to Hive. Therefore the system should not artificially constrain users beyond clear necessity.

very attractive appearance. How are you today friend?

Hello miosha!

It's nice to let you know that your article will take 5th place.
Your post is among 15 Best articles voted 7 days ago by the @hive-lu | King Lucoin Curator by deepresearch

You receive 🎖 2.3 unique LUBEST tokens as a reward. You can support Lu world and your curator, then he and you will receive 10x more of the winning token. There is a buyout offer waiting for him on the stock exchange. All you need to do is reblog Daily Report 108 with your winnings.

2.png


Invest in the Lu token (Lucoin) and get paid. With 50 Lu in your wallet, you also become the curator of the @hive-lu which follows your upvote.
Buy Lu on the Hive-Engine exchange | World of Lu created by szejq

If you no longer want to receive notifications, reply to this comment with the word STOP or to resume write a word START

I like to upvote comments at 0.021 so that I know they won't dust. I use the slider in peakd to do this. In effect, all my upvotes are worth 0.021 as long as I am doing this. I am using the available tools to get consistent value across all of my votes, without forcing my preferred outcome on everybody else. Is there a good reason you cannot do the same?

You are getting "consistent value" across your votes, because you are not really voting (at least not on this account). During last two months you've voted on average less than once per day, which means you've given up on 90% of the votes you were entitled to. Also all your votes were 100%, so it seems your use of "slider in peakd" didn't really have any effect. No wonder you never run into the problem I described. But don't worry, nothing will change for you with my request. You are overflowing with voting power. My issue addresses those who use it in full, but might want more flexibility when to use it.

Good job, you can do basic blockchain analysis on my voting pattern from this account instead of thinking about what I actually have to say.

Congratulations @miosha! You have completed the following achievement on the Hive blockchain And have been rewarded with New badge(s)

You distributed more than 5000 upvotes.
Your next target is to reach 6000 upvotes.

You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word STOP

Check out our last posts:

Hive Power Up Day - December 1st 2023