I'd like to request / propose a trivial yet impactful change with voting for posts.
"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%.
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:
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:
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:
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 😁).