search

steemit / steem

The blockchain for Smart Media Tokens (SMTs) and decentralized applications.
https://steem.com
Other
1.95k stars 792 forks source link

Price Feed problem #3176

Open ayogom opened 5 years ago

ayogom commented 5 years ago

The STEEM price is wrong now. I think the API is a problem,

TimCliff commented 5 years ago

@ayogom - any more details about what you are seeing?

There is also a related issue: https://github.com/steemit/steem-js/issues/418

mvandeberg commented 5 years ago

curl -d '{"jsonrpc":"2.0", "method":"condenser_api.get_current_median_history_price", "params":[], "id":1}' https://api.steemit.com responds with:

{"id":1,"jsonrpc":"2.0","result":{"base":"122311325.826 SBD","quote":"283920832.196 STEEM"}}

The value is correct, but the representation is not normal. The price feed is a median of medians. Every round, the median of the price's from the scheduled witnesses is calculated. Then, the oldest price from the feed is popped and the new price is pushed. Lastly, the median of the medians is saved as the current price.

This value isn't wrong, but it is unconventional. We could make the price feed should conform to the same "price tick" rules that limit orders will when SMTs are released. This will ensure some amount of precision, while avoiding strange price representations.

LKNX commented 5 years ago

This value isn't wrong, but it is unconventional. We could make the price feed should conform to the same "price tick"

Instead of tricking the price, how about showing the price of STEEM and SBD with up to 8 digits against Bitcoin like normal cryptos? Why do we display in dollars with 3 digits?

@mvandeberg with all due respect, this feels like Kangaroo-Coding. Can we please UP the PERFECTIONISM in this? It is painful that we cannot even display a right dollar-value which also could/should be displayed with 8 digits like Monero, Ethereum, Bitcoin and the other cryptos are displayed in.

The value is correct, but the representation is not normal. The price feed is a median of medians.

Ehh, The Price feed is a median of medians... and is not displayed correct. We know the value is correct @mvandeberg - we got to be more hardcore accurate than that and prove the value to be correct by displaying it correct!

No more price-display tricks please, even if it makes for some what of a "happy thanksgiving" for the multitudes using the front ends affected.

Thank you, and happy thanksgiving!

mvandeberg commented 5 years ago

Instead of tricking the price, how about showing the price of STEEM and SBD with up to 8 digits against Bitcoin like normal cryptos?

There is a big difference between the blockchain price representation and display price. There are 3 ways we could represent prices on the blockchain.

  1. Floating point numbers. Floating point calculations have small error that can differ system to system. This means they are wrong for any financial system. More-so for a decentralized consensus based financial system. The likely result of floating point prices would be a post that I see gets rewarded 1000.000 STEEM and you see a reward of 1000.001 STEEM. Not good, so that is out.

  2. Fixed point numbers. Fixed point solve the inaccuracies of floating point by fixing the radix and using integer math for the actual calculations. An 8 point fixed point value would have an implicit denominator of 256. The problem here is that not all finite length decimal numbers have a finite length binary representation. (0.1 in binary is 0.00110011...). No matter how much precision we add by increasing the radix, some common decimal values cannot be accurately represented.

  3. Store prices as ratios. The fundamental problem with the fixed point representation is the lack of display accuracy. By storing prices as ratios, it becomes the responsibility of the UI to display a reasonable representation of the price. In this scenario, there was a problem in a common library that led to an incorrect display price. The tick pricing rule solves a similar problem for limit orders. Given a ratio price, it is possible to create two prices that have the same display price for some algorithm, but not match in the representation. This can lead to orders seemingly not being matched and orders being sniped by other users. The tick pricing rule reduces the valid set of ratio prices to the subset of those that have a "reasonable" decimal representation. In fact, Bittrex and other exchanges have similar rules regarding the rationalization of their market orders.

steemit/steem-js#418 fixes the display problem, but I am going to leave this issue open to discuss the potential rationalization of the price feed.

TimCliff commented 5 years ago

It is outside the scope of the potential rationalization discussion, but there are a few other items to consider while we are on the topic of the price feed representation, specifically with regards to the 10% "haircut" rule.

