All the cool kids are posting in #utopian-io...
I might as well join the crowd. Welcome to my first utopian.io analysis post.
A note on my professional background
while I focus my posting on Steem blockchain on art, music, family, marijuana and curation (among other creative/crazy type stuff), my professional background is in market research. I have held positions of project manager, survey author & programmer, data analyst, research facility manager, and district manager (for a national market research company with research facilities across the country).Since October of 2017 I have been a full-time Steem'er. This is my employment now. I am a community rep, operator, curator and reviewer for @curie. I am also one of the co-founders of the C² Curation Collective, an inclusive community intended for all curators on the Steem blockchain. Join the community as a curator on Discord and follow the @c-squared vote trail on steemauto.com to support the curated authors.
Repository
https://github.com/steemit/steem
Reason for Analysis
There is a lot of confusion surrounding the proposed changes to curation reward under HF20. Part of this confusion stems from the wording of the @steemitblog posting on the subject, which could be read to imply that only self-voting behavior will be impacted by the proposed change. Thanks to @tcpolymath for pointing me to the actual Github Proposal: Curation Reverse Auction Changes #1874, which makes it clear that the proposed changes will affect all votes (self-votes and otherwise).
The above linked Github proposal has a clear explanation of the current voting situation; see also this post by @paulag and these posts (first post on topic; updated proposal for alternative to HF20 proposal) by @tcpolymath for more background.
As @paulag noted in reply to me in the comments of above linked post, "the rewards pools and distribution of it is very complicated to understand". When analysis is conducted on the level of individual votes, there are many factors which determine how much each vote actually ends up affecting payout. An accurate analysis must include all votes on the post and account for vote time and rshare. Data sets quickly become unwieldy and it is difficult or impossible to analyze all authors/voters or even a representative sample across a decent time range to normalize for daily variance.
I believe a more constructive approach to this issue is to look at sum totals of author and curator reward by SP of author to understand the current situation, and how proposed HF20 changes will impact authors with different amounts of vested SP.
This approach will allow us to see not just how much authors will lose under HF20 (how much will be returned to the reward pool), but also what % of the reward pool is distributed to those authors (to determine the net effect of HF20).
Goal of Analysis
- Present a complete picture of current author rewards and curator rewards on total and by author SP
- Examine impact of HF20 proposed changes including likely changes in voter behavior
Analysis of Current Author Rewards and Curator rewards
I pulled the data for this analysis from the SteemSQL database on 7/6/2018. I looked at all posts (this includes comments, for the reason that author/curation rewards behave identically for top level posts and comments) from the time period of June 1st, 2018 through July 6th, 2018 when I pulled the data. This gives us a robust data set with 4.4 million posts, 90k unique authors and $2.3 million total reward payout.
SQL Query used:
SELECT
SUM((c.total_payout_value)+(c.curator_payout_value)) as [Total_Post_Payout],
SUM(c.total_payout_value) as [Author_Payout],
SUM(c.curator_payout_value) as [Curator_Payout],
COUNT(c.url) as [Number_Posts/Comments],
COUNT (DISTINCT c.author) as [Number_Authors]
FROM
Comments c (NOLOCK) INNER JOIN Accounts a ON c.author = a.name
WHERE
datediff(month, c.created, GETUTCDATE()) between 0 and 1
AND cast(left(a.vesting_shares, len(a.vesting_shares)-6) as float)*492.725/1000000 [SP CONDITION]
NOTES ON QUERY:
- The above query returns the sum total of author payout, sum total of curator payout, count of posts/comments and count of distinct authors in each author SP grouping specified by the
[SP CONDITION]. - Replace
[SP CONDITION]with an argument to specify SP range e.g. to include only authors with 0 - 499 SP replace[SP CONDITION]withbetween 0 and 499. Remove the last line entirely to return results on total (all authors). - Date range is specified as current and prior calendar month - adjust the
datediff(month, c.created, GETUTCDATE()) between 0 and 1line as needed to specify different date ranges e.g.datediff(day, c.created, GETUTCDATE()) between 0 and 30for past 30 days data orc.created between '[DATE 1 in timestamp format]' and '[DATE 2 in timestamp format]'to return results between specified date ranges.
I ran the query six times to generate a data set for the following author SP bands (breaks chosen somewhat arbitrarily based on prior knowledge of numbers of accounts in various SP ranges):
0-499 SP; 400-4,999 SP; 5,000-9,999 SP; 10,000-49,999 SP; 50,000-99,999 SP; 100,000SP+
I further created derived metrics from the data:
% of Total Reward Pool; % Author Reward; % Curation Reward; projected Author Reward given proposed 75% cap; Author Reward payout reduction per author given proposed 75% cap; and % of the total reduction in Author Reward.
You can see the spreadsheet and check the formulas used to generate these numbers at this Google Sheets link.
Click table to view full size
FINDINGS
- The more SP an author has, the more the HF20 changes will affect author reward if current early self voting behavior continues (we will later examine impact of likely changes to voting behavior in response to HF20).
Solely considering reduction in author reward from proposed 75% cap (we will later examine how much of this reduction would be recovered based on % of reward pool controlled by each SP band) we can see that individual authors in the highest SP ranges will be returning a much larger amount to the reward pool:
The lowest SP users are currently the closest to the 75% author reward share and as SP increases so does average % author reward share:
These are not surprising findings. The more SP a user is voting with, the greater the opportunity to take advantage of the increased rewards available from current self-voting at 0 minute behavior.
- The two lowest SP bands (0-499 SP and 500-4,999 SP) are net beneficiaries from the proposed HF20 changes while all SP bands above are net losers, with net loss increasing as author SP increases. The smallest accounts with less than 500 SP are the largest net winners.
This can be seen by comparing the % of the total author reward reduction by SP band under HF20's 75% author reward cap, with the total % of the reward pool controlled by that SP band. If the SP band controls a greater % of the total reward pool than the % of the reduction in author rewards coming from that SP band, it is a net beneficiary of increased author payouts.
EDIT - as I noted below in a comment to @paulag, the actual % of the reward pool controlled by each SP band under HF20 will be different than the numbers used above (which are the current % of the reward pool controlled by each SP band). Without the 0 minute self vote returning well over 100% ROI, large accounts will control a relatively smaller % of the reward pool compared to status quo.
Impact of likely changes to voter behavior under HF20
- Large accounts self voting at 0 minutes will likely stop. There will be a clear incentive to delay self voting, either to 15 minutes to receive a full share of author and curation reward, or to some optimal point between 0 and 15 minutes to take advantage of curation reward from other early votes falling before 15 minutes (e.g. if an author knows a large automatic vote will come in at 12 minutes, it might be optimal to self-vote at 11 minutes). The optimal time to vote will vary depending on the behavior of other voters but clearly 0 minute self voting by large accounts will stop.
This change in voter behavior will still result in lower payouts for the highest SP authors
- Current author reward % above 75% is possible because a self-vote at 0 minutes gives a share of the curation from trailing votes; under HF20 self-voting at 15 minutes (while still giving the full value of the self-vote to the author) does not automatically result in a share of the curation reward from other voters. As noted in our original analysis above, it is the highest SP users that are currently able to take most advantage of this self-vote loophole that allows > 100% return - closing the loophole necessarily impacts them the most.
- Even to the extent that an author recovers some of the missing author reward from a post through increased curation reward from self-voting at the new delayed optimal time, this will still result in a net reduction of post payout value because of a net decrease in the proportion of the total reward paid out to the author in SBD. Interestingly, the total market value of all payouts will decrease under HF20 because of the weak SBD peg to the dollar. At any time that SBD is worth more than $1 USD, a net increase in total curator reward % results in a net decrease in total reward payout market value. However, the beneficiaries from this are still the lowest SP accounts. The important thing to look at here is total % of reward pool. The accounts that previously were best able to take advantage of the 0 minute self-vote will lose a relatively greater share of the reward pool. This is a net win for all smaller accounts.
Conclusion
- HF20 will change voter behavior by dis-incentivizing 0 minute self voting and will reduce the total market value of the reward pool payout by decreasing % of total payout in the form of SBD.
- Any account with vote power under the dust threshold will suffer no negative consequences under HF20 and can only be a beneficiary of increased payout. (EDIT - @tcpolymath points out in the comments this is not true RE the dust threshold - the broader point below holds, net effect of HF20 is negative for the largest SP accounts and positive for the smallest SP accounts in regards to % of reward pool distribution)
- The largest accounts previously able to take best advantage of > 100% ROI from self-voting will lose the largest relative share of the reward pool; the smallest accounts will be the biggest winners with a larger relative share of the reward pool.
- Under HF20 it will no longer be possible to automatically receive > 100% return on a self vote. Self-voting at 15 minutes opens the possibility that another voter has voted earlier and will receive a portion of the curation reward from the self vote. Self-voting earlier than 15 minutes necessarily results in a reduction of curation reward. ( EDIT - @tcpolymath points out in the comments that in practice, it is still possible to guarantee a 100% return, but not > 100%, on a self-vote through self-voting comments exploit )
Future Analysis
- Actual future voter behavior cannot be accurately modeled beyond the broad trends identified above. If HF20 is implemented, future analysis on its impact should focus on actual combined author/curator reward realized by accounts at different SP bands, remembering to account for the reduction in market value of payout stemming from decreased SBD payout.
Fantastic analysis! Good to see that the effect should be beneficial for smaller accounts overall.
From a behavioural perspective my guess is that after HF20 the rule of thumb most people will use is not to upvote in the first 15 minutes (in the same way that the old rule of thumb was to upvote at 30 minutes).
On this basis it is likely that accounts with small payouts will return relatively little to the reward pool, since there is no real reason to upvote prior to the 15 minute mark.
Accounts with larger payouts will probably still return some proportion to the reward pool due to curation-hunters early voting around the 12-14 minute mark. So even after HF20 this could continue to have an overall positive impact for smaller accounts.
As an aside, it would be good for platforms like @steempeak to implement a "delay my votes to the 15 minutes mark" option, allowing users to browse through and vote without worrying about the timing. I think this shouldn't be too difficult as they already have a buffer system to avoid the repeat posting / voting time restrictions.
An option to "delay all votes made through steempeak on this post to the 15 minute mark" would be potentially more controversial but also an interesting option. It would need wider adoption, ideally with steemit and busy also implementing, to be fully useful. One to debate!
Great comment! Yes I totally agree that in actual practice, for the largest accounts that always have a high expected payout on posting, we will definitely still see votes coming in before 15 minutes because of the curation hunters. Really it is similar to what we see now on auto-votes set up on large accounts - you don't see very many set to 30 minutes even though at first blush that might seem the optimal time - actual optimal time is going to be determined by behavior of other voters, and constrained by the diminishing returns the earlier you vote - for haejin/ranchorelaxos of the world I expect we will see incoming votes even earlier than the 12 minute vote.
I think your last suggestion is great, and on a related note I have actually been planning on commenting on the GITHUB proposal that an adjustment will need to be made to the automatic self-vote that an author can enable by clicking the box when posting - if that stays at 0 minutes it is obviously to the detriment of the author. Possibly that should be a slider (self vote at 0-15 minutes) with a note explaining possible diminishing returns on vote closer to 0.
That's a good point on the automatic self-vote. A default of 15 minutes would probably be sensible for new users but the opportunity to change with a slider to earlier (or even later than 15 minutes) would be useful additional functionality.
Hey @miniature-tiger
Here's a tip for your valuable feedback! @Utopian-io loves and incentivises informative comments.
Contributing on Utopian
Learn how to contribute on our website.
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Great analysis. I'm personally a self-upvoter and will lose from HF20 but if it's good for platform and leads to better reward spreading for community I'm happy. The same chunk of bigger pie is better than a bigger chunk of smaller pie. And it's must be economy and game theory leading to this state, not a hope for a "proper behavior" of wealthy individuals. Humans behave selfishly, in general and we must invent rules where optimal for individual and optimal for community is the same!
What do you think about this optimization strategy for whales: get a separate voting account and post with the poster account. Voting account votes on 0 seconds for each post of poster account? Will it work? How can it be countered?
That behavior is already countered under this HF20 proposal :) Under HF20, any vote coming in early sends rewards to the pool (or more accurately, does not claim as much of the pool as the rshares provided by the vote would normally suggest). If a whale used a second voting account to vote at 0 minutes, the vote would give 75% to the author but would claim 0 curation rewards at all. It would be a loss for the whale.
I think there are two main questions - first, is HF20 an improvement on current situation? I think the answer to that is clearly yes.
Second, is HF20 the best way to solve current situation? Here we have some disagreement, and I didn't cover alternative proposals in my analysis. Competing proposals keep the chunk of curation that a vote misses for coming in before 15 minutes in the reward pool for the individual post rather than "returning" it to reward pool at large. Reasoning is that the largest accounts get a larger share of the reward pool, so returning rewards to the pool rewards them; I counter that the largest accounts are the ones giving up large rewards under HF20, and there is no way to game the reward pool to recover a greater % beyond whatever % of the reward pool the account already controls. I believe it would be trivially easy for a large account to recover all the "missing" reward through use of alt account voting strategies if the reward is kept in the pool for the post at hand.
what an amazing splash into the world of utopian. Amazing work. Its a little late here now and I am trying to get my head around your math. So when the funds are returned to the rewards pool, when and to whom are the redistributed?
Thank you for doing this, a lot of work and time go into these analysis posts.
That is the funny part about all this - when these funds return to the reward pool, what that really means is it increases the relative value of every other vote on every post/comment. That is why I showed the % of the total reward pool that is awarded to each SP band. I don't think a lot of people realize that > 70% of the reward pool goes to accounts with < 5000 SP, which is why there is so much confusion of the "HF20 will just make the rich get richer!" type.
Ultimately the actual impact on the bigger accounts is probably even more exaggerated compared to the smaller accounts. Minnows don't (usually) have a bunch of votes automatically coming to them from a fanbase autovoter. An interesting avenue for future analysis would be to look at what % of the payout value for posts comes from votes before / after 15 minutes. I am willing to bet good money that this also follows the same general pattern, with larger accounts receiving more early votes and smaller accounts receiving next to none. Think about it this way - under HF20 any minnow / new user who writes a post which then gets found by a curator / established user with more SP and receives a vote down the road is going to get a bigger share of the pool, funded by the larger users above playing games with optimal self vote time :)
thank you for clearing that up for me. From what I am aware ( and could be wrong) the rewards pool works on a 30 day average, so there will be an initial 30 day settling period for the pool to balance out one this comes into play
One other thing that I should probably edit into the post is I just (for simplicity's sake) used the current percent of the reward pool commanded by each SP band. Those numbers are definitely inflated for the highest SP users as seen by the greater % of author rewards vs. curator rewards they receive - the actual % of the reward pool commanded by the highest SP users should decrease quite a bit once the loophole that allows > 100% ROI on a self vote is closed.
Looking at the big picture, there cannot help but be a reduction in income for the largest accounts under HF20, and this reduction in income goes to the reward pool at large where the smallest accounts will be receiving a larger % of it than they do now.
so if you dont self vote, and you are a smaller account ( like me) then you stand to have a better post payout?
For the individual account it will depend on how many votes you previously were receiving prior to 30 minutes and even knowing that we can't tell for sure if it will be net positive or negative until we know the actual amounts returned to the reward pool under HF20. Then we can calculate what the rshares received on your posts would have actually been worth when your posts paid out. It is not enough to just say you would have lost X amount from votes that came in before 30 minutes; that is only part of the equation.
Even though you are technically a "small" account it wouldn't surprise me if you personally will lose out at least a small portion under HF20, as you are definitely punching above your SP weight in terms of your average post reward.
But you also will not be one of the big losers - accounts that previously were using the 0 minute self vote to maximum effect were sometimes getting up to 800% ROI on the self vote, and the best they will hope to get under HF20 is 100% (as @tcpolymath points out in the comments here, 100% ROI at least is easily attainable by self-voting comments). That is still a huge difference of course - the accounts that combined large voting stake with use of the 0 minute self vote were previously commanding a hugely disproportionate share of the total reward pool.
The share of the reward pool dominated by 50K+ SP accounts will decrease - that is a net positive for everyone else.
Thanks for the detailed analysis.
I don't believe this is true. One of my experimental accounts has a 1c vote and has still been able to move the needle with instant votes. I should use one of the other ones and do a more-controlled experiment, though. I'll do that with @blueox in a minute actually.
I said automatically - voting comments still requires there be one at least 15 minutes old with no self vote. In practice that is likely to be easy to accomplish, but in practice a huge account that engages in that behavior would also likely result in other users setting up a script to try to front run the self vote on the comment. Either way, it isn't automatic like the current setup is (you are guaranteed a minimum of 100% return on a 0 minute self vote now), and it also won't result in greater than 100% ROI.
Ultimately I think the flaw in the way you have been looking at this whole thing is you are focusing on what accounts will lose without looking at what share of the (increased) reward pool they gain back. I think it is very clear the highest SP accounts will lose something, and the lowest SP accounts will gain something in net reward. I don't think it is possible to get exact figures in advance but there is no way this is not a net gain for the under 500 SP accounts.
This is well within our scripting capabilities. You still have to make the comments, but making comments is easier than making posts.
There's more than one way to look at losing. Both you and Paula have decided to look at what current posts will gain or lose rather than looking at how much of your stake reward will go to places you didn't choose if you vote naively. That's way more important to me. If the system is burning 7% of total vote value that means a lot to me as a voter.
I can now confirm that the idea that accounts below the dust threshold don't gain any extra value from immediate self-voting is false. I'll make a post about it a little later.
Thanks - edited the post to note this :) The broader point still stands. The accounts that previously were best taking advantage of 0 minute self voting will receive a smaller % of the reward pool under HF20 - this equals a larger % of the reward pool for everyone else. The data in my analysis above shows that it was larger accounts that were best able to take advantage of 0 minute self voting (% author reward goes up with SP). This means the effect of HF20 is net positive for lower SP accounts.
Looking at the individual cases is only confusing you, as you actually don't have the data needed to see what the payout would have been under HF20. The big picture is super clear and intuitive - there is no way around that HF20 is net positive for smaller accounts.
Even if it does narrow the rewards gap over the current system, that doesn't make them the only two choices. In fact, I see no reason to think that what you're seeing has anything to do with "returning to the pool" - it's entirely a result of removing the extra author rewards, which I fully agree should be done.
When a vote "goes to the pool" - whether it's by this method, voting on a declined rewards post, flagging, or just sitting at 100% - it fundamentally broadens the rewards gap, because it's distributed proportionally by vote size. That effect here is swamped by the fact that you're removing a ton of rewards from certain large votes exploiting the bug.
Essentially you're taking a big chunk of money and narrowing the gap, and then using it to widen the gap again, differently, and somewhat less. Taking the money is probably a good idea, but it could be used in a different fashion that doesn't do that.
At least there you are finally saying that the net effect of hf20 is to narrow the gap.
I still think you are missing the big picture. The smallest accounts are always going to have the least amount of votes coming in shortly after posting and people jockying around for optimal curation reward vote time. The largest accounts are always going to have the largest amount of votes coming in shortly after posting and people jockying around for optimal curation reward vote time. If the early curation rewards are returned to the pool, the largest accounts will "send" proportionally more reward back to the pool - it decreases the % of the pool dominated by the large accounts.
If those rewards stay in the post pool, whether it is in the author reward for the post as in your proposal or the curation reward for the post as in earlier proposal advocated by @davemccoy among others, it doesn't do anything for the smaller accounts - the % of the pool dominated by the large accounts stays the same!
In effect this argument is that smaller accounts will be more effective at discouraging pre-fifteen-minute votes (relative to total votes received) than large accounts. That seems unlikely to me since larger accounts are almost universally more sophisticated users.
I've been pondering a project to vote accounts with large expected payouts at minute zero to create this effect intentionally. I think once more people are paying attention to this issue the consensus will be that it's incredibly stupid that I will be able to do that. But we will see.
And here's the post.
What amazing splash in the world? Here's a little late. So when and when the funds come back to the awards pool, when and who is re-arranged.Thank you for doing this @carlgnash
Welcome to @utopian-io Carl!
I'll take a good look at this when I make it to the laptop. It didn't come through the normal route because the first tag should be utopian-io, and the 2nd analysis. Not to worry, I'm hoping it will be scored according. Nice!
(Trust my autovote not to work on a 200$ post!)
Aw snap rookie mistake LOL. The funny thing is I actually copied the tags directly from @paulag 's post here since it was on the same topic and I knew it had been accepted by @utopian-io : https://steemit.com/analysis/@paulag/hf20-exploratory-data-analysis-on-proposed-payout-changes
I was going to go look up the rules and guidelines and what not but I figured Paula had to know what she was doing :) LOL
Hey @carlgnash. It's an honest mistake. Join the utopian discord and mention it. They will help you and most probably still review it. They just use the tag to find it.
Hey @carlgnash
Thanks for contributing on Utopian.
Congratulations! Your contribution was Staff Picked to receive a maximum vote for the analysis category on Utopian for being of significant value to the project and the open source community.
We’re already looking forward to your next contribution!
Want to chat? Join us on Discord https://discord.gg/h52nFrV.
Vote for Utopian Witness!
Can you determine that this change doesnt just increase the take by the trending page?
Minnows hardly get a majority of rewards, if i am guessing correctly.
It seems to me if the lion's share of rewards are sent to bidbots and trending, that that will also increase.
I would like to see these rewards burned, thereby benefiting all stakeholders equally by decreasing supply and inflationary losses.
Further i would like to see flagged rewards being burned.
Flagging trending is futile if the rewards are just transfered to the next post down the list.
While we are at it, declined rewards could be burned, too.
Again benefiting all stakeholders.
I dont have the skillz to do this myself, and would greatly appreciate it if you would look at the numbers so i can put the issue to rest, or start beating the drum harder.
Thanks.
One thing that there is absolutely no doubt on is that HF20 will dramatically decrease the return possible through using bidbots. It won't do anything about how attractive delegating SP to bidbots is unless that actually equates reduced demand/use, but it will eliminate one of the major ways that you could actually turn a profit by using bidbots. Under status quo users self upvoting at 0 minutes on a post that they buy a large vote for get a portion of the curation reward that would have gone to the bid bot.
I will have to look into effect of actually burning that reward vs. just ignoring the effect of those rshares on the reward pool as HF20 does. If I get some time I will try to dig up some answers.
Ok, thank you.
I just see flagging trending as futile if the rewards just go to the next post down, where burning them takes them off the table.
Its double edged, in that flagging spam wouldnt return the rewards to proper authors, but i think the deflationary aspects mitigate against that.
How does this change better ensure that truly high quality posts will get higher author rewards? How does it simplify the effects of a vote, such that a normal user (one that doesn't read the code or do a bunch of experiments) will know when and if to vote to get the effect they desire? How does it reward curators who find and highlight truly high quality posts? How does it allow us to simplify the FAQ so that new users will quickly and easily understand exactly what their vote will do? And if it can't do these things, why would it even happen? Perhaps we should all get to vote on it, or try it for a few months and then vote yay or nay.
Todd
Well a lot of those things are outside of the scope of the proposed changes in this hardfork :) That doesn't mean that what the hardfork does do isn't worthwhile. This particular change to curation rewards will increase the total % of the reward pool that goes to curators, by 6% (curators currently only get 19% of the reward pool, and will get 25% under HF20).
My point is that those are the things that need to be worked on. It sounds like HF20 just further obfuscates things. New users get virtually nothing from curation, but if I create a post or comment, at least I know that I can get something by an immediate upvote. Now I don't think it should be even possible to upvote yourself as that is a clear conflict of interest, similar to paying for votes. I realize that there are all sorts of game theoretic reasons for the way the algorithm is set up, but these are necessary only because of certain other design choices. I also realize that doing this right is hard, but I always use StackExchange as a counterexample to Steem where, despite no reward pool and no blockchain, the content quality is extremely high. There is also a certain psychological aspect here. If new users don't feel that Steem is fair, or feel that it is too complex, they are unlikely to continue. I suspect this has a lot to do with the low retention rate. Setting up rules that make steem essentially the equivalent in complexity of CDOs (collateralized debt obligations) doesn't seem like a very good recipe for success. For me, the main incentive to be here is not because of what steem is now, because it seems deeply flawed, but rather what it (or some other fork) might become. But I'm a geek when it comes to these things, not a normal facebook-type user.
I don’t really understand most of it, but I’m glad you posted it anyway so I can learn a bit more about the HF20.
Wouldn't everyone just vote for posts that are at least 15 minutes old?
If by "everyone" you mean the large self-voters who are currently voting at 0 minutes, it isn't quite so simple. If they switch to voting at 15 minutes, another user chasing curation rewards can simply upvote the post at 14 1/2 minutes - losing a small bit of the curation reward for voting slightly before 15 minutes, but gaining a portion of the curation reward for the huge self-vote that will come behind them at 15 minutes. In actual practice the optimal time to self-vote for a large account will likely be earlier than 15 minutes, which means giving a portion of the reward from the upvote back to the reward pool.
We already see something like that currently when it comes to users attempting to maximize curation rewards on auto-votes set on other user's posting - even though currently a vote at 30 minutes might seem to be the optimal time to vote since it gives full curation reward, in practice the optimal time to set an auto-vote on another user's posting is usually somewhere around 20 minutes or so - the game is to vote early enough to come in before other votes, but still vote as late as possible to maximize the % of curation reward.
Removing the 0 minute self-vote loophole will cause something similar to happen for self-voting.
i am still not sure I understand it, but I may not really need to. So using some real numbers and fake ones.
Pre HF20 Whales 75% of reward pool everyone else 25%. So whales get $75 and everyone else $25.
Post HF20 Whales self vote 75% of the time everyone else 0% of the time.
Whales Reward pool 75%- 25% (for all the early self votes)= 50% of reward pool and everyone else 25% of reward pool.
Pre HF20 reward pool=$100 Whales ge $75 and Everyone Else $25
Post HF20 Reward pool=$100 Whales get $56.75 and Everyone else $43.25
The 25% that was returned to the reward pool goes to the all the others so would that be kind of close to what you are saying ?
Apples and Oranges, but is it close? Can you show what it would be with the assumption I used of whales and everyone else above?
When do you plan to stop Vote-buying Bid Bots
or that is out of the question?
Congratulations @carlgnash! You have received a personal award!
Click on the badge to view your Board of Honor.
Do not miss the last post from @steemitboard:
SteemitBoard World Cup Contest - Semi Finals - Day 1
Participate in the SteemitBoard World Cup Contest!
Collect World Cup badges and win free SBD
Support the Gold Sponsors of the contest: @good-karma and @lukestokes
I missed this post complete, I'm sorry @carlgnash, but what a really fantastic analysis you have made here. I have to read it a few times more but it really helps me to understand some more of the steemit platform and the curation rewards.