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

0 Members and 1 Guest are viewing this topic.

Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Motivation

Market-pegged assets, aka MPA, aka SmartCoins, can suffer a "black swan" event. A black swan occurs when the least collateralized short position has insufficient collateral to buy back the borrowed SmartCoins at the current feed price. What happens then is that the MPA is tagged with a "settlement price", defined as the collateral ratio of the least collateralized short. All short positions are closed automatically, by collecting sufficient collateral into a settlement pool and paying out the remainder to the short's owners. MPA holders can use the forced settlement operation to receive their share from the settlement pool in exchange for their MPAs.

MPAs that have suffered a black swan are effectively dead. They can still be transferred or traded, but they can no longer be shorted. Eventually, all significant holders wlll have settled their positions, and some dust will remain scattered all over the place, where the value of the dust position is lower than the fees required to get rid of it.

The same is true for Prediction Markets. Prediction Markets don't suffer black swans, but at some point the prediction will be resolved in the same way that an MPA resolves a black swan - i. e. a settlement price is defined, short positions are closed, and holders can settle their positions individually. After that, the Prediction Market is effectively dead.

The most recent example of a black swan is GRIDCOIN, and I think it has left a bad impression on its issuer, and serves as a bad example for possible future candidates:

That's unfortunate & quite a short lived experiment in BitShares by the Gridcoin community then. [...] I hope black swan handling/recovery functionality is added into BitShares in the future, time to look into other DEXs.

I also believe that the one-shot property is one of the major reasons why prediction markets haven't gained traction yet.

Goal

I'd like to find a minimally invasive way to revive assets after a global settlement or black swan event. Since we currently don't have a designated dev team, this will have to be done as a community effort. Community support is also required because we need to implement and accept a hardfork for this.

I'm looking for a "minimally invasive" solution because
* I want to avoid breaking things, obviously.
* I hope a small change can be done without the usual hassle with worker proposals. I'd volunteer to implement changes, but I will need help testing.

Starting point

Reviving MPAs / PMs consists of two basic steps, IMO:

1. Resolve all open positions
2. Reset the asset object in the database to a usable state

I believe the second step is safe to do after the first has been completed.
* For an MPA, it is sufficient to remove the settlement price. Once it has been removed, price feeds can be published again, and with sufficient price feeds, shorting becomes possible.
* PMs should be reset into a state that requires issuer action to re-enable shorting, possibly by setting some flags at the time the settlement price is removed.
Both can be done within a maintenance interval at little computational cost.

The first step, however, looks much trickier to me. For example, I'm not clear about what are "open positions":
* holders
* market orders (sell *and* buy)
* shorts that use the to-be-revived asset as collateral (?)
* fee pool
* anything else?

For each type of "open position", we need a way to close it. Suggestions:
* Resolve holders by allowing the issuer to invoke forced settlement if the asset has a settlement_price.
* Resolve market orders by allowing the issuer to cancel orders if one of the assets has a settlement_price.
* Ignore the fee pool - it belongs to the issuer anyway.
* For shorts I don't see a solution, but that should be a rare case. I hope.
* Anything else?

By allowing the issuer to take action we avoid overly complex computations. The fees should be paid by the issuer. We might want to offer a reduced settlement fee in that case, since protecting shorters is not necessary at this point.

Comments?

Edit: crossposted on steem: https://steemit.com/bitshares/@cyrano.witness/minimal-required-changes-to-revive-a-bitshares-mpa-after-a-black-swan-event
« Last Edit: September 18, 2016, 10:28:37 am by pc »
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline R

  • Hero Member
  • *****
  • Posts: 757
    • View Profile
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #1 on: September 18, 2016, 11:14:34 am »
Thanks @cyrano.witness, I appreciate the write up - I was going to do a write up on this topic but have been swamped with Gridcoin things recently.

I'm very interested in seeing the current 'black swan' state resolved for the Gridcoin MPA, however this will likely continue occuring due to the volatility of Gridcoin's marketcap.

On a positive note - this is a great learning opportunity for all BTS users; it's not often that black swan events occur, better for it to happen on a new MPA than one of the large ones (fiat/btc).

I'm not going to give up on BTS, i've been holding BTS since BTSX so i'm very much so interested in seeing it succeed.

I've promoted your post, let's hope some Bitshares users join in the conversation! :)