When the haircut rule is in effect, the price feed that is returned by the API as well as used for all of the internal calculations is no longer a representation of the "actual" price. This has a few unintended consequences:

Also, since the haircut rule is only applied once an hour (when the median price feed is updated), if there is a large change in the STEEM or SBD supply between the hourly updates (such as the completion of a large SBD->STEEM conversion), then there will be a predictable difference between doing a new conversion before or after the next hourly update. This means converters would be able to put themselves at an economic advantage by timing their conversions based on other large conversions that are being started.

I don't know if any of these things are worth the time to fix, but they seem relevant to consider.

ajayyy commented 5 years ago

SBD from posts cannot end at 10%, it must end earlier or else SBD will continue to be printed FOREVER. SBD printing must revert back to the previous schedule.

TimCliff commented 5 years ago

It is not necessary to revert back to the previous schedule. The 1% printing is definitely not correct, but it is also unlikely going to have any significant economic impact. There are lots of potential ways to address it which don’t involve going back to the previous print rates.

ajayyy commented 5 years ago

The SBD percentage of debt is unstable, a 1 percent buffer between 100% SBD and 100% steem is unfeasable. There are many other better ways of preventing SBD from getting pumped to 15$ then this method.

TimCliff commented 5 years ago

If you are concerned about the fact that we passed the “10% haircut rule” point, the print rate is really not the issue. We passed the 10% point because of a significant drop in STEEM price, which still would have put us over the limit even if the printing stopped earlier.

iamsmooth commented 5 years ago

To put some numbers on the last couple of comments, full rate SBD printing is currently about 2% of market cap per year. That's less than 0.2% per month. This is really tiny and hardly matters at all. Any changes to the debt ratio that happen faster than that are based on the more important factors of the STEEM price changing and/or conversions, not printing.

Transisto commented 5 years ago

Is the plan to wait for the price to maybe recover?

iamsmooth commented 5 years ago

As an extension of this issue, the recorded past payout (reported in estimated dollars) are now incorrect, because they use the adjusted-to-10% feed value. There isn't really any way for UIs to adjust for that. (Some UIs have been rolling out work-arounds in other cases but this one is harder.)

IMO the core code should maintain both an adjusted and unadjusted feed (assuming the debt ratio cap mechanism isn't reimplemented in a different way). The adjusted feed should only be used for SBD conversions with the unadjusted feed used for the various reporting purposes.

nnnarvaez commented 5 years ago

I ended here looking for a different thing but i have question that is been bugging me for a while now.

How come the haircut_price ended being a hardcoded ? Some have pointed me out to the 2017 white paper, page 11 however that is clearly an example and not an affirmation.

I think both the STOP SBD print and haircut_price percentage would be better as witness defined values as a dynamic tool to help control the value (not the price) via consensus.

mvandeberg commented 4 years ago

As a solution to the reported problem, we should require the price feed to also follow tick pricing rules used for market orders come SMTs. (#1573)

iamsmooth commented 4 years ago

@mvandeberg There is some misunderstanding in the 'reported issue' here.

The price feed is a median of medians. Every round, the median of the price's from the scheduled witnesses is calculated. Then, the oldest price from the feed is popped and the new price is pushed. Lastly, the median of the medians is saved as the current price.

In fact the issue here was never prices are reported by witnesses. The 'odd' feed value comes about when the blockchain code disregards witness feed values and imposes its own in order to implement the 10% 'debt cap'.

I do not believe it is a good idea to impose the tick pricing rules on the feed inputs from witnesses. By convention, witnesses currently use the base to report the STEEM price and the quote to report any intentional bias for peg maintenance purposes. Imposing the tick pricing rules would restrict this or other interesting uses which are arrived at by informal consensus.

Furthermore, UIs can display the feed however they like.

Therefore, I believe this issue should simply be closed as not a bug.

There might be a question whether distorting the reported feed on the STEEM price to something it is not is actually the best way to implement the debt cap (as opposed to the more obvious approach of adjusting payouts on conversions), but that would be a different issue if considered to be one.