Steem Simplicity 0.17.0

Steem Simplicity 0.17.0 Release Notes

The hardfork is schedule for Tue, 21 March 2017 15:00:00 UTC (11:00:00 EDT)

All witnesses should update to 0.17.0

Note: Witnesses running 0.16.0 may need to resync due to bug fixes with the block log. Witnesses running 0.16.X should only need to reindex.

Overview

This Hardfork is about simplifying the comment subsystem both for end users but also technically to improve performance now and into the future.

Remove Posting Rate Limit.

Posting rewards are no longer penalized for posting more than 4 times in 24 hours. Originally this was implemented to reduce the impact of bots posting junk content. Ultimately it ended up hurting legitimate authors.

The comment depth limit has been increased to 255.

The limitation was created to make UI design easier. Many changes we are making are to do right by the blockchain and have the UI adapt. Each UI can and should choose how deep of comments they want to display and can actively reject comments that are deeper than the limit they wish to display. The soft limit is 255 with a hard limit of 64k. 64k was chosen as a limit because the depth is stored on each comment object. This allows us to use a 16 bit field and 64k should be more than enough depth for anybody. (Reddit has a limit of 10,000)

Comments can now be permanently edited.

We are adapting a new model of imposing as few restrictions in consensus code as possible and having witness actively reject transaction for both rate limiting and security. There is a soft freeze of 7 days that will be lifted with a non-consensus operation. This custom operation still needs to implemented, but will be included in 0.17.1. The operation will be a plugin op in the witness plugin that will inform a witness to accept edits for the next T minutes.

Comments are now paid out independent of their discussion.

Paying out discussions as a whole was a design decision to make displaying discussions by total_children_rshares2 easier. It also made sense to do this with multiple payout windows. This tight coupling ultimately has proven unnecessary. Removing restrictions on depth and editing makes this idea antiquated.

All comments are paid out 7 days after creation and there is no longer a second payout window.

99% of votes are cast in the first 7 days after creation. This elimates the need for a second payout to accumulate value to a post and simplifies logic significantly.

There is now a comment reward fund separate from posts.

We want discussion to be incentivized. Currently, comments are only claiming 2% of the content rewards and there are more comments than posts. Comments will receive 38% of the content reward fund. This change should incentivize commenting, engaging in, and curating discussions.

All payouts now look at the prior 30 days of payouts to determine the share of the reward rather than the current pending rshares.

The reason for this change is twofold. 1. Looking at a 30 day decaying window reduces variance in payout due to small changes in vote densities. 2. On votes we are currently updating the comment the vote is on, every comment in the tree up to the root, and the global property object. With this algorithm we only need to update the comment, significantly reducing the amount of time spent processing votes. With this change, payouts will initially dip and then ramp up over the next 30 days until the reward fun reaches a steady state.

Reward Balance

Rewards will now go into a separate reward balance that must be claimed before they can be used.

Comment Reward Beneficiaries

All content can now specify beneficiaries to receive a part of their author rewards. The beneficiaries are specified in the extension field of the comment_options_operation and is a sorted vector (by account name) of account name, weight pairs. The beneficiaries can only be specified once and must be specified before any votes are cast on the comment. Most apps are already adding a comment_options_operation in the transaction that creates the comment, so this should not be much of a challenge to add to existing apps

Delegated Steem Power

Steem Power can now be delegated to other accounts. This transfers content voting rights and bandwidth allocation but not witness voting rights. Delegations come in to effect immediately, both when increasing and decreasing a delegation. However, Steem Power being returned by decreasing or removing a delegation has a one week delay in limbo before it is returned to the owner. This is to prevent a satoshi of Steem Power from being able to vote on the same content twice.
Accounts cannot power down Steem Power that is being delegated, nor can they delegate Steem Power that is being powered down.

Accounts can be created with a smaller fee and an initial Steem Power delegation.

Instead of paying the entire account creation fee with Steem, creators can now pay a smaller fee (30x less) and delegate some Steem Power for 30 days. The exact amount is 5 * min_fee + STEEM_POWER == 150 * min_fee. You can pay any combination of STEEM and Steem Power along that curve (so long as the minimum fee is paid).

The witness voted STEEM fee is now the minimum required STEEM fee for delegation. Witnesses should reduce their fee by 30x when the hardfork goes live to preserve the same required fee for an all STEEM account creation.

PoW is being removed.

PoW has been broken for a long time. Very few people pay attention to it. It is dominated by the same few people and is providing very little value to Steem. Instead of investing even more time fixing it, we have decided to remove it entirely.

NTP is disabled by default

There is an option, enable-ntp that can be set to true in the config file to enable ntp in steemd. All node operators should begin using ntpd as we will be removing ntp from steemd in a future release.