You are viewing a single comment's thread from:

RE: Steem 0.17 Change Proposal Introduction

in #steem8 years ago (edited)

These changes, if all made together in a hardfork, would represent the largest change to Steem since the chain began. I think bundling the amount of changes (including the change to Chainbase in with the economic changes) in the last hardfork was a risky choice for the main chain.

Changes and their effects will be more understandable for everyone if they're paced.

Therefore if I were to lay out a plan of changes I would keep these in 17:

  • Removing Over Posting Reward Penalties
  • Comment Payout independent of Discussion
  • Removing the Comment Nesting Limit
  • Normalize Payout Rates
  • Removing Proof of Work
  • Remove Bandwidth Rate limiting from Consensus
  • Multiple Arbitrary Beneficiaries to Reward Payouts (needed for Busy's imminent launch)

And defer these to the next or subsequent hardfork:

  • Single [7-day] Payout Period
  • Allow Editing of any Past Post or Comment (if "switch" code isn't implemented)
  • Independent Comment Reward Pool
  • Separate Market and Rewards Balance from Checking and Savings
Sort:  

I understand the spirit of what you are saying, but clearly you don't grasp how the code is organized. Moving to a single 7-day payout period and allowing editing of past content are tightly coupled with the logic that must be touched to implement the top items.

Of the things that could be delayed until 18 I would say:

  1. independent comment reward pool
  2. Separate market
  3. Separate rewards balance
  4. Normalize Payout Rates

Alright, thanks for the clarification.

Multiple Arbitrary Beneficiaries to Reward Payouts (needed for Busy's imminent launch)

The bold is not really true. Economic incentives for clients, etc. is more of a longer-term issue, particularly given the low price of STEEM and accordingly the low total value of rewards (and in turn the value of the small slice of that a UI would receive). I'm not sure that the Busy team would prioritize implementing this in the first public release even if the blockchain supported it (likewise for other clients)

It's not technically needed, true. And like you say, I don't know if Busy.org would implement it from the get-go. I'll ask. Edit: According to ekitcho, it's not a big immediate priority, but they are counting on the change [as part of Busy's model].

In any case, this is one change that gives more potential to Steem as a platform sooner rather than later because there are front-ends in the works that would benefit and be incentivized by it.

No doubt, I think it's a great addition.