Hi everyone,

As the hardfork is rapidly approaching I would like to share my thoughts on each of the items mentioned. Overall I think the changes will be good, but I don't like the comment reward fixed split option. I will be upgrading my witness to be ready, but I would prefer an option which did not include the comment reward fixed split. Thank you for your time.

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.

Approve- I think overall this will have a positive impact by simplifying things for users and any abuse would be more noticeable now that we have a more active community.

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)

Approve- The less intrusions from system rules to the user, the better.

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.

Approve

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.

Approve

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.

Neutral- I think the main concern associated with this is the possibility of long term value posts missing out and receiving smaller payouts if they are not voted for right away. While I agree with the concern, there are still ways for posts to receive payouts as long as comments are treated separately(can be made on posts of any age and payouts timelines are not related to the original post). To continue receiving payouts, the author could comment below their post and modify the original to direct people to vote for the comment. This would obviously complicate things and for it to be usable, most aspects would have to be hidden from the users. The question then would be whether the added complexity is worth the gains from simplifying the blockchain logic. Since I don't have a good enough understanding of the tradeoffs in these two scenarios I am holding off from making a decision.

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.

Reject- The comment rewards do seem a little low, however I don't like the idea of forcing a specific split. While I understand that this number could be adjusted, I think finding a correct setting may be difficult in the long run. In addition, other changes to the system associated with voting(voting curve flattening, abit's no whale voting experiment) may have a positive impact on the comment rewards situation. If the lack of comment rewards was simply another symptom of concentration of voting power then it would seem wise to see if comment rewards change as a result of these other experiments.

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.

Approve- I think this is reasonable as long as it is easily accessible in the gui.

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

Approve- Probably one of the most exciting aspects of this hardfork, which will hopefully open up new business opportunites for developers building on steem.

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.

Approve- This seems like an interesting change which could provide an additional opportunity for steem holders, besides voting with it themselves.

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.

Approve

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.

Approve- I have no problem with this. As someone who has used this feature in the past, it actually seems more like a distraction from the real product than anything else. Also having the extra funds to support an additional full time witness seems like a better use of the blockchains funds.

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.

Approve