You are viewing a single comment's thread from:

RE: Proposal: reduce Hive inflation by reducing curation rewards

in Hive Improvement4 years ago

Why no one talking about how 5min voting window creates the issue ?

Changing the curve to reduce difference and efficiency of 3min voting against 5h voting could help. Not sure how difference math works, but could be just hard coded to not exceed x% difference between early voter and late voter...
Basically flattening difference between efficiency on timing, and creating more fair competition for manual voters. System is designed for bots and this proposal seems like penalizing both parties not just bots, and completely ignoring flaws in design.

sign up with an auto-vote bot and collect your curation rewards (somewhere between 8-12% APR)

up to 16-20%
dlease ratio +2-6%
it is actually 14% on leasing so more than your estimation for curation rewards :)

The problem with this is that auto-vote bots are generally programmed to vote for a set of “known good” authors

Can be also done with unknown authors. Much more efficient probability based approach not "name" approach, like Marky mentioned above it's increasing average rewards on posts by adding multiple small votes. Increasing average +1-2$ on posts that others regularly vote(probably with simplest voting with hive.vote) but with better(moving) timing.

I am afraid it would make many passive investors just sell, 14% passive profits are good enough to keep people holding. With 4% it would be better to lock USD stable on lending protocol...

Penalizing was mentioned. I think it is possible to penalize voters on set of “known good” authors, or on probability of high rewards with loss on penalizing account. Am not going to describe it here tho :)
And it would penalize authors too, cause if curators earn less, they going to switch votes. But this could force people to shuffle more.

Still in my opinion voting window is main issue here, and decreasing curation rewards, will decrease hive value.

I mostly keep my hive liquid cause it is more efficient to rent power than power up. Only reason for me to power up would be witness voting 😣 with this change there would be no reason to rent, and millions of passive hive investors would just sell...

Sort:  

I echo your thoughts. Voting window is the major issue here.

Still in my opinion voting window is main issue here,

Several people have expressed the opinion that this is the key issue affecting manual voters, and I have to agree.

On the passive profits issue, most investors definitely don't earn 14% on their curation. You operate arguably the smartest bot that probably has the highest return on the blockchain, most people don't see the kind of return you get :-)

yes, but they can lease power for 14% :)

I don't see nothing wrong in increasing average rewards on few hundreds posts from few hundreds authors by 1-2$.

The question is, if that should give best curation rewards. I don't mind losing few % from apr if this can be moved to late voters, by creating less competitive or time dependent environment.

Also there is built in penalize system on timing where voting early decrease curation rewards for voter and also for next voters(as first one get bigger share in rewards and it goes back to the system). It was already used in some voting wars i believe. Point is that in competitive bot environment average voting time should always go towards this barrier and eventually voting popular author becomes less efficient. Maybe there is not enough bots 😅

It's good if manual curators can "discover" good authors, drop initial rewards, so authors can start earning from bots too at some point. Another issue is not enough content probably so votes mostly goes to same people and it makes auto-voting issue very visible.

Although not specifically mentioning the details, as you have here @gerber ...

Why no one talking about how 5min voting window creates the issue ?

... I did write about this. My number 1 concern! And according to the "clock," 2 hours before you did ...😉

Seriously, thank you for writing this comment. You have coding insights that should be beneficial to the discussion. Of whether or not this timing issue is ever going to be addressed in the first place, a year after its implementation.

And, if so, how it is addressed ...

sorry missed it :)

vote timing was always a part of this blockchain, still not sure how 5min is better than 15min :)

Not a problem. 😉

"vote timing was always a part of this blockchain ..."

Always has been ... Good to know.

Question now (I hope anyway ...) before us is - "Will it always be?"