Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redefine long term voting rules #177

Closed
mvandeberg opened this issue Jul 19, 2016 · 10 comments
Closed

Redefine long term voting rules #177

mvandeberg opened this issue Jul 19, 2016 · 10 comments
Assignees
Labels
Milestone

Comments

@mvandeberg
Copy link
Contributor

Proposed Changes

For the most part, voting when a post is new works great. The viral nature of great posts quickly rise to the top, however there are many great posts that receive votes but do not receive a great payout at all. We want authors to be able to receive something for their efforts, even if they aren't viral, but do so in a way that isn't easily farmed.

There are several changes being made in this proposal that will achieve this goal.

  • Initial payout stake weight time is being reduced to 12 hours.
  • After the first payout, a second payout time is hard set 30 days after.
  • Curation rewards only count for the first payout (This is already the case)
  • Comments will be editable up until the second payout. After the second payout the post is frozen and effectively archived.
  • Users will be able to upvote and downvote frozen content without costing voting power and not rewarding reward shares, only costing bandwidth.
  • For low memory nodes, we will be clearing comment votes on frozen posts and removing all extraneous data from comments. The only consensus required data for a comment when it is frozen is author and permlink.

Effect

The effect of these changes is that trending content will rotate out about twice as often. Content payouts should be roughly the same. Posts that have slower growth can accumulate decent payouts over 30 days. This should help alleviate the disappointment when your content does not explode. You can still get a good payout through this longer second payout.

Allowing edits for 30 days provides a good middle ground between not preventing editing too early and allowing content to be edited forever. However, to make things more intuitive for the user we will not prevent voting of frozen posts. Instead, votes will simply happen with no effect on consensus. A vote operation on a post that is frozen will go through as an effective no-op, only charging the user for their bandwidth. Applications can choose to do whatever they wish with the vote.

Reducing the amount of data for consensus will slow our ever increasing memory footprint.

@mvandeberg mvandeberg added this to the Hardfork 12 milestone Jul 19, 2016
@mvandeberg mvandeberg self-assigned this Jul 19, 2016
mvandeberg pushed a commit that referenced this issue Jul 19, 2016
@iamsmooth
Copy link

iamsmooth commented Jul 20, 2016

Not sure about 12 hours. Perhaps better to reach every time zone once at least before closing the first period? Not all, but a lot of content is global in nature.

@mvandeberg
Copy link
Contributor Author

mvandeberg commented Jul 20, 2016

The reason for this change is that a lot of content is staying at the top of trending much longer than 24 hours. The 24 is simply the delta from the head block time that a vote is voting for. So a large vote with 6 hours to go could extend the payout time significantly. We are expecting that most of the top content will still be around for 24 hours. The other change that goes hand in hand with this one is the extended 30 day second voting period. If a post does not sky rocket, it can still accumulate votes over the next 30 days and get paid as a lump sum. We have noticed that posts tend to go viral and make a ton, or votes trickle in for pennies. This will let the pennies begin to add up to something meaningful. It should also encourage users to create quality content not based entirely on how viral it is.

It is worth mentioning that we plan on moving this parameter and many others to a consolidated witness vote so that witnesses can tune them without the need of a new release. If 12 hours isn't quite right, it will be easily changed very soon.

mvandeberg pushed a commit that referenced this issue Jul 20, 2016
@iamsmooth
Copy link

Sounds good, thanks for the explanation.

@xeroc
Copy link

xeroc commented Jul 22, 2016

I see the advantages of having a longer period of time before the second payout so that authors can accumulate their reward, however, I do not see any reason why a post should be frozen after roughly 30 days. This will prevent me from supporting any of my old posts. People might have question on posts that I made months ago because it went viral and still sticks around on Google. IMHO it would make more sense to just remove all kinds of rewards after 30 days and let the discussions continue.

// edit: this explains the release better: https://steemit.com/steem/@steemitblog/steem-version-0-12-0-released
With that, it makes more sense. Good job

@tchap
Copy link

tchap commented Jul 27, 2016

Not sure how viral you need to get to stretch the period to 24 hours. https://steemit.com/steemwatch/@void/steemwatch-0-5-0-is-deployed-real-time-event-stream-is-online is a pretty popular post, payout after 16 hours. People still voting rather often, but I have to wait for 4 weeks now :-)

@samupaha
Copy link

The reward payout system will affect greatly what kind of content is produced in Steem. I think this should be thought from a blockchain perspective first, and then adjust Steemit.com to act accordingly. Right now most of the rewards are dictated by Steemit.com mainpage (basically the current trending-algorithm).

When the thing that affects the most is not the reward algorithm but the website, it would be better to change how the website presents the content, rather than try to adjust blockchain rewards.

I don't know what is the best solution to this, but I suggest that you approach this problem from a long term perspective. In the future there will be a lot of different communities, UIs, applications, etc. build on top of the Steem blockchain. Rewards will make some of them thrive and some of them fade away.

When changes are made to reward payouts, it's more important to think what the effect will be in ten years, not what it'll be in the next week.

I just wrote about this topic: https://steemit.com/steem/@samupaha/what-is-the-ten-year-vision-for-steem-blockchain

@grctest
Copy link

grctest commented Sep 8, 2016

Sorry if posting here is inappropriate, but I've just encountered one of my steemit threads that I have been continuously directing users to being 'frozen' after only 30 days.

Reddit allows for posting within threads for up to a year (if not more depending on what sub you visit).

I simply don't get the logic behind how this is supposed to support low paid users who never reached the trending page & who post to small communities which don't reach the trending page - I'm not going to continuously spam the exact same topic every 30 days (causing a larger data impact/footprint on the network than maintaining a single thread) but will rather move the discussion entirely to an existing communication platform that doesn't lock the thread after 30 days. (I'll still use Steemit, but for serious long term discussion it's not suitable).

Fair enough lock the original post, but preventing replies after 30 days kills the discussion entirely & likely confuses new users who encounter the 'discussion frozen' error prompt.

Edit: What about a compromise? Pay x SBD via post promotion = postpone topic freezing?

@roguesupport-scott
Copy link

I know FOR A FACT that over 400 people upvoted my first article.

It says I made 9 fucking cents and has zero votes.

Steemit is a scam, or a broken piece of shit. It's NO REDDIT.

@mvandeberg
Copy link
Contributor Author

Can you please link to the article in question so that we can investigate what happened to the payout of the post?

@theoreticalbts
Copy link
Contributor

Oops, accidentally changed milestone from HF9 to HF12. So I changed it back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

8 participants