You are viewing a single comment's thread from:

RE: More about Steem's inflation models

in #programminglast year (edited)

Yeah, I definitely think the SBDs in the SPS are part of inflation. They reduced the author & curator rewards from 75% to 65% at HF21/22 in order to give it to the SPS - which is why we see the cliff on August 29, 2019 for the HF16 graph, above. I tried to include that in the model, too. (But now I am thinking that they also switched curator rewards from 25% to 50% at that hardfork, and I didn't model that.... so I probably need to update it yet again. Ugh. No time ATM.)

Anyway, it's still a black box for me as to exactly how/when the various reward components get created out of the "new STEEM" (SBD, VESTS, and liquid STEEM), but fortunately I didn't need to dig that deep for this check. Another question I'm still not clear on is where the tokens would come from if the witnesses would decide to start paying interest on SBD savings.

And the ratio of the conversion again is equal to the median_price.

That's how I understand it too - the blockchain's median (currently 0.252), not the true median.

Probably a good idea to calculate in Integers. That "round" was just a kludge because Python didn't like working with small numbers.

Update: It went faster than I thought. Updated the HF16 graph with pre-HF21 settings.

Sort:  

Ugh. No time ATM.)

It's like me :-)
There are still so many questions which should be checked, but... you know :-)

it's still a black box for me as to exactly how/when the various reward components get created out of the "new STEEM" (SBD, VESTS, and liquid STEEM)

This is one of these questions :-)
I wrote my calculation similar to the blockchain calculations. On that occasion, I noticed the conversions accordingly. However, I did not go into any further detail. Especially the VESTS conversion was not very intuitive.

where the tokens would come from if the witnesses would decide to start paying interest on SBD savings.

I have deliberately not yet dealt with this topic. But it is also a good question...

That "round" was just a kludge because Python didn't like working with small numbers.

Floating point numbers in binary representation are (almost) always only an approximation. Every language deals with them differently. Unlike C, C++ or Java, Python generally uses 64 bits for the floats. In an approximation, this can result in a few decimal places. Especially when checking for equality, you have to take this into account.
In Python, the use of the decimal module is supposed to handle it better. But I haven't really used it yet either.

Thanks for the update :-)

TEAM MILLIONAIRE

Congratulations, your comment has been successfully curated by @o1eh at 10%.

Coin Marketplace

STEEM 0.20
TRX 0.25
JST 0.039
BTC 97542.75
ETH 3458.83
USDT 1.00
SBD 3.15