Author Topic: [New BSIP Discussion] Defer MCR update to next maintenance interval  (Read 4286 times)

0 Members and 1 Guest are viewing this topic.

Offline Bangzi

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Steemit: Bangzi
  • BitShares: bangzi
If changes of MCR is not frequent, I believe we can change MCR even before the protocol upgrade on Dec 2018. What we can do is announce to the community the date/time when MCR will change, then they can update their position for new call price.
Bitshares DEX - Over 1000 Coins, Buy, Sell, Transfer & List Any Coins |Free Signup Today: https://wallet.bitshares.org/?r=bangzi

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
At present I tend to adopt option 1 as well. By moving the caching to median price feed, perhaps performance can be even better. It's still a hard fork change anyway.
BitShares committee member: abit
BitShares witness: in.abit

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
I feel 3.2 is acceptable in UX.

however sounds option 1 is an even better solution, but I am not sure whether it add extra complexity or uncertainty, seems need to do more evaluation to ensure the safety.
Email:bitcrab@qq.com

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I'm for option 1.

The call_price caching is a nice example of Knuth's "Premature Optimization" rule. Removing the cache would simplify the code without changing chain behaviour, whereas deferring MCR changes would make it more complicated *and* reduce chain responsiveness. Also I don't think the impact on performance in order matching would be significant.
How much work would it be to implement this and see how much *extra complexity* it adds?

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
I'm for option 1.

The call_price caching is a nice example of Knuth's "Premature Optimization" rule. Removing the cache would simplify the code without changing chain behaviour, whereas deferring MCR changes would make it more complicated *and* reduce chain responsiveness. Also I don't think the impact on performance in order matching would be significant.
« Last Edit: May 25, 2018, 06:23:57 pm by pc »
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1902
    • View Profile
  • BitShares: ebit
support
by the way ,the shorter have the freedom to choice settlement time  .if he has the second collateral ,such as gdex.btc . then,we have no reason to buy bitcny for adjusting.
the second collateral is an open idea .
« Last Edit: May 25, 2018, 10:45:39 am by ebit »
telegram:ebit521
https://weibo.com/ebiter

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I prefer 3.2 as well.
Consistency is key on the blockchain.
Scalability is key as well.

The fact that the economics slight change (read are delayed) in case the MCR changes, isn't too much of a problem
and rather gives people a chance to update their orders in time BEFORE it becomes active.

So, I am all for 3.2

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
MCR=maintenance collateral ratio?
MCR= median collateral ratio?
It's actually median of "maintenance collateral ratio" fed by feed producers, I I abbr'ed it to "median collateral ratio". OP updated.
« Last Edit: May 25, 2018, 07:39:25 am by abit »
BitShares committee member: abit
BitShares witness: in.abit

Offline Bangzi

  • Sr. Member
  • ****
  • Posts: 321
    • View Profile
    • Steemit: Bangzi
  • BitShares: bangzi
3.2 Approach: Does witness have enough time for issue #504 + Defer MCR Update?

If Yes, I would say just go ahead.

If No, is it possible to set Defer MCR update at different time eg. every hour 35 minutes?
Bitshares DEX - Over 1000 Coins, Buy, Sell, Transfer & List Any Coins |Free Signup Today: https://wallet.bitshares.org/?r=bangzi

Offline binggo

  • Hero Member
  • *****
  • Posts: 2374
  • 世间太多瘪犊子
    • View Profile
MCR=maintenance collateral ratio?
MCR= median collateral ratio?

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
BitAssets' MCR (maintenance collateral ratio) is calculated from price feeds (actually it's the median of feeds), it can change when feed changes, although rarely changes (according to current use cases in production aka BitShares mainnet, but perhaps there are potential new use cases which need to change it frequently).

MCR affects all margin positions. When MCR increased, more short positions will be put into margin call territory; when MCR decreased, more short positions will be pull out of margin call territory.

So, ideally, when MCR changed, all short positions should be reevaluated.

Since the quantity of short positions can be very large, for better performance, a caching mechanism is used in current system, aka "call price". When a short position is created, we calculate its call price with current MCR; when its collateral and/or debt got updated, we update its call price according to current MCR. When median feed price reached call price, the short position is put into margin call territory; when feed price changed backwards, the short position is pull out of margin call territory.

However, in current system, we don't refresh the "call price" cache when MCR changed, that said, existing short positions' call prices can be inconsistent with latest MCR. In the meanwhile, call prices of new positions or updated positions will be always up-to-date as long as MCR didn't change. This may lead to unintended margin calls when MCR decreased, or unintended inability to call when MCR increased.

By the way, BSIP31 partially solved the cache refreshing issue: before BSIP31, when a short position is partially called or settled, its call price won't be updated; after BSIP31, it will. https://github.com/bitshares/bsips/blob/master/bsip-0031.md

Another related feature is BSIP38, using "target_collateral_ratio" option will effectively avoid unintended margin calls, somewhat of double insurance. However, if a borrower is not using "target_collateral_ratio" option, her position can be called unintendedly after MCR decreased. https://github.com/bitshares/bsips/blob/master/bsip-0038.md

Now come back to the MCR topic.

To solve the cache inconsistency issue, we have options:

1. totally drop the caching mechanism, calculate call prices on the fly (may impact order matching performance)

2. update "call price" cache immediately when MCR changed (may impact performance since possibly need to update lots of data at a time)

3. update "call price" cache at maintenance interval since maintenance interval is meant to be used to process mass calculation

With the 3rd approach,

3.1 if we don't change MCR update behavior, aka update "current effective" MCR directly when feed changed, then the call price cache will be still inconsistent before maintenance interval;

3.2 we can defer MCR update to maintenance interval, that said, when detected a MCR change due to feed change or asset option e.g. feed lifetime change, don't apply the MCR update immediately, but apply it in next maintenance interval. With this approach, the call price data will be always consistent to "current effective" MCR.
  * pros: data consistency
  * cons: probably poorer user experience (UX), since users (usually asset issuers and feed producers) need to wait when wanted to update MCR.


Summary:
I recommend the 3.2 approach: defer MCR update to maintenance interval, update call price cache every time after MCR updated.
Update: at present I tend to adopt option 1. Actually, we can also try to move the caching to median price feed.

Thoughts?
« Last Edit: August 21, 2018, 03:30:01 pm by abit »
BitShares committee member: abit
BitShares witness: in.abit