RE: Blockchain Update 3: Hardfork 20 and Release 19.4 – AppBase, StatsD, and RocksDB
I can see some positive things there but have to address this one :
the unused portion of the curation rewards will be returned to the rewards pool instead of being awarded to the author, thereby increasing the overall percentage of rewards that will be paid to curators.
This will definitely not ensure that the Steem blockchain distributes rewards to the most valuable content.
I appreciate that you're trying, but before you implement new problems to the system, consider how we're going to tackle them. What I can see coming is authors quickly learn that they don't get to keep their rewards by voting for themselves in the first 30 minutes; so they wait. And when they wait they reward the curators who voted before them. How lovely. Until the curators learn that they get better rewards for voting for self voters with more SP, ensuring that the whales get the most support while smaller accounts get the crumbs (curation) for voting for them. Unless you can add an antidote this is a recipe for implosion.
This change does not really open up a new form of abuse. What you described is possible today. If I am a large stakeholder today and I want to incentivize a large number of votes prior to my self-vote, I can just wait 30 minutes and vote then.
There will always be an economic incentive for curators to lead the votes of large stakeholders whose votes they can predict. In my view, if we are to address this problem we need to look more into ways to lower the rewards on content that is receiving a higher payout than it is worth (i.e. downvoting).
I think what @beanz may be suggesting is that with the 75/25 split, the author may gain MORE from waiting. But then again, they could do that now too. I don't see this change as adding any additional benefit to self-voters. It takes away an option to instantly vote. It doesn't add any new options.
It is already possible, but the incentive to do so is currently countered by the incentive to grab your own curation rewards. This counter incentive is being removed, and I don't disagree with that, but to suggest it will bring the best content to the top is utterly ridiculous. There will be increased incentive to vote for whales because whales have less incentive to vote themselves early. What we could do now and what we're incentivised to do are 2 different things.
The issue you are describing is that self-voting whales will now be waiting until the "early voting penalty period" is over, which will increase their rewards from self-voting because other users will be front-running their votes.
There are two possible scenarios:
If 1 is true (which is what you are asserting) then they can already do this today. This change is not enabling any abuse that is not already possible. Steemit could exclude the proposed change from the hardfork and all the self-voting whales could start doing this to increase their profit.
If 2 is true, then they will be making less under the new system, so there is no issue.
was there not to be the ability to edit posts with this update?
That should be part of the AppBase release. I think this post was just about the stuff they had specifically been working on. That change was technically completed a while ago, and is just waiting for the release to be deployed.
Less of an issue.
This entire comment chain is exemplary of the problem that variably valuing votes, and rewards for both creators and curators, by timing and etc., introduces - IMHO unnecessarily.
Want curation to actually better reward content based on the value of the content? Get rid of all the timing and games that vary the value of votes on content.
Deal with bots separately. SOC (SMTs, oracles, and communities) will make that possible. Gamifying curation simply incentivizes playing games, rather than rewarding good content rationally.
I hope to see this realized at some time. I expect SOC will make it obviously a necessary solution to many that presently don't understand how gamifying curation degrades curation quality.
Thanks for clarifying this complexity as you have. I hope we can simplify curation significantly soon, as doing so will make good content - and the people that make it - more valuable than knowing how to manipulate the rewards system.
There is talk of doing this, but no consensus yet.
Curious how
I am happy to hear that folks you listen to are discussing simplifying curation.
As to how SOC can deal with bots, in his talk in Korea @ned (whom I believe would not make idle speculations on the matter) stated that oracles are able to ascertain whether an account is A) a human person, and B) even a unique user. Communities intent on being bot free can rely on such oracles to exclude bots and socks.
The actual detection of bots is complex, and I don't pretend to grasp the details. If @ned did not misspeak (and I did not misunderstand), and can be relied on, then oracles make it possible for communities to exclude bots.
Yes, Oracles (used with SMTs) will be one way of dealing with this problem. I am in support of those changes.
There is coming a fruit of diligent nurturing of principle in action that I greatly anticipate. Good people will join their ilk in doing good.
Nothing will more encourage those whose actions heretofore have neglected beneficence to undertake it, and I can scarcely comprehend the potential of such mutual action to effect felicitous society.
Thanks for your personal dedication and work to that end.
They "problem" as you described it, sounds like the perfect / fair market to me...
Seems the plan may be to have SMT fix some of these issues; but you are right, it would be nice to SEE MUCH MORE OF A ROADMAP? on how these obvious problems will be solved... just makes sense to communicate this.
Please post the updated 2018 Roadmap along with this post.