Upgrade Steem Economic Model

[bytemaster]

Set a fixed instantaneous annual creation rate of 9.5% from all sources (except Steem Dollars conversion)

Allocate 75% of the created Steem to the Reward Fund.
Allocate 15% of the created Steem to the Vesting Fund as interest on Steem Power.
Allocate 10% of the created Steem to the Witnesses.
Witness rewards would be rebalanced such that the top 19 would earn 1/29th of the witness rewards, the runner up witnesses -would share 5/29th, and the miners would share 5/29th.

Witnesses and miners would be paid in STEEM rather than Steem Power. All votes for witnesses would expire after 3 months, this would remove the incumbent advantage and require people to continuously evaluate and vote for witnesses.

To support more equal opportunity mining the mining algorithm would be updated to use Equihash (similar to zcash).

Reducing the Steem Power holding period to a minimum of three months.

Lastly, under the new inflation rate there is no longer a need to perform a reverse split every 3 years. This would greatly simplify the life of exchanges.

Reduce the SBD delay from 7 days to 3 days and the median period should match.

[Gandalf-the-Grey]

"Witnesses and miners would be paid in STEEM rather than Steem Power."

If we are considering also reducing power down 2y period to 3m, above isn't something making a big difference.

All votes for witnesses would expire after 3 months, this would remove the incumbent advantage and require people to continuously evaluate and vote for witnesses.

Conscious users re-evaluate their votes continuously anyway. I'm afraid that this would impact network reliability / security. Those from big stake holders that are more technical would run bots to update their votes. Which would make unnecessary transactions just to keep status quo. Again, changes to Steem Power would cause more impact to witness list than above.

Equihash, that sounds good.

[taoteh1221]

Awesome proposal @bytemaster . I think you just saved an awesome platform if it is accepted by the community.

[VIM-Arcange]

To support more equal opportunity mining the mining algorithm would be updated to use Equihash (similar to zcash).

Someone on Golos suggested to link mining computation power to something useful for the society like computation of protein folding or docking of molecules.
Miners would get double incentive: reward from the cryptocurrency platform and reward from the related computation project.
Moreover, you will be able to add some "ethic" label to your platform.

[bytemaster]

@VIM-Arcange linking mining computation to real world benefit is incredibly challenging to do in a decentralized manner. It is also far beyond the scope of this change.

[gamerate]

I actually suggested using mining to do something useful like molecule folding or docking, but I don't mean to propose implement it's right away, but discuss and find ways to do so in the future, I know some startups who tries to do so and they will need computing power...

[etestol]

Great changes by the way.
Where I can find more info regarding Equihash?

[arhag]

In this line the comparison should be greater than, not less than or equal to. Also, I am pretty sure the 19 in the two lines below it should be a 21 instead. So these lines should instead read

      if( wso.vote_threshold > cwit.votes ) {
         witness_reward = (5 * witness_reward * 21) / 29;
      } else {
         witness_reward = (1 * witness_reward * 21) / 29;
      }

But even with that correction, this is not that great of a way of distinguishing between the top 19 and the rest, because the votes for the rank 19 can change within the round.

Assuming (and all three of these assumptions seem pretty reasonable to me for typical scenarios)

