Project Information
- Repository: https://github.com/steemit/steem
- Project Name: Steem
https://github.com/steemit/steem/issues/3184
Expected behavior
- SBD print rate should be 0% now.
I believe this bug itself must be well-known now, so this is mainly for explanation in detail, and more importantly, some suggestions. This is a very important issue, so it shouldn't be fixed by a temporary measure.
While I'm not sure this is intended or not, get_feed_history() shows current_median_history as the value already discounted by the so-called haircut. I think this is highly confusing and where all the mess begins. You shouldn't do that way.
Suggestions
Use non-haircut value for
current_median_historyfor consistency- All other real history values are non-haircut values, as you can see on https://api.steemjs.com/get_feed_history. This inconsistency can create lots of confusions, e.g., recent asset value error (steemit.com) / voting value error (busy.org which they still have)
- Witnesses still need to report non-haircut prices, which again is very inconsistent and confusing. (https://steemd.com/witnesses)
Introduce a new variable such as
"haircut discount"and show the value on steemd andget_feed_historyas well.- For instance, https://api.steemjs.com/get_feed_history should show "base": "0.328 SBD", "quote": "1.000 STEEM", "haircut": "0.796"
- This makes the code much more readable and much less prone to bugs such as the current one.
In reality, it might be already late to change the behavior of current_median_history in the code. Then introduce a new variable. In any case, UI (e.g., steemd.com) should show non-haircut value for the current feed price with haircut discount separately.
Actual behavior
SBD print rate is still 1%.
This bug is due to separate and inconsistent calculations for current_median_history and sbd_print_rate.
The sbd_print_rate is calculated here
https://github.com/steemit/steem/blob/7ebe3f8bddf9e58c943618f55136db6330dd95a0/libraries/chain/database.cpp#L3761-L3783
The first problem is current_median_history is already haircut (which I don't recommend doing so in Expected bahavior), so percent_sbd can never surpass 10%.
The second problem is due to the inflation between the time when current_median_history is calculated and the time when update_virtual_supply() (which updates sbd_print_rate) is called, percent_sbd is always strictly less than 10% just a bit.
I explain this in more detail below.
High-level
update_median_feed();
update_virtual_supply();clear_null_account_balance();
process_funds();
process_conversions();
process_comment_cashout();
process_vesting_withdrawals();
process_savings_withdraws();
process_subsidized_accounts();
pay_liquidity_reward();
update_virtual_supply();
As you can see in the above, update_virtual_supply() (which updates sbd_print_rate) is called twice.
The problem is update_median_feed() limit the current_median_history so that sbd_print_rate at most 10% already.
price min_price( asset( 9 * gpo.current_sbd_supply.amount, SBD_SYMBOL ), gpo.current_supply );
if( min_price > fho.current_median_history )
fho.current_median_history = min_price;
Unless you're very lucky due to floating point precision error, sbd_print_rate is already strictly less than 10% in the first call of update_virtual_supply().
But even if you were very lucky, now process_funds() inflates the supply.
(While there are other functions that change virtual_supply or current_sbd_supply, they don't change them in the direction of the sbd_print_rate increase. So let me skip too much details here.)
Thus, in the second update_virtual_supply(), sbd_print_rate is always strictly less than 10% regardless of your luck :)
How to reproduce
Don't need to explain, since it's always happening now.
Recording Of The Bug
steemd.com