Author Topic: Minimal required changes to revive an MPA after a black swan event?  (Read 12704 times)

0 Members and 1 Guest are viewing this topic.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Thanks @pc for all the work done on this.
I am still trying to understand all the complexity that will be brought by the planed change. I think I will vote the worker only when I am sure enough that the planed change is safe to the ecosystem.

Thanks - but please note that the current worker proposal is not for the mechanism discussed in this thread but for BSIP-0018 instead.

Edit: https://bitsharestalk.org/index.php/topic,24322.0.html
« Last Edit: July 13, 2017, 04:37:54 pm by pc »
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
Thanks @pc for all the work done on this.
I am still trying to understand all the complexity that will be brought by the planed change. I think I will vote the worker only when I am sure enough that the planed change is safe to the ecosystem.

Email:bitcrab@qq.com

Offline R

  • Hero Member
  • *****
  • Posts: 1004
    • View Profile
*bump* Has anyone been working on this? All MPA are vulnerable to this problem.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
I have created a PR with some changes and also updated my earlier post: https://github.com/bitshares/bsips/pull/19 https://bitsharestalk.org/index.php/topic,23334.msg299973.html#msg299973

Important changes:

1. I propose another way to handle dependent MPAs, i. e. instead of modifying DUCK to be backed by BACK I propose to apply the "revival" also to DUCK. This is recursive.

2. I also propose to apply global settlement on DUCK at the time when SWAN sees global settlement.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
I was trying to answer your previous question:

Quote
Does it make sense to keep those USD used as collateral for child MPAs and
socializse the costs to all shorters proportianally?
Then, I agree :D

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
I was trying to answer your previous question:

Quote
Does it make sense to keep those USD used as collateral for child MPAs and
socializse the costs to all shorters proportianally?

Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
It would be preferrable to force-settle DUCK, as suggested in the comment in the source code (see Discussion). But that only works for MPAs, not for PMs because PMs don't have a "current price" (aka price feed). Maybe use different methods to handle DUCK_MPA and DUCK_PM? I'll have to think about this.

Socializing the cost is out of the question IMO.
By "socializing the cost", do you mean settling PMs at 0.5?

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Quote
In that regard, the "override_transfer" permission, which usually
regulates forced transfers of a bitasset by the issuer, can be ignored
for the purpose of reviving an asset.
I don't fully understand what this paragraph is good for. If you create a new
operation, we don't need to touch old operations and modify their behavior.

This is just a clarification of an issue brought up by cm-steem on steemit. Normally, the override_transfer permission is required to transfer SWAN from someone else's account. We want to be able to revive assets that don't have that permission.


Quote
* The global settlement event has happened at least 28 days ago.
  This parameter requires further discussion, see below.

I think this requirement only makes sense for PMs, and not for bitassets.
Why would we need to wait to revive bitUSD after a black swan? I can see reasons
to wait for PMs though. On the other hand, I can understand the need to inform
people (and exchanges) about what has happend and how to deal with the
situation.

IMO a black swan is an exceptional situation that should be carefully analysed, and possible countermeasures should be considered before putting the MPA into action again.

But I see that the proposed four weeks may be too long.


Quote
### force_settlement_object

Resolution: cancel them all at the time of the black swan. This is a softfork.
This makes them similar to any other short position with one difference: The
owners already told the chain they wanted to convert to the underlying asset. So
why cancel them and not execute them at the settlement price right away. That's
what the owners asked for either way and the price is the one they would get at
the expiration one or the other way. Is it too costly to let them actually
settle?

Good suggestion.


Quote
### call_order_object
[...]
Resolution: Modify DUCK to be backed by BACK instead of SWAN. Modify all DUCK
calls accordingly. Remove price feeds from DUCK.
I like this solution. It's easy to understand, makes sense. But endusers may not
like it at all. Suppose we had an asset bitGOLD_USD that is GOLD backed by USD.
When USD black swans, people holding bitGOLD_USD still have their value but it
is now backed by BTS not USD (which is not much of a difference), BUT, they will
not be able to use their USD to borrow bitGOLD_USD any longer.

Does it make sense to keep those USD used as collateral for child MPAs and
socializse the costs to all shorters proportianally? If 5% of all black swaned
assets are in collateral for DUCK, then shorters of SWAN can only settle 95% of
their call position. To settle all of thei call position, they would need to get
SWAN out of the collateral of the other asset and close their position as usual.
Just some food for thoughts ..

Well, this is really the weakest part of the proposal. Its simplicity is its only good aspect, IMO. And abit found a potential issue with white/blacklisting, which needs investigation.

It would be preferrable to force-settle DUCK, as suggested in the comment in the source code (see Discussion). But that only works for MPAs, not for PMs because PMs don't have a "current price" (aka price feed). Maybe use different methods to handle DUCK_MPA and DUCK_PM? I'll have to think about this.

Socializing the cost is out of the question IMO.

Besides that. I fully support your efforts!!
https://github.com/bitshares/bsips/blob/master/bsip-0017.md