• witness ranking order doesn't change within the round,
• the rank 18 witness does not end up with less votes by the time of the block they are scheduled to produce in the round compared to the votes that the rank 19 witness had at the start of the round,
• and a rank 20 runner-up witness scheduled to produce a block in the round continues to still have less votes by the time of the block they are scheduled to produce compared to the votes that the rank 19 witness had at the start of the round (and assuming they weren't exactly tied to begin with),

then currently implemented algorithm follows what I consider to be the obvious intent of your witness pay re-balancing proposal only if one other assumption is also true: the rank 19 witness does not end up with any less votes by the time of the block they are scheduled to produce in the round compared to the votes they had at the start of the round. This means if there is any (even by one milliVESTS) net decrease in votes for the rank 19 witness between the start of the round and when they are scheduled to produce a block (on average approximately 30 seconds), the rank 19 witness will be paid as if they are a runner-up witness. Even without abuse, this seems pretty likely with a large userbase given random fluctuations in people's witness voting patterns.

But the problem gets much worse when you consider that there is a financial incentive to make the above event happen intentionally every round: the rank 19 witness, and perhaps many other top witnesses could manipulate the system to earn 5 times their intended pay (which would by the way increase the intended overall inflation rate from 9.5% to up to 13.3% if all top 19 witnesses abused this system in that way). After the start of the round, they would broadcast a transaction to unvote their own witness with a high stake account so that the votes for their witness goes below the threshold (would no longer be in the top 19 for the next the round). But then after producing their block and receiving their 5x larger reward, they would broadcast the transaction to revote for their witness and get back to the original spot they were at so that they are scheduled to produce a block again for the next round.

Even though I disagree with this entire mechanism and have an alternative proposal for how witness pay budgeting should be done, if you do want to keep something like this mechanism, I think that you at least need to track, at the level of each witness object, whether they were scheduled for that round as part of the top 19 or not (or even better distinguish whether they were scheduled as top 19, runner-up, or miner). That field would be updated for exactly 21 witness objects in update_witness_schedule4. Then when it comes time for payout, you simply payout according to the value of that field.

Also, what is going on with this change from an if statement to a while loop? That isn't a hardforking issue is it?

[bytemaster]

Switching from an IF to a WHILE allows it to shrink. Prior to the hardfork it would reach the max size and then hold there (popping one for every pushed). After the hardfork the number of items will have to shrink.

You are right about the potential for abuse with my implementation. Will need to fix that.

[mvandeberg]

Following the model for our previous hardforks, the change to the price feed should happen at the time of the hardfork (in apply_hardfork) and the feed history window variable should be assigned one of two constants when the price feed is updated. The benefit of this approach is that the intent of the hardfork is much clearer and there is significantly less refactoring of the code to be done if we do a pitchfork in the future.

[thecryptofiend]

Do we have an ETA for when these changes will be implemented?

[arhag]

@bytemaster, @mvandeberg: Still no change of the 19 number to 21 in these lines. Add up the witness rewards given away in a round (assuming 100% participation) and you will see that the current implementation delivers 19/21 of the amount intended according to the proposal.

[arhag]

@mvandeberg: You missed changing the 19 to 21 on this line as well.

[bytemaster]

I think we need to reduce the miner reward to equal the top 19. That will ensure things are fair whether there is 1 miner or 100 miners.

[mvandeberg]

Does this remove the higher pay to the time share witness as well or only the miner?

[klyed]

Hey Dan, Hope all is well.

Could I possibly interject and propose we get rid of the mining slots altogether with?
Miners have no loyalty nor want to help the network, they think only of profit for the most part.

While I can understand the reasoning behind wanting to have miners be able to come and grab STEEM at the end of the day it is sort of a "hole in the bucket" so to speak. let alone when we've got one maybe two parties dominating the mining queue with either private GPU miners or exploiting some currently unknown bug.

Also on a side note.. (this likely isn't the correct place to ask but as you've seen I'm a bit of a bullmoose in a china shop) who would I ask permission to to start doing some front end tweaks for Steemit.com and commiting them? I'm getting near completion of streemit.online and once I have a bit more free time I wouldn't mind lending my skills to the Streemit Inc team to help where I can. :)

[abitmore]

who would I ask permission to to start doing some front end tweaks for Steemit.com and commiting them? I'm getting near completion of streemit.online and once I have a bit more free time I wouldn't mind lending my skills to the Streemit Inc team to help where I can. :)

It seems a bit off-topic, but I think you can submit pull requests to https://github.com/steemit/steemit.com repository (no permission is needed to do so, and your work will be reviewd by other members). Of course that's not the case if your work is not based on current code base, then perhaps you need to ask someone to fork your code to a new repository.

[noisy]

question about:

#define STEEMIT_HARDFORK_0_16_TIME  1480435200 // Tue, 29 Nov 2016 16:00:00 UTC (11:00:00 EST)

from: 5f4ef76#diff-4d554cc42c9d314c7f50d421cbd293a8R5 by @mvandeberg

vs.

I have tentatively set the hardfork date to Tuesday November 16th

from Steem Economic Changes Update by @bytemaster

What is final date for this hardfork?

[faddat]

Other than you know, totally exploding what we have, doesn't this really sound like it is better suited for another chain?

All economic events that occurred based on the initial assumptions go entirely wonky when viewed in this light.

[mvandeberg]

What is final date for this hardfork?

Not the 16th ;) (Which is also not a Tuesday)

The hardfork will be when it's done. The proposed changes are huge and the correct parameterization is nuanced.

[thecryptofiend]

The hardfork will be when it's done. The proposed changes are huge and the correct parameterization is nuanced.

Makes sense:)

[Elevexx]

So the hardfork will not be on the 16th?

[mvandeberg]