Offline nmywn

  • Sr. Member
  • ****
  • Posts: 266
    • View Profile
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #2 on: September 18, 2016, 12:53:42 pm »
Great lesson, indeed... and very cheap.
I was unable to close my position when market moves my direction, so I set my collateral as low as possible when BTS jumped to 1300 sat.  If we didn't stop there I could be even at profit while margin called. (bolded one).
Anyway, my position is closed,  orderbook is empty -  I had also buy order which I've been canceled by hand after black swan event. I suppose others done the same.
What we've got now is 1,472 BTS in Setllement fund which could be used to cover holders ( some may be at loos, some not - relative to BTS) with 1: 1,47 ratio

I think proper way to resolve  black swan event is:
1 auto-cancel all orders
2.refund holders - they should be aware what is their risk before the trade.
3. Restart market and expect different results ?

Quote
kezzik121 bought 1,000 GRIDCOIN at 1.471823 BTS/GRIDCOIN
kezzik121 bought 1,110.59 BTS at 0.85 GRIDCOIN/BTS
kezzik121 bought 11.76 BTS at 0.8499997 GRIDCOIN/BTS
kezzik121 bought 6 BTS at 0.83333333 GRIDCOIN/BTS
kezzik121 bought 6.5 BTS at 0.76923077 GRIDCOIN/BTS
kezzik121 bought 7 BTS at 0.71428571 GRIDCOIN/BTS
kezzik121 bought 15 BTS at 0.66666667 GRIDCOIN/BTS
kezzik121 bought 16 BTS at 0.625 GRIDCOIN/BTS
kezzik121 bought 20 BTS at 0.50 GRIDCOIN/BTS
kezzik121 bought 1.17 BTS at 0.85655306 GRIDCOIN/BTS


Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #4 on: September 21, 2016, 09:59:27 pm »
however this will likely continue occuring due to the volatility of Gridcoin's marketcap.

That is a valid concern. I think this will have to be managed carefully, probably with very conservative parameters, i. e. a high margin call ratio.

I'm not going to give up on BTS, i've been holding BTS since BTSX so i'm very much so interested in seeing it succeed.

Thanks! :-)

I intend to discuss/mention this matter in episode #194 of the BeyondBitcoin hangout:

Great! I don't know if I'll make it. At the very least I'll be late. :-/

Quote
The Gridcoin MPA does not have the permission "override_authority: Issuer may transfer asset back to himself" as it was surrendered in the pursuit of decentralization.

Good point. However, I'm not suggesting to transfer assets back to the issuer, so I think this flag does not apply here. Also, a black swan is a special situation where the MPA is no longer market-pegged but has a well-defined fixed value wrt the backing asset. Exchanging the MPA for the equivalent amount of collateral does not damage the holder in any form, so ignoring the flag (if it is applicable at all) might be OK.

The first step, however, looks much trickier to me. For example, I'm not clear about what are "open positions":

For each type of "open position", we need a way to close it. Suggestions:

I have read through the code and found two more kinds of open positions:

* vesting balances - should be rare and can be exchanged for equivalent vesting balances of the backing collateral
* blind balances - I don't see a viable solution for these. It might be possible to tag blind balances with an exchange rate and perform the exchange in the transfer_from_blind operation, but this will be close to impossible to get right due to rounding issues (and a UI nightmare, too).

Right now I think blind balances are a blocker. If you want revivable bitassets you'll have to forbid blind transfers.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

iHashFury

  • Guest
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #5 on: October 14, 2016, 03:12:25 pm »
This issue is also being discussed here:

https://github.com/cryptonomex/graphene/issues/664

Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #6 on: October 29, 2016, 09:57:22 am »
So... it took me some time, but I've created a formal BSIP for the topic. It doesn't have an official number yet, I suppose it's going to be #0017. Will create a PR later today.

There are a few points in there that require discussion.

Also, this has become a lot more complex than I initially thought, so this NEEDS a review by community members.

