Instead of having Steemit community members vote by clicking on a button, something that requires virtually no effort/ time on the member's part, have them vote with their time*.
With Steemit's current voting system it's all too easy and, IMO, far too common for people to up-vote a post without even taking the time to click on the post's link to have a look at its content. People are simply gaming a post's "perceived popularity", without so much as giving a minute of their own time to really rate it. It literally takes less than two seconds to up-vote a post and there's little incentive to up-vote content that we really like, because everything (in terms of financial rewards) is based on what up-buttons we click on.
Now, if we were to suddenly make it where each member votes with their time spent on a post and the accumulated time spent on a post between all members were the determining factor of author payout, these members would have the added weight of now having to spend their valuable time and energy to cast their "likes". IMO, people now would be less likely to vote on content that they really don't like, because doing so would require spending more time on posts that don't really interest them.
Of course, having more SP should still offer more curation rewards and it can, with a simple formula which takes both time spent on a post and SP into account.
I'm going to use a few arbitrary values as an example of how this could work in the Steemit "real world":
Let's say that SP holders are rewarded an additional one one thousandth (1/1000) of a second for every 10 seconds spent on a post, per every 1 SP. Now let's cap the time spent at a 30 minute limit, because. let's face it, a blog post should never take more than a half of an hour to read through, even when it's relatively long.
The above image is taken from Steemd.com and it lays out the current SP distribution of Steemit's members (where 1 MV = 1M VESTS = 339.867 STEEM = $180.469). As you can see, 51.27% of Steemit accounts are "newbies", or have SP values worth around $1.80 (somewhere between $0.01 and $10, I assume), yet they only combine for 0.02% total stake in SP.
This means that if every account up-voted one time in a 24 hour period, each on a different post, each being the only up-vote for that post, and assuming that they all average the same number of votes per 24 hours (voting power calculation takes both SP and votes per hour into account), then the 1,944 newbie accounts would only distribute 0.02% of future Steem. This explains why a minnow's early up-votes (first up-votes to a post) are only worth fractions of a fraction of a penny to the post author at this time.
Let's say that we use the following simple formula, as an example:
(T/ I) * (S * V)
Where;
T = time an account spends on a post, in seconds (capped at. let's say, 30 minutes worth of seconds = 1,800 seconds, payable)
I = "voting second amplify time", number of 10 second intervals that the account spends viewing the post
S = "voting seconds" (VS) payout of, let's say, 1/1000 of additional seconds for every 10 seconds spent on post, per 1 SP.
V = account SP value
Using the above values, a 30,000 SP account spending 15 minutes on a post would provide the following payout:
[(15min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (30,000SP)] = 90 * 30 = 2,700 additional voting seconds
We'd add this value to the "actual time spent on the post" (15 minutes, or 900 seconds) to get our total payable, curation reward, time of: 900s + 2,700VS = 3,600 "payable curation time" (the value that's used to calculate the percentage of Steem payout to the content author and the potential curation reward payout to the account which made the vote).
The "actual time spent on the post" (ATOP) can be divided by some factor to decrease the weight of that value on curation reward potential. For instance, we can divide ATOP by 10 to give that value 10 times less weight compared to SP.
The above example would then have a total payable curation reward time of:
(900s / 10) + 2,700VS = 90s + 2,700VS = 2,790 payable curation time.
This is where we can give minnows more voting power. Let's assume that we stick with the original calculation (without diminishing the weight of ATOP), keeping the SP portion of the calculation as it is:
Now, let's look at a minnow that has only 10 SP, but spends 30 minutes reading a post. Here's what the voting power calculation would look like:
[(30min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (10SP)] = 180 * 0.1 = 1.8 additional voting seconds
then, 1,800s + 1.8VS = 1,800s + 1.8VS = 1,801.8 payable curation time.
The 10 SP account spent twice the time on the post as the 30,000 SP account. This is time that could have been spent reading another post or doing something else - time is valuable and so is the energy that's spent by our computers as we keep a post up inside of our browsers (therefore we're punished for keeping a post open that we don't really like)! So the lower SP account spends twice the time in order to provide the content author with about half of the Steem reward and, therefore, has half of the potential curation reward payout as the higher SP account, all else being equal.
Now let's consider an account that holds over 1 million SP. Let's assume that this account spends one minute on a post. Here's what the calculation would look like:
[(1min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (1,000,000SP)] = 10 * 1,000 = 10,000 additional voting seconds
then, 60s + 10,000VS = 10,060 payable curation time.
This whale spent 1 fifteenth the time of the 30,000 SP account and 1 thirtieth the time of the 10 SP account on "voting", yet still provides a 279% and 558% better author reward and curation reward potential, respectively. The whale's much higher SP value makes his/her time more valuable to the post author and rewarding to the whale, in terms of curation rewards.
The main difference between this approach to distributing Steem versus the current model is that it should work out where the whale has significantly less voting power compared to minnows, unless, and here's the rub, the whale decides to spend a lot of time on a post(s).
Of course, it would have to be worked out how to make it such that one account can only be spending "voting time" (*VT) on one post at a time and, IMO, there should be a cap on how much VT any account can give to a post. Otherwise we could have a situation wherein a whale leaves a post open for days on end and the post author gets an endless stream of high Steem payouts (or, at least until the payout cut-off).
Now a whale can pay an author up to 30 minutes worth of TSOP.
Going back to the 1 million SP example, the capped limit would look as follows:
[(30min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (1,000,000SP)] = 180 * 1,000 = 180,000 additional voting seconds
then, 1,800s + 180,000VS = 181,800 payable curation time.
Even if the whale keeps the post up for 300 days, his payout to the author will remain capped at 181,800 "payable seconds" of vote, and his curation potential will remain capped there as well.
I'm not convinced that any accounts should have a cap on how much voting power that their time spent on any new posts will have, even if they've reached the time limit on prior posts. This way, our time spent on Steemit is highly incentivized.
I think that the current curation system of paying out the majority of the supply to the "early voters" should remain in order to battle against people jumping on late to bank on all the voting hours that go into a post. I also think that it would be beneficial to delay the reporting of voting hours by an hour or more in order to hide whale votes long enough to make the high payout content (in terms of curation rewards) less noticeable.
Everything should be geared at diverting most of the user bases' focus at spending more time on content that they actually like, versus on those posts that they believe will be more popular with the majority of the user crowd.
So each account has an attached SP value. Most accounts (over 50%) have between 1 cent and $10 worth of SP. That being said, all of our time (all Steemit users) is valuable.
My suggested payout system takes the second point into account. Instead of basing Steem distribution on where we each place a few clicks, my system bases it on where we each spend our time and it only rewards those that take the time to look over Steemit content.
Therefore, if the Steemit whales spend a combined 30 minutes worth of time looking over Steemit content within any given 24 hour window, then they will only be rewarded for those 30 minutes worth of VT and they will only take up that portion of the total VT pie for the day. Should the minnows combine to spend hundreds of thousands of hours looking over posts, then their combined time and energy will more than make up for the whale's higher SP, and their votes will make up the majority of the voting power for that day as a result.
This is easily proven by looking at the math:
[(30min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (1,500,000SP)] = 180 * 1,500 = 270,000 additional voting seconds
then, 1,800s + 270,000VS = ** 271,800 payable curation time**.
[(120min * (60s/ min)) / (10 seconds voting second amplify time)] * [(1/1000 voting seconds per 1 SP) * (10SP)] = 720 * 0.01 = 7.2 additional voting seconds
then, 7,200s + 7.2VS = ** 7,207.2 payable curation time** per minnow.
therefore, 7,207.2 payout per minnow * 1,000 minnows = 7,207,200 total payable curation time for the 1,000 small SP accounts
In this case, assuming all else is equal, the minnows would provide a combined 2,669% more voting power than the whales. Why? Because, yes, SP is valuable, but time is valuable, too. Thirty minutes of combined whale up-voting, no matter how high their combined SP values, should never be worth more than 2,000 combined hours of up-voting, I don't care how low their combined SP values.
This is what Steemit is missing, IMO. Our time spent curating needs to be rewarded, not just our SP value and the timing of our up-votes.
That the cap limit doesn't really limit how much a post can potentially be paid out on any given day. If, for instance, every active account for the day were to spend all their time viewing a single post, be it for only a few seconds or for well beyond 30 minutes on average, then all the Steem payouts for that day will only go to that post author. It all comes down to the pie chart of VT distribution for the day, taking the 30 minute payout limit into account.
Furthermore, poor quality posts are very unlikely to receive high Steem payouts, since the combined VT that goes into their post would have to take up a relatively large portion of the combined VT pie chart for the day in order to receive a high percentage of the daily SP payout. Even having 30 minnows vote with their time, each spending 1,800 seconds on a post, would only amount to about 54,000 payable time, which is easily surmounted by a single whale spending a minute or two on some other posts. The difference now is that whales are forced to spend more than a few seconds to vote up posts; they're forced to actually look at the content!
It would seem to me that this would help out with the bot system that seems to be taking over on the curation side of Steemit over the last weeks, but perhaps I'm missing something (could the bots be designed to open posts from popular authors and then spend 30 minutes on them before moving on to the next high payout potential post?) Any feedback on this would be appreciated.
But I'm aware that I can't see all the angles on this and I don't know how this kind of system could be programed into Steemit, or if it's even possible.
That's why I would like to create a discussion about this suggestion with anyone who's willing, @jamesbrown. I invite constructive criticism, tweaks to my suggestions and alternate solutions. Let me know if what I suggest is feasible and/or if it's even an improvement. Share why it can or can't be implemented into code, if you're skilled in that area and happen to know if, and how, it can be done.