Thanks!
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Quote
Any acceptable financial damage must be in the range of rounding errors that are
to be expected when dealing with the assets in question.
Had to think about this one but I think you are correct in assuming that there
will be rounding errors.

Quote
In that regard, the "override_transfer" permission, which usually
regulates forced transfers of a bitasset by the issuer, can be ignored
for the purpose of reviving an asset.
I don't fully understand what this paragraph is good for. If you create a new
operation, we don't need to touch old operations and modify their behavior.

Quote
* The global settlement event has happened at least 28 days ago.
  This parameter requires further discussion, see below.

## minimum_time_before_asset_revival

A quick cycle of global settlement and revival is likely to cause confusion
among an asset's users (holders and shorters). There is even limited potential
to abuse this feature. Therefore it is reasonable to enforce a minimum time
before revival, allowing users to get informed about the asset's situation and
the resolution process that affects them.
I think this requirement only makes sense for PMs, and not for bitassets.
Why would we need to wait to revive bitUSD after a black swan? I can see reasons
to wait for PMs though. On the other hand, I can understand the need to inform
people (and exchanges) about what has happend and how to deal with the
situation.

Quote
### force_settlement_object
Forced settlements have an expiry date. After that date, they are cancelled if
the underlying asset has a settlement_price. For SWAN this is the case, so these
are resolved automatically after some time. Because "some time" can be quite
long though, it is better to resolve this in a quicker way.

Resolution: cancel them all at the time of the black swan. This is a softfork.
This makes them similar to any other short position with one difference: The
owners already told the chain they wanted to convert to the underlying asset. So
why cancel them and not execute them at the settlement price right away. That's
what the owners asked for either way and the price is the one they would get at
the expiration one or the other way. Is it too costly to let them actually
settle?

Quote
### call_order_object
[...]
Resolution: Modify DUCK to be backed by BACK instead of SWAN. Modify all DUCK
calls accordingly. Remove price feeds from DUCK.
I like this solution. It's easy to understand, makes sense. But endusers may not
like it at all. Suppose we had an asset bitGOLD_USD that is GOLD backed by USD.
When USD black swans, people holding bitGOLD_USD still have their value but it
is now backed by BTS not USD (which is not much of a difference), BUT, they will
not be able to use their USD to borrow bitGOLD_USD any longer.

Does it make sense to keep those USD used as collateral for child MPAs and
socializse the costs to all shorters proportianally? If 5% of all black swaned
assets are in collateral for DUCK, then shorters of SWAN can only settle 95% of
their call position. To settle all of thei call position, they would need to get
SWAN out of the collateral of the other asset and close their position as usual.
Just some food for thoughts ..

-------
Besides that. I fully support your efforts!!
https://github.com/bitshares/bsips/blob/master/bsip-0017.md
« Last Edit: October 31, 2016, 08:13:51 am by xeroc »

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Renaming a settled asset would be much simpler to implement than the BSIP, that is true. But it's not a good idea, IMO. It's more like a hack, not a real solution.
* It clutters up the asset namespace, which will lead to confusion.
* It will also clutter up wallets with dust amounts from settled assets, which is a nuisance.
* It will turn users away from assets that have seen a black swan before - who would buy GRC when there's also GRC_SWAN_1, GRC_SWAN_2 and so on? :-)
* 3rd party software (like external exchanges) may run into problems if the mapping asset name <-> asset id is no longer static.
* It won't help assets backed by SWAN.

Sounds good to me, I was mostly trying to think of a way to save some work.  I think it would be great if you got a worker approved to take this on!  My opinion is it's important to keep sharp developers like you taking an active interest in the platform and community, so hopefully it would get approved quick.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Comments from @abit on github:
Quote
Some concerns:

* Holders of DUCK are perhaps not in the white list of BACK (but perhaps it doesn't matter).
* Currently, new chain parameter can only be added in extensions. Perhaps better implement cryptonomex/graphene#554 first?

Excellent points, thanks!

I'm far from happy with the proposed resolution of dependent assets. The proposal as-is might serve as a way to circumvent whitelisting on BACK. This is not acceptable of course.

It would be possible to leave out the new chain parameter from this proposal, for now, if we find consensus on a reasonable default value. This can be turned into a modifiable parameter after #554 has been implemented.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
This has grown beyond "minimal". I will probably set up a worker, if nobody else volunteers to implement this. But I appreciate your offer, and testing will be very much needed in any case.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline wackou

Awesome work pc, very much appreciated! Thanks for pushing this. I don't feel qualified to comment on all the details of your proposal, but I'll be helping testing as soon as you get something working. And if you don't set up a worker for this, I'd be very much willing to chip in a few BTS to compensate for your work. I feel like that this issue right now is the most pressing one affecting BTS, glad to see someone taking the lead on this.  +5%
Please vote for witness wackou! More info at http://digitalgaia.io

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Thanks PC for work on this issue, the Gridcoin community greatly appreciates what you're doing!

Thanks for your support!
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de