(Crossposted on steem: https://steemit.com/bitshares/@cyrano/bsip-revive-bitassets-after-global-settlement )

---

    BSIP: 0017
    Title: Revive BitAssets after global settlement
    Authors: Peter Conrad <[email protected]>
    Status: Draft
    Type: Protocol
    Created: 2016-10-27
    Discussion: https://bitsharestalk.org/index.php/topic,23334.0.html
                        https://github.com/cryptonomex/graphene/issues/664
    Copyright: Public Domain

# Abstract

BitAssets, i. e. market-pegged assets (MPA) like bitUSD and prediction markets
(PM) in BitShares can suffer a "global settlement" event. After global
settlement, the asset is effectively rendered useless. This BSIP proposes
a protocol change to enable resolving a global settlement so that affected
assets can be "reset" and put to good use again.

# Motivation

Market-pegged assets, aka SmartCoins, and to some extent Prediction Markets are
among the core features of the BitShares blockchain and as such provide one of
our USPs.

MPAs can suffer a "black swan" event. A black swan occurs when the least
collateralized short position has insufficient collateral to buy back the
borrowed SmartCoins at the current feed price. What happens then is that the MPA
is tagged with a "settlement price", defined as the collateral ratio of the
least collateralized short. All short positions are closed automatically, by
collecting sufficient collateral into a settlement pool and paying out the
remainder to the short's owners. MPA holders can use the forced settlement
operation to receive their share from the settlement pool in exchange for their
MPAs. (Actually there's a bug that prevents this currently, but that's the way
it is intended to work.)

A technically quite similar mechanism is used to settle PMs. In a PM, shorters
and holders are betting on the outcome of a specific event. Once the actual
outcome has materialized, the PM is settled by setting a settlement price.

Both MPAs that have suffered a black swan and PMs that have seen settlement are
effectively dead. They can still be transferred or traded, but they can no
longer be shorted. Eventually, all significant holders wlll have settled their
positions, and some dust will remain scattered all over the place, where the
value of the dust position is lower than the fees required to get rid of it.

Allowing MPAs and PMs to be revived after a settlement event will greatly
increase the usefulness of both types of assets. Increased usefulness will
hopefully boost adoption.

# Rationale

After a global settlement, the value of the unit in question is fixed relative
to the underlying asset. This means that any exchange of an amount of the
asset in question for the underlying asset at the settlement price does not
financially damage the previous owner of the exchanged asset.

Reviving bitassets is beneficial for the network as a whole. This justifies
decisions in favour of the network, as long as financial damage to anyone is
avoided. Any acceptable financial damage must be in the range of rounding
errors that are to be expected when dealing with the assets in question.

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.

# Specification

## revive_asset operation

A new operation will be introduced that performs the revival. The fee for this
operation SHOULD be significant, because it is a computationally intensive
operation.

The operation has a single parameter, the asset to be revived.

The operation requires a signature from the asset's issuer authority.

The operation can only be invoked under the following conditions:

* The asset has a settlement_price, either from a black swan or from an
  asset_global_settle operation. Note that this is possible only for MPAs and
  PMs.
* The global settlement event has happened at least 28 days ago.
  This parameter requires further discussion, see below.

To execute the operation, all open positions of the asset to be revived are
looked up and handled as described below.

## Open Positions and How to Handle Them

In the following, SWAN is the asset to be revived. BACK is the asset backing
SWAN.

### 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: cancelexecute them all at the time of the black swan. This is a softfork.

### limit_order_object

Limit orders can either buy or sell SWAN. In the case of a sell, the order holds
some amount of SWAN. Sell orders MUST be cancelled to revive the asset.
Buy orders SHOULD be cancelled, because the price offered may be based on
outdated information.

Resolution: Cancel all orders where either the asset to sell or the asset to
receive equals SWAN. An index on limit_order_object::price::quote::asset_id will
be added to speed up lookups.

### call_order_object

Calls on SWAN are resolved when global settlement happens. So at the time of
revival none of these exist.

However, calls may exist with SWAN as collateral. Suppose that DUCK is an asset
that is backed by SWAN. Calls on DUCK cannot be cancelled.

Resolution 1: Modify DUCK to be backed by BACK instead of SWAN. Modify all DUCK
calls accordingly. Remove price feeds from DUCK.


Resolution 2: Force-settle DUCK. This will free up all SWAN used as collateral
for DUCK, i. e. the SWAN will be returned into account_balance objects and
resolved as described below.

Note that Resolution 2 is only available for MPAs, not for PMs, because PMs
don't have a price feed that can be used to determine the fair value of DUCK vs
SWAN in settlements.

Also note that Resolution 2 is recursive - if an asset SLUG exists that is
backed by SWAN, SLUG will have to be settled as well.


This solution requires further discussion.

### vesting_balance_object

A vesting_balance_object can hold a vesting balance of SWAN for a given account.
Vesting balances can vest with different strategies (linear or coin-days).

Resolution: for every non-zero vesting balance of SWAN, create (if necessary) a
vesting balance for BACK with an equivalent vesting policy and adjust balance
and policy parameters accordingly.
An index on vesting_balance_object::asset::asset_id will be added to speed up
lookups.

### balance_object

Balance objects (not to be confused with account_balance objects) contain
genesis balances, possibly with linear vesting. This should be a rare case in
BitShares-2.0, but it is a possible case and requires resolution.

Resolution: all balances of SWAN are replaced with equivalent balances of BACK.
An index on balance_object::asset_type will be added to speed up lookups.

### blinded_balance_object

Blinded balances are part of the stealth feature of Graphene. A blinded balance
has only an asset id, but no (visible) amount. The only visible thing is the
total of all blinded balances of that asset type, which is a field in the
asset's dynamic data.

Resolution:

1. A part of the settlement_fund will be set aside for settling blinded
   balances. For this, a new object type "blinded_settlement_object" will be
   introduced that carries the blinded_settlement_fund and the remaining total
   blinded amount.
2. The blinded_balance_object will receive an additional optional field that may
   contain a reference to a blinded_settlement_fund. blinded_balances with such
   a reference may only be withdrawn from, together with other blinded_balances
   carrying the same reference, but they cannot be transferred anymore.
   Note: special care needs to be taken in the fee handling here. Using the
   blinded balance together with the SWAN fee pool must be avoided. Instead,
   the BACK fee pool must be used (if at all).
3. Upon withdrawal, the amount withdrawn is immediately converted to BACK, from
   the blinded_settlement_fund. If the amount withdrawn is equal to the total
   remaining blinded amount, the remaining blinded_settlement_fund is paid out
   to the withdrawer and the object is deleted.

Note that the pair (SWAN, blinded_settlement_object) creates a kind of virtual
asset that should not be mixed with "pure" SWAN balances by existing user
interfaces.

An index on blinded_balance_object::asset_id will be added to speed up lookups.

### blinded_settlement_object

This object type does not exist yet. It is introduced by the mechanism to handle
blinded SWAN balances, as described above.

Resolution: blinded_settlement_objects holding SWAN are immediately converted to
BACK.

### account_balance_object

This is what holds the actual balances of an account. Each such object refers to
a specific account and asset. Account_balances of SWAN can be converted into
BACK at any time via the forced settlement feature.

Resolution: account balances of SWAN are converted into BACK immediately.

### asset_bitasset_data_object

This object defines (among other things) if an asset is in global settlement.

Resolution:

* pay out remaining settlement_fund to issuer (if any)
* nullify settlement_price / force_settled_volume
* empty feed list / unset current_feed
* empty options.whitelist_authorities and set white_list in options.flags

The latter requires discussion.

### asset_dynamic_data_object

This object logs the existing amount of SWAN (total and blinded). It also
contains the fee pool.

Resolution: set accumulated_fees to 0 and adjust current_supply accordingly.
The issuer will be compensated for the lost fees by receiving the remainder of
the settlement_fund. After all the previous resolutions have been executed, the
current_supply and the confidential_supply must be 0.

## Additional changes

### Bugfix: MPAs that have seen a black swan cannot be settled after the price feed expires

It has turned out that force-settling an MPA requires a valid price feed even
when the MPA has a settlement_price set. This is clearly a bug, since in that
case the settlement price is independent from the price feed. Furthermore,
publishing price feeds is no longer possible after a black swan, so the time
when settlement is possible at all is limited to the expiration period of the
price feed of the MPA.

This needs to be fixed. See https://github.com/cryptonomex/graphene/issues/664#issuecomment-254056746
for a discussion.

### New chain parameter: minimum_time_before_asset_revival

This parameter defines the minimum required time between a global settlement
event on an asset and the revival of that same asset. The parameter will be
modifiable by the committee and defaults to 4 weeks (28 days). See discussion
below.


### Dependent MPAs

If at the time of global settlement an MPA exists that is backed by the settled
asset, that dependent MPA is also settled.

Additionally, it will be forbidden to create assets backed by bitAssets that
have a settlement_price.

The reason for this is that after global settlement the settled asset is no
longer pegged to its "real" counterpart. For example, suppose that an asset
bitGOLD_USD exists that is supposed to represent the value of an amount of gold
and is backed by an amount of bitUSD (which is supposed to be pegged to the
US-Dollar). After bitUSD has suffered a black swan, bitUSD is no longer pegged
to USD. Instead, bitUSD represents a fixed amount of BTS, defined by the
settlement_price.

Supposedly, the price feed for bitGOLD_USD will continue to follow the gold
price in terms of US-Dollars, which will quickly deviate from the actual worth
of bitGOLD_USD, which is really defined by the BTS price at that time. This will
lead to confusion and anger among market participants. It is therefore
reasonable to put bitGOLD_USD into the same state of limbo as the backing USD.

This change requires further discussion.


# Discussion

## 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.

## Dependent Assets

As described above, assets may exist that use SWAN as collateral. Short
positions in such assets must be resolved somehow. The proposed resolution 1 is
quite harsh, in that it modifies the asset that uses SWAN as collateral.

It is reasonable insofar as SWAN effectively represents the value of a fixed
amount of BACK, which means that an asset backed by SWAN is *actually* backed
by BACK. The proposed resolution only makes that explicit.

There is a related comment in the source code (https://github.com/cryptonomex/graphene/blob/f1b19b15629cd02669a94f2af16eeaec7f54b3f6/libraries/chain/include/graphene/chain/protocol/asset_ops.hpp#L160 ):

> If this asset is used as backing for other bitassets, those bitassets will be
  force settled at their current price.

This is not reflected in the actual implementation AFAICS.

Better suggestions are welcome.

## Flags and permissions

As described above, the revival operation will set the whitelist flag and
permission of the revived asset. The purpose of this is to prevent the asset
from immediately becoming active again, before the issuer has a chance to
modify other asset parameters. For example, after reviving a prediction market,
the owner might want to update the asset description before starting the next
round of predictions.

## Affected Parties

### Exchanges

An exchange holding SWAN will have its SWAN exchanged for BACK just like anyone
else. The exchange will probably have SWAN balances in its internal ledgers,
which belong to the users of the exchange. The exchange MUST be notified of the
settlement and it MUST modify its internal ledger, replacing SWAN balances
with BACK balances.

Exchanges SHOULD perform this operation independently from the revival, i. e.
before the revival is triggered. They can do this by force-settling their SWAN
holdings.

### (Other) Users

Users holding SWAN will have their holdings replaced with an equivalent amount
of BACK, at the settlement_price. This does not damage the holder financially,
see above.

### Asset Owners (aka Issuers)

The issuer of an asset to be revived should know what he is doing. Invoking the
revive_asset operation is a wilful act. If he isn't happy with the effect of the
operation he simply should not invoke it.

Issuers of assets backed by a revived assets are affected too, but they have no
choice. See discussion about Dependent Assets above.

# Summary

This proposal discusses a set of changes to bring back a "stuck" asset into a
usable state.

Not all shareholders need to understand the technical details of the proposal,
however, they should be aware of the implications of these changes. It is
particularly important to understand how the revival of an asset affects the
different parties, i. e. holders, shorters, traders and issuers.


After an asset SWAN backed an asset BACK has seen global settlement, in order to
revive it all existing SWAN must be destroyed and their owners must receive a
share of the available collateral (BACK). In particular,

0. At the time of the black swan, all outstanding settlement requests will be
   filled, and all MPAs backed by SWAN will receive a global settlement as well.
1. At the time of revival, all open market orders concerning SWAN will be
   cancelled (buys and sells).
2. Other MPAs backed by SWAN will be settled as well.
3. Other PMs backed by SWAN will be modified so that they are backed by BACK.
4. Vesting balances, genesis balances and account balances of SWAN will be turned
   into respective balances of BACK.
5. Blinded balances of SWAN will receive special treatment so that they can be
   withdrawn as BACK.
6. The SWAN fee pool will be zeroed out, and the issuer will receive the
   remaining BACK collateral.
7. Finally, SWAN will be put into a state where the issuer can modify parameters
   and eventually open it up for general use again.

---

Edited 2016-11-13, changes are green
« Last Edit: November 13, 2016, 04:36:39 pm by pc »
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline R

  • Hero Member
  • *****
  • Posts: 757
    • View Profile
« Last Edit: October 29, 2016, 05:48:40 pm by crypto123 »

iHashFury

  • Guest
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #8 on: October 29, 2016, 01:46:22 pm »
Awesome work pc! Thanks

Offline Chris4210

  • Sr. Member
  • ****
  • Posts: 431
  • Keep Building!
    • View Profile
    • www.payger.com
  • BitShares: chris4210
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #9 on: October 29, 2016, 05:14:10 pm »
This is the right step forward since we have a couple of MPA that black swanned and are unusable. I would support a community approach to reset all black swanned markets in an HF and also implement better code to restart an MPA in trouble.

When I understand the black swan right then all affected MPA will be automatically converted back to the collateral right? So the Blockchain would pull my BitUSD from my Bitshares account and replace it with 100% BTS in value of the taken BitUSD.
Vote Chris4210 for Committee Member http://bit.ly/1WKC03B! | www.Payger.com - Payments + Messenger | www.BitShareshub.io - Community based fanpage for the BitShares Blockchain

Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #10 on: October 29, 2016, 06:57:38 pm »

When I understand the black swan right then all affected MPA will be automatically converted back to the collateral right? So the Blockchain would pull my BitUSD from my Bitshares account and replace it with 100% BTS in value of the taken BitUSD.

Right now, nothing happens automatically. In your example, BitUSD holders can use forced settlement to exchange their BitUSD for BTS at the settlement price. Or at least they could if it wasn't prevented by a bug.

My proposal would allow the issuer (in the case of BitUSD this is the committee) to enforce this settlement for all types of BitUSD positions.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline Agent86

  • Sr. Member
  • ****
  • Posts: 471
  • BTSX: agent86
    • View Profile
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #11 on: October 29, 2016, 11:06:27 pm »
Hi pc,

I'm impressed with how detail oriented you have been in fleshing out all the impacts of this change!  It seems like it could be a lot of work.  Getting that bug fixed with the feed expiration time preventing people from settling positions seems to be most important. Otherwise the primary goal is to recover the name for re-use right?  Do you think it might be possible/easier to allow the original issuer (after a certain period of time) to create a new asset that would just show up in the user interface under the same previous name?  Whereas prior versions of the asset that have been black swanned /force settled are represented differently to indicate this?

In regard to assets used as backing for other assets (SWAN backing DUCK) I'm not sure this is a very useful feature in the first place and maybe could be eliminated if that simplifies things, I think Dan had originally though of this as working like a bond market of some sort but I'm not sure it was ever useful in that way... thoughts?

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #12 on: October 30, 2016, 04:50:12 am »
Hi pc,

I'm impressed with how detail oriented you have been in fleshing out all the impacts of this change!  It seems like it could be a lot of work.  Getting that bug fixed with the feed expiration time preventing people from settling positions seems to be most important. Otherwise the primary goal is to recover the name for re-use right?  Do you think it might be possible/easier to allow the original issuer (after a certain period of time) to create a new asset that would just show up in the user interface under the same previous name?  Whereas prior versions of the asset that have been black swanned /force settled are represented differently to indicate this?

In regard to assets used as backing for other assets (SWAN backing DUCK) I'm not sure this is a very useful feature in the first place and maybe could be eliminated if that simplifies things, I think Dan had originally though of this as working like a bond market of some sort but I'm not sure it was ever useful in that way... thoughts?

Great job outlining all the details and taking the initiative [member=94]pc[/member]! This is very important!

[member=9289]Agent86[/member] Recovering the name sounds like creatively simple solution! 

BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #13 on: October 30, 2016, 09:02:19 am »
Thanks for your feedback!

Getting that bug fixed with the feed expiration time preventing people from settling positions seems to be most important. Otherwise the primary goal is to recover the name for re-use right?  Do you think it might be possible/easier to allow the original issuer (after a certain period of time) to create a new asset that would just show up in the user interface under the same previous name?  Whereas prior versions of the asset that have been black swanned /force settled are represented differently to indicate this?

Yup, fixing that bug is important (and it's a simple fix). But that requires a hardfork, so while we're at it we should think about what else we need to fix.

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.

In regard to assets used as backing for other assets (SWAN backing DUCK) I'm not sure this is a very useful feature in the first place and maybe could be eliminated if that simplifies things, I think Dan had originally though of this as working like a bond market of some sort but I'm not sure it was ever useful in that way... thoughts?

I'm not sure about the usefulness either. Nevertheless, such assets exist and therefore the case must be handled properly.

At least there seems to be some interest in the bond market, as it was only recently brought up in this thread: https://bitsharestalk.org/index.php/topic,23354.0.html
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Online pc

  • Hero Member
  • *****
  • Posts: 1524
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Re: Minimal required changes to revive an MPA after a black swan event?
« Reply #14 on: October 30, 2016, 09:04:23 am »
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