The 16th is tomorrow and we have not made a release for 0.16.0. It is safe to say the hardfork will not be on the 16th. We will have a release out at least one week prior to the hardfork date.

[dragosroua]

Keep up the good work, guys, sending good vibes. Looking forward to steem after the 16th hard-fork.

[arhag]

@mvandeberg: I'm happy with the new changes. But I should mention a small issue that remains with the code as written, even if you guys think it is a low probability enough corner case to not bother coding a solution for.

If the miner queue becomes empty (either because no one is mining or maybe because of a future hardfork that for some reason decides to disable the pow2 operation), the 21st slot in the round will be given to a second timeshare witness. The way the current code is written, that would mean the blockchain would print 29/25 * 21 * witness_reward STEEM per round rather than the target amount of 21 * witness_reward.

If you do think it is worth solving this issue with the least amount of code changes, then you would need to add an integer field num_miners_in_round to the dynamic global properties which tracks the number of miners scheduled for the round and replace these lines with:

      auto top19_witness_weight = 1;
      auto timeshare_witness_weight = 5;
      auto miner_witness_weight = 1;

      auto normalization_factor = top19_witness_weight * STEEMIT_MAX_VOTED_WITNESSES + miner_witness_weight * props.num_miners_in_round 
                                   + timeshare_witness_weight * (STEEMIT_MAX_WITNESSES - STEEMIT_MAX_VOTED_WITNESSES - props.num_miners_in_round);
      if( cwit.schedule == witness_object::timeshare )
         witness_reward = ( timeshare_witness_weight * witness_reward * STEEMIT_MAX_WITNESSES ) / normalization_factor;
      else if( cwit.schedule == witness_object::miner )
         witness_reward = ( miner_witness_weight * witness_reward * STEEMIT_MAX_WITNESSES ) / normalization_factor;
      else // cwit.schedule == witness_object::top19
         witness_reward = ( top19_witness_weight * witness_reward * STEEMIT_MAX_WITNESSES ) / normalization_factor;

This preserves the ratios of pay rates among the three different categories even with the number of miners scheduled in the round changing. Also, I think it has the benefit of being clearer code and setting it up in a way that makes it easier to possibly modify these ratios in a future hardfork if desired.

Another possible solution to this problem could be keeping the fraction of witness_reward pay going to the top 19 constant and instead rebalancing the weights between timeshare witnesses and miners appropriately, but that is a slightly more complicated implementation.

[clayop]

Can you check this line?

Given the hardfork timestamp 1480435200, the block number will be approximately 7,152,400, which is greater than 7,000,000. You meant 8,000,000 or am I misunderstanding?

[mvandeberg]

Given the hardfork timestamp 1480435200, the block number will be approximately 7,152,400, which is greater than 7,000,000. You meant 8,000,000 or am I misunderstanding?

The current implementation has a narrowing of 0.01% every 250,000 blocks. To make the implementation as easy as possible, we calculate what the APR would have needed to be at block 1 to achieve 9.5% at block 7,000,000. The hardfork being not quite at 7,000,000 is not a huge deal. If it gets delayed further, we can bump up the starting percent by 0.01.

[clayop]

I now understand it. Thanks.

[bytemaster]

[bytemaster]

[theoreticalbts]

I think typo in first graph (should this be "new liquid steem")?

[theoreticalbts]

Found two issues with this calculation.

• Subtraction overflow is not handled (if we get a negative number it will wrap, uint rules.)
• Inflation "clicks" downward once every 250k blocks, ~20 satoshis at current supply level. Cleaner to have much smaller more frequent "clicks" in the sub-satoshi range.

[theoreticalbts]

Some other issues:

• This should be witness_pay_normalization_factor not STEEMIT_MAX_WITNESSES. Edit: Not a bug, see subsequent comment.
• Trimming the window needs to use while not if...oops, actually not a bug, handled with one-time HF processing here.
• Unnecessary cast makes code more confusing

[theoreticalbts]

Current block's witness pay times STEEMIT_MAX_WITNESSES gives you a pool of total witness pay per round (assuming no adjustments to per-block witness pay). The share of this pool each witness is entitled to is its weight over the sum of all witness' weights, so the correct calculation really is

witness_reward * STEEMIT_MAX_WITNESSES * witness_weight / sum_of_witness_weights

Some notes:

• First two terms of above expression are the above-mentioned pool
• In the code, sum_of_witness_weights is actually called witness_pay_normalization_factor

[mvandeberg]

This was implemented in hardfork 16.