Latest Curation Reward Solution
A lot of effort went into discovering a solution that accomplished our desired goals without unintended side effects. Here is a summary of what we propose to fix it.
Desired Goals
When we originally introduced the concept of curation rewards to Steem our intent was to increase user engagement. We recognized that every time someone votes it provides useful information to everyone else. To be consistent with our desire that all positive contributions should result in earning a fair and proportional stake in Steem.
Intended Outcome
Any user who engages and actively discovers and up-votes content should receive a measurable reward. A properly behaving system should reward natural user behavior without users having to change their behavior beyond being more active.
Another intended outcome is that no one should get “something for nothing”. Any community that has people milking the system without providing meaningful value to the system is going to suffer. This kind of parasitic behavior can stunt the growth of the community.
Unintended Results
We did not intend to create a system that causes people to have to think about how to play. It is obvious that people will attempt to discover any advantage they can get, but a well functioning system should not have any obvious means of getting something for nothing.
A Picture is worth 1000 words
It is very difficult to explain the complex mathematical relationships at play in terms that the average reader can follow. We will leave more detailed explanation for another post geared toward the more mathematically inclined. This picture tells it all.
The yellow line shows payouts to accounts under the new distribution. Green line shows the old distribution.
Under the original rules, @ned and @dantheman were collectively getting 975M STEEM as a result of their voting habits. Under the new rules they would only receive 306M STEEM. Furthermore, only the top 20 curators lose and everyone else gains dramatically. In percentage and absolute terms, @ned is the biggest loser.
What we can infer from this is that Steemit, Inc is not proposing this change to the rules with an intent to maximize our own individual outcomes, but with an intent to maximize the outcome of the platform.
Posting Rewards
Here is the picture that shows the approximate distribution of posting rewards.
Getting more from Bots
One of the aspects to any single curve we select is that bots can win at both extremes. If we were to adopt a very exponential curve then speed matters more than anything: bots win. If we adopt a very linear curve then frequency matters more than anything, bots would win this too.
In both of these extremes the bots are providing the network relatively little information while depriving ordinary people of the vast majority of the rewards. We realized that when all of the bots race to be first, that the order they are included is either “random” or chosen by the witnesses. If frequency matters more, then bots will spam the network to maximize their rewards. We want a system that encourages bots to be selective and strategic while allowing people to behave without thinking.
We thought it would ideal if bots could “pay” to be first. This would eliminate the race and give us more information about the expected value. The more a bot is willing to pay, the higher the probability that there will be many votes that follow. In other words, a bot will only pay to be first if the value of being first outweighs the price they pay. The value of being first depends entirely upon the subjective estimate of the final value of the post.
Our solution is to offer a reverse auction for curation rewards on votes cast within the first 30 minutes. The price starts out at 100% of your curation reward and falls toward 0% over 30 minutes using the curve (1-t2). The longer a bot waits to vote, the lower the fee will be. However, if someone else chooses to vote before you it would lower your potential absolute reward.
When people vote early, the fee is given to the author. In all likelihood the reason people are willing to vote early is because the author has a solid reputation and the content is clearly valuable. If the content is less clearly valuable then it requires more effort on behalf of curators.
Final outcome: those who vote early do so selflessly (rewarding the author), those who vote late are also doing so selflessly. Only those who vote in the critical window will earn high profits from curation and only if they correctly move first without moving too fast.
It is our estimate that most people paying attention to new posts (curators) will naturally vote 10 to 30 minutes after a post is made. This allows time for review and variance in time of discovery. Those who vote naturally will on-average earn a meaningful amount from curation (relative to their Steem Power). There is very little incentive to vote instantly after a post is made unless you really want to reward the author.
Authors benefit from Reputation
Under the proposed system, authors who develop a solid reputation will find that people (and bots) will tend to vote on their content earlier than they do other content. This will maximize the rewards to the authors with solid reputations while minimizing rewards for people curating the obvious.
Discussion Rewards
Until July 4th, the curation rewards will receive 50% of the payouts. After July 4th, 25% of a post’s rewards will be distributed to comments in addition to any reward the comments get from direct votes. This will serve to amplify the value of participating in discussions while reducing the benefits from direct curation.
Decision Time
The question faced by Steem is the same question faced by Ethereum and The DAO. Do we hard-fork to better capture the intent of the curation reward smart contract, or do we distribute initial rewards under the code that fails to capture the intent and only apply the fix to future payouts. The ideal situation would be for everyone who loses from the change to voluntarily consent to the change. This would leave everyone better of and no one worse off.
There are several things we must consider when making this decision.
Code Complexity
The complexity of code grows with order N2 the number of branches / cases. Having two code paths (pre July 4th and post July 4th) will dramatically increase the long-term costs and risks for the network. It means twice as much code to maintain and twice as many unit tests. It means any future bug fixes will take longer, cost more, and likely have more bugs.
All rewards are Pending
We have maintained that all rewards are pending and are subject to the vote of Steem Power holders until they are actually paid out. Once rewards are paid out there are no take-backs. This is why the July 4th deadline is so critical.
The Steem Power stakeholders get to vote for witnesses and witnesses get to decide what changes to adopt. This is part of the overall governance model of Steem.
Consent of those Negatively Impacted
One final aspect to consider is the voluntary consent of those who benefited from or exploited bugs in implemented the intent of the software. A cursory poll of the less than 20 people who lose from these changes shows that at least 48.5% of the lost curation rewards belong to people who support fixing the implementation to match the original intent. We request that others involved voluntarily show their support for the change by stating so in the comments. In this way we can document the consent to fix the intent and prove as much consensus as possible.
New Top 40 Curators
The following are estimates on the rough order-of-magnitude of curation payouts under the proposed changes. These numbers are taken as of June 20th and will certainly change between now and July 4th.
Account Name STEEM
--------------------------------------
dantheman 166,096.399
ned 140,478.062
itsascam 124,287.114
berniesanders 82,746.46
smooth 70,474.192
pharesim 61,377.664
blocktrades 45,220.515
enki 36,447.817
blackjack 30,750.514
fuzzyvest 29,899.892
rainman 23,219.401
firstclass 22,080.283
nextgencrypto 20,267.565
summon 18,935.215
dan 18,350.276
xeldal 17,927.287
tombstone 14,956.534
bitcoin2016 13,514.589
steempty 13,095.631
complexring 12,741.466
roadscape 8,020.037
clayop 6,964.301
benjojo 5,086.087
puppies 4,764.642
hr1 4,758.074
arhag 4,515.24
onceuponatime 4,471.008
xeroc 4,079.835
lafona-miner 3,659.582
au1nethyb1 3,370.918
bhuz 3,134.844
samupaha 3,121.251
liondani 2,409.185
riverhead 2,314.849
justin 1,958.091
wackou 1,801.04
Old Top 20 Curators
This is provided as a point of reference on where the biggest losers are.
Account Name STEEM DIFF
--------------------------------------
ned 601,419.659 -460,941.597 (steemit)
dantheman 357,883.527 -191,787.128 (steemit)
berniesanders 306,528.317 -223,781.857
smooth 255,558.419 -185,084.227
itsascam 209,112.082 -84,824.968
blocktrades 133,541.764 -88,321.249
wang 57,796.624 -57,784.321
dan 57,542.043 -39,191.767 (steemit)
rainman 55,247.331 -32,027.930
steemed 54,110.775 -44,230.869
blackjack 45,042.45 -14,291.936
summon 40,930.91 -21,995.695
tombstone 36,255.739 -21,299.205
pharesim 34,140.918 +27,236.746
enki 26,081.791 +10,366.026
fuzzyvest 23,657.465 +6,242.427
firstclass 23,417.681 -1,337.398
xeldal 15,178.122 +2,749.165
nextgencrypto 13,322.803 +6,944.762
skywalker 12,736.522 -3,621.573
All told only about 19 accounts are negatively impacted and aside from @ned and @dantheman, bot operators are the biggest losers. Of these 19 accounts, some belong to the same people which means 17 people are effected.
Future Changes
As a platform we need to maintain some principles so that others can trust us. Stating these principles early and sticking to them is critical. Once payouts are made, they are irreversible. Until payouts are made they are subject to change by community vote. July 4th was our deadline for getting the curation rewards problem solved after getting input from actual users.
Feedback Wanted
Any of you who would have your rewards adjusted downward if this proposed change were adopted, please let us know if you voluntarily agree to this for the benefit of the wider community. It will significantly reduce potential conflict if we can get everyone on board.
As one of the people impacted negatively by this change, I'd like to state that I support this change. The current system is clearly flawed and needs to be changed sooner rather than later. Making these kinds of corrections as early as possible is better for the system as a whole as there aren't that many people affected. We're dealing with a brand new crypto-currency experiment here,one should not expect that everything would be perfect and immutable in the first iteration.
To those who feel they're losing money here, let me remind you that nothing has actually been earnt yet as we're still a few weeks away from the first payout! That's why all payouts are still pending, so you're not really losing anything. Even the amounts we'll still be receiving are quite frankly ridiculous based on the amount of work actually done; I'm certain this is the easiest/most enjoyable money any of us will ever earn, so just sit back, continue curating and enjoy your "free money".
I would not call it free money but I get what you mean.
wowwww
2nd that and nothing to add
I think the whole issue of changing the curation rewards is a matter of integrity.
First off, greed is a necessary in order to understand the underlying mechanism that fuels the Steem incentive system. If rules are put in place, and they are followed, which they were, then from a game theoretic perspective, one would expect a rational agent to do everything possible to maximize rewards. All agents (be they early adopters, cryptoheads, people new to the scene, etc.,) based their actions on a pre-defined set of rules.
Now, it turns out that due to the beta nature of this 'game,' and over the course of time by performing a live test on the system, we understand the current algorithm for distributing rewards for a given set of actions (posting, commenting, upvoting, etc.) much better. We see that the current implementation doesn't achieve what was initially intended.
The fact of the matter is that there is nothing faulty in the code, per se, and the current implementation is not, what I would consider, buggy. Rather, this is an an algorithm that attempts a particular type of distribution for the rewards and does so in a poor manner. In this sense, the algorithm failed, but it produced correct results as implemented. In addition, it is important to note that all participants knew the rules of the game in that the rules were in readily accessible places displayed on the Steem blockchain and strewn throughout the internet or in the Steem white paper.
Since the rules of the game were known before any agent decided to participate, actions and behavior occurred according to said rules. To change the rules retroactively is to penalize behavior that was deemed appropriate within the scopes of the rules at that time.
Changing the payout scheme and applying it retroactively to past behavior is no different than a government charging you with a crime after a law has been passed. Ignoring beliefs as to the role of government / nations (if any), established precedent exists in that most nations have ex post facto laws so that laws cannot apply retroactively to behavior that is deemed legal at a certain point of time.
I do not believe that anyone has an issue with changing how the rewards are calculated moving forward or if a future date (even possibly prior to the 4th of July large payout) is decided as to when one algorithm is used for the reward system and then the new schema is adopted. However, the problem lies in penalizing legitimate behavior retroactively.
Disclaimer: I would benefit from a retroactive change.
But weren't the rules said to be open to change?
I never saw that, at least until the recent round of posts started being made about shifting things around. I read the white paper, web site, bitcointalk posts, and no I never saw it. People who were encouraged to participate on the basis of rewards being displayed on the site in response to their actions were always told that the rewards would change based on activity (being divided among more posts for example) but I do not recall any suggestion that the rules governing those reward would be retroactively rewritten in a substantial way until quite recently. In fact, if I recall correctly, some earlier changes and proposals were specifically put forward as only applying to future actions.
I'm not sure if this was explicitly state anywhere. I thought it was implied, however, and that (maybe?) common sense would suggest that behavior would be rewarded based upon agreed rules that were put in place at the time said behavior was performed. It's not like anyone can go back and retroactively change behavior (voting patterns, post patterns, etc.).
I expected that to be obvious, I don't see any other reason for the delay of the payouts until July 4th. The algorithm was live tested, and flaws can be resolved before it affects the intended goal of distribution.
There are at least two very good reasons to delay the payouts. One being the possibility of obvious bugs in new code. If, for example, it turned out that rewards were being generated at twice the specified rate, credited to the wrong account, etc. then it would make perfect sense to fix the bug before doing the payout.
The second reason is that the reward fund started accruing well before the web site was open for posting, and certainly before it had many users. If the payouts were made on the normal 24-hour schedule the first few users on the site the first day would have gotten huge rewards. It makes more sense for those initial rewards to be spread out over a few months of usage.
Yeah, makes sense.
Seems like we're a bit in the DAO dilemma - is it code or intention that counts, and if the latter, whose? I for my part expected a curve like the new one for the first payout, and wouldn't have participated at all if I could've forseen the old one. I don't fully understand the changes we see here, why I'm up so much and you and nextgen losses are so unproportionally high. But I wouldn't care when I'd be on the other side of the fence, because I want that wide distribution that has been announced at the beginning of beta to happen. That's what I bought into.
https://coinreport.net/conversation-ned-scott-ceo-steemit/
I agree with @pharesim that this is similar to a DAO dilemma (I would've posted directly under his post, but too many descendants from the parents' post).
However, what is different is not so much the intention-- I would argue that the DAO fiasco was due to a bug in the contract and someone understanding the nature of how that contract was written using his / her expertise as a programmer. But with this situation, what we have was a complete lack of data about **HOW** the algorithm would perform. I find it unjust to reward behavior based on rules that were not known while actions were being performed, even if the new rules achieve the intention of a much more even reward distribution after the data has come in.
I am losing 185K STEEM under this proposal, a reduction of approximately 72%. The statement that bots are the biggest losers is incorrect. I played by the rules, not only the literal rules, but also very much within the intent of the rules. I never used any bot or automated system whatsoever. I devoted my time and effort to carefully evaluating posts, authors and promising topics on the site to promote. A significant portion of the time I evaluated new posters, I would find that they were plagiarizing material and not only would I not upvote them, but I would downvote them, costing myself voting power for no reward. My votes on some promising new posters and categories were risky, in that I did not know at the time they would become popular. Some did, though some did not.
In summary I do not support the retroactive change. I support 'flattening' changes going forward, though I don't know for sure this specific proposal will be a positive overall, as flatting undermines some of the subtler aspects of the incentive structure that holds the design together. Hopefully the degree of flattening will not be excessive, nor with the changes introduce some other unintended but undesirable consequences, but in any case could be modified again (just not retroactively).
I likewise do not support cutting the portion of the reward fund that is going to SP holders as a group from 50% to 25%. Those who vest into SP are locked in for two years. It is in effect a retroactive change if the future benefits to the SP asset class are reduced after people have vested under the previous rules.
Furthermore, independent of fairness issues, IMO the shift of 25% from curator rewards to content and comment rewards is misguided. Consider that, if this change is made, reversing it would cut aggregate content rewards by only 33% but would double curator rewards. The latter would likely be far more noticeable to the affected users in the latter group than the former (that is, those who primarily vote but don't post or comment much). To see a more extreme example of this effect for illustration, imagine that reward funds were shifted to 99% content, 1% curation. We could then propose to cut content rewards by less than 4% and at the same time quintuple curation rewards. Thus any such shift away from 50-50 is questionable when considering the asymmetric perceived impact from the perspective of users in different classes.
I am very active in commenting on many platforms, so this last remark is not particularly self-serving. I would likely personally receive significant comment rewards. Instead it is based on an observation that there are many people on every platform I've ever used who read and vote (when voting is available) but do not comment much if at all. That is simply the nature of how different people use these sites. For example, in forums with an international audience where posting is English-dominated, people may be avid readers and community members, but choose not to speak much because they are not comfortable writing English. Voting rewards can be a big draw and very inclusive; I see no good user-focused reason to cut them in half just to add incrementally to posting and comment rewards.
As a #1 witness you can state that you will not support next hard fork and let's stakeholders to decide - this is how Steem governance works.
Perhaps as a compromise, something like "Compensated Emancipation" needs to be explored.
Complex issues often need complex solutions.
During the times of slavery, someone along the line had made "investments". The slavery issues around the world were more easily resolved when compensation was made for perceived and real losses in investment due to a change in the rules (emancipation).
We wouldn't like to have a "steemit civil war" this early in its emergence and there appears to be a polarization between North and South developing.
Results for bots:
It's easy to have a bot that has a wait field so as not to upvote within a certain amount of time. And have a post that the bot wants to upvote in a queue, monitor this until a certain amount of time and upvote it after the time has elapsed OR wait for some number of other people to upvote the post in the queue and then upvote it even if the calculated time has not been reached.
Still interesting from a machine learning aspect.
Hahaha. Brilliant deductions :(
I am unsure of the comments issue. Won't this 25% of rewards to commenters encourage people spamming meaningless comments on every high earning post? The signal to noise ratio will be significantly impaired by this. The voting on comments counteracts this to a certain extent. I don't think there is one optimal solution to this, this must be very difficult to solve.
Man, I can only imagine how much work and effort is to make some of these changes, let alone not piss anyone off (I'm certain some people will be pissed, but people will always be pissed).
Absolutely love the new system, and definitely believe the whole redistribution of wealth is a great idea...but I believe we have to make sure it doesn't get out of hand :)
As it stands, thumbs up on the new system and I'm hella excited for July 4th!!! :D
All fundamental changes to bring things in line with the intent/vision should bemade as soon as possible. Better now, while still in beta than later when you would piss people off.
It's probably too late to not piss anyone off.
Some insist on the point that a retroactive change would be bad, and would be pissed off when it happens.
I expected the algorithm to be adapted to reach the intended wide distribution on July 4th, and would be pissed off if that huge pot ends up in a few hands mostly.
Difficult decision for our young community...
The 'wide distribution' is achieved with a combination of content rewards as well as curation rewards. Both come from the reward fund mechanism and both will be distributed on July 4 so it makes no sense to focus narrowly only only the curation reward, unless the intent is to make the distribution appear narrower than it actually is. The curation portion has always been defined as both a benefit of owning SP and a superlinear benefit. Indeed in the short- to medium-term it is the only such benefit to SP (aside from upvoting your own posts, which does no good if everyone does it). As such it should come as no surprise that the largest SP holders receive the lastest share of the portion of the reward fund that is designed to go to largest SP holders.
From what I have seen of the content rewards they are being distributed very widely to a large variety of different types of users. The primary exception there are the Steemit insiders, who gain a disproportionate share due to what I consider a glitch (possibly temporary) in the way the reward algorithm handles the small user base.
I don't see that much value in curation, voting is something most users do anyway. While I certainly spent 6+ hours a day here spreading votes the last weeks, even my old payout seemed way too high for me regarding the value I think it has for the platform compared to authors. And I'm completely opposed to derive the value of SteemPower from how easy it is to accumulate it.
I'm afraid we won't find a consensus on that issue, but at least we know each other's expectations and reasons pretty well now :/
Outside of the comments section here, which can be a bit confusing and noninclusive, where can we find out which witnesses support these changes and which do not so we can vote accordingly?
That's a good question. I do not support retroactively applying the new rules to behavior that occurred under the regime of previous defined rules.
I do support this change with no retroactivity.
In addition, I do not buy the argument that the code complexity increases as a factor of N^2. This is patently false about the nature of software development. My background is mathematics and computer science and have been developing mathematical and scientific software develop for 12 years. These applications are mainly in C/C++, FORTRAN for domain specific scientists that have user bases anywhere from 4 people (authors of a paper) to several thousand.
Anyway, when new rules are enforced, there will be no need to maintain the codebase for the previous rules. All that is needed is a proper way of identifying the functions that are called and used for the previous rules, and some if / then statements in the codebase to test whether or not we are past a block that uses one set of rules or not. In fact, these types of if / then statements already exist in the codebase with the previous hardforks! The previous versions are not continually maintained, only new code is!
I am uncertain about attempting to fix the 'bot problem' with a 30 minute window. Bots can easily change their timing scheme to vote immediately after that window has passed. Also, 30 minutes seems like a long time. I can read many articles and good posts in 5-10 minutes.
For what it is worth, I am not currently in the top 19.
There's a "beta" below the logo, so anything can be subject to change, I don't see a reason to stick with a bad algorithm. You got my full support (I'm sure you knew before, and no, it's not because i got a fat + for my rewards^^).
Minor correction:
Should be K but not M
Minor. Well a couple of order less makes this somewhat major. Thank you for pointing it out!