BSIP-18: How to easily revive a BitAsset after Black Swan - read for comment

[pc]

We now have an official release: https://github.com/bitshares/bitshares-core/releases/tag/2.0.171025
I think @xeroc will make an announcement.

[Brekyrself]

We've tagged a pre-release. Upgrade at your own risk, preferrably non-critical systems first.
https://github.com/bitshares/bitshares-core/releases/tag/2.0.171024

Thats great news, thanks for all for the hard work.  Now whats the next project your going to tackle

[pc]

We've tagged a pre-release. Upgrade at your own risk, preferrably non-critical systems first.
https://github.com/bitshares/bitshares-core/releases/tag/2.0.171024

[abit]

Great, thanks!

I'm not aware of anyone else still testing, nor have I received any negative reports.

I'll start preparing the mainnet release now. Preliminary hardfork date is 2017-11-27 15:00 UTC, unless anyone comes up with a convincing argument that this is a bad choice.

Just a note here, as we've discussed in Telegram, the hardfork date/time will be 2017-11-27 14:40 UTC.

[fav]

can we start to spread the word, or is it not live yet?

[R]

We must give 3rd parties (exchanges and other businesses) sufficient time to get notified and upgrade.

2 weeks should be sufficient enough time for anyone to upgrade once we've gained their attention (likely the hardest bit for poloniex, haha!)
I'm just impatient

[pc]

We must give 3rd parties (exchanges and other businesses) sufficient time to get notified and upgrade.

[Brekyrself]

Great, thanks!

I'm not aware of anyone else still testing, nor have I received any negative reports.

I'll start preparing the mainnet release now. Preliminary hardfork date is 2017-11-27 15:00 UTC, unless anyone comes up with a convincing argument that this is a bad choice.

Why 1+ month away for the hardfork?  Continued testing or simply want to get the witnesses on board?

[pc]

Great, thanks!

I'm not aware of anyone else still testing, nor have I received any negative reports.

I'll start preparing the mainnet release now. Preliminary hardfork date is 2017-11-27 15:00 UTC, unless anyone comes up with a convincing argument that this is a bad choice.

[ElMato]

Hi guys, as witness i agree with the changes and hardfork date

[pc]

Thanks for the approvals, guys.

Any know if this information was sent to Bittrex?  Could be why they are going to delist BTS on the 13th?

According to @Stan bittrex has suffered from the problem. I don't know if that's the reason for the delisting though.

Exchanges will have be notified when the mainnet release is available. It might be a good idea to highlight that p2p fix in the release notes.

[Brekyrself]

Thanks for the update PC.  Any know if this information was sent to Bittrex?  Could be why they are going to delist BTS on the 13th?

[abit]

I'm OK with the progress and the scheduled HF date range.

[roelandp]

This is great news. A hardfork around end of November would be timeframe of choice as well. thank you for all this work. Especially the p2p fix is a great last minute fix. Recently a steem network interruption on my node automatically caused to reconnect when network state returned normal. Bitshares behind the same router didn't and had to auto-switch to another failover node. Nonetheless the revival of black-swanned currencies will certainly help the platform further. Thank you, thank you. I approve the hardfork for sure!

[pc]

A couple of days ago, @dannotestein alerted us to an issue in the P2P code that may have been causing problems to exchanges. It seems that nodes would get stuck for hours, conveying the impression that the blockchain was dead.
@xeroc backported a fix from STEEM into our codebase. The fix is currently being tested in testnet and will become part of the next master release.

The following witnesses (and others) have contributed to testing so far:

Code review (Github)
* @abit
* Alfredo aka @oxarbitrage
* @xeroc
* Several others (@wackou, @Thom, @Taconator, …)

Approvals so far
* @xeroc
* @Fox
* iPerky aka @iHashFury
* @Bhuz
* @sahkan
* @roelandp
* @abit
* @wackou
* @Thom aka verbaltech2
* @ElMato

I'm still hoping for an ACK from @Thom , then I'll prepare the mainnet hardfork.

I'd suggest a hardfork date around end of November, that'd give everyone about 6 weeks to upgrade, which is plenty IMO.

Edit: added approvals from roelandp, abit, wackou, thom and elmato

[Taconator]

seems you hired another fuck worker task
a core fork development even without code review and test.
you need to hired another fuck test worker and another review worker.
consider hire another fuck requirement worker
maybe a custom service worker.

blockchain fucker

Testers (other than myself) are not paid through the proposal, see http://www.bitshares.foundation/workers/2017-07-peter-conrad .

You must not have seen the units tests that were prepared by pc for this worker. In particular, see the completely new tests under swan_tests.cpp file, along with updates to existing tests in order to support the black swan revival.

Additionally, I do not think the words "fuck" and "fucker" means what you think it does. In this context it is both offensive and vulgar (and probably physically impossible). Surely, another word would be more appropriate.

[pc]

Please rethink your wording.

Code review is one of the responsibilities of Alfredo, our paid developer. In return, I have reviewed other contributions, and the hardfork includes a lot more than just bsip-18. The bsip-18 code has been reviewed by several other volunteers as well. It's all on github if you really care.
I think the shareholders are getting very good value for this worker.

My opinion about witness responsibilities have been expressed in the proposal from the beginning. The shareholders have approved this. I don't know what you're complaining about.

[alt]

seems you hired another fuck worker task
a core fork development even without code review and test.
you need to hired another fuck test worker and another review worker.
consider hire another fuck requirement worker
maybe a custom service worker.

blockchain fucker

Testers (other than myself) are not paid through the proposal, see http://www.bitshares.foundation/workers/2017-07-peter-conrad .

[pc]

one question, if testing is part of the BSIP18 work, should the testers be paid from the fund of the worker proposal?

Testers (other than myself) are not paid through the proposal, see http://www.bitshares.foundation/workers/2017-07-peter-conrad .

My work includes the following milestones:

* 20% specification (already delivered, see BSIP-0018)
* 30% implementation (mostly finished)
* 10% integration into testnet (*)
* 10% testing (*)
* 10% bugfixes
* 10% integration into mainnet, including release (*)
* 5% supervision of hardfork (*)
* 5% supervision of initial coordinated MPA revival after hardfork (*)

I expect the current witnesses to actively assist in the items marked with (*). It is their responsibility to maintain the operation of the chain, and ultimately it is their decision which version of bitshares-core they use to produce blocks. With the current price of BTS, witness pay should be sufficient reward for their efforts.

[iHashFury]

Great work @pc

I was able to:

• reset SETTLE on the test-net
• blackswan SETTLE again
• then reset SETTLE using "bid_collateral" cli command

I look forward to seeing this code forked into bitshares-core
 

[bitcrab]

seem I need to go through my witness votes and kick out some of those that aren't as active as they are supposed to be for the amount of money they get.
By reducing the number of active witnesses we also reduce the operational costs of the blockchain ... let's see when people start complaining real hard ..

reducing the number of active witnesses is not a good idea, and this do not reduce the costs of the blockchain as block generating speed is not reduced.

one question, if testing is part of the BSIP18 work, should the testers be paid from the fund of the worker proposal?

[Fox]

Thank you @pc for providing the CLI commands.

I was able to utilize these for testing FOXUSD (1.3.366) on the TESTNET. I am confident with the functionality of the code implemented therein.

Please note my APPROVAL of the code for release to MAINNET.

[pc]

In order to make testing easier for everyone, here are a few example CLI commands for creating a bitasset and generating a black swan. Also see http://docs.bitshares.eu/api/wallet-api.html#asset-calls .

Issuer "crn" creates an asset with symbol "CLOSED.USD", 4 decimals and the given asset options (all permissions, override_authority flag, core exchange rate of .1 CLOSED.USD / 1 TEST) and bitasset options (1 hour pricefeed lifetime, 1 hour settlement delay, 50% maximum settlement ratio):

Code: [Select]

create_asset crn CLOSED.USD 4 {"issuer_permissions":511,"flags":4,"core_exchange_rate":{"base":{"amount":1000,"asset_id":"1.3.1"},"quote":{"amount":100000,"asset_id":"1.3.0"}}} {"feed_lifetime_sec":3600,"force_settlement_delay_sec":3600,"maximum_force_settlement_volume":5000} true

Show the new asset (note its ID, it is required for publishing feeds):

Code: [Select]

get_asset CLOSED.USD

Set the list of feed producers to the issuer account only (alternatively, set the witness_fed_asset or the committee_fed_asset flag):

Code: [Select]

update_asset_feed_producers CLOSED.USD ["crn"] true

Publish a feed price of .1 CLOSED.USD / .00001 TEST and a core exchange rate of .0001 CLOSED.USD / .01 TEST (you have to substitute the ID of your own asset in two places!). Warning: with these settings someone can cheaply borrow CLOSED.USD and use them to empty the fee pool!

Code: [Select]

publish_asset_feed crn CLOSED.USD {"settlement_price":{"base":{"asset_id":"1.3.341","amount":1000},"quote":{"asset_id":"1.3.0","amount":1}},"maintenance_collateral_ratio":1750,"core_exchange_rate":{"base":{"amount":1,"asset_id":"1.3.341"},"quote":{"amount":1000,"asset_id":"1.3.0"}}} true

Account "crn" borrows 1000 CLOSED.USD from the blockchain, providing 0.2 TEST as collateral:

Code: [Select]

borrow_asset crn 1000 CLOSED.USD 0.2 true

Account "crn" settles 10 CLOSED.USD:

Code: [Select]

settle_asset crn 10 CLOSED.USD true
You have to wait for the settlement delay, i. e. 1 hour in the example, provided that there is a valid pricefeed at that time. If executed after a black swan, settlement happens immediately.

Account "crn" places a sell order of 10 CLOSED.USD for .01 TEST (no expiration, no fill-or-kill flag) on the market. The subsequent price feed update triggers the black swan (again, you have to substitute your asset ID twice):

Code: [Select]

sell_asset crn 10 CLOSED.USD .01 TEST 0 false true

publish_asset_feed crn CLOSED.USD {"settlement_price":{"base":{"asset_id":"1.3.341","amount":1000},"quote":{"asset_id":"1.3.0","amount":10}},"maintenance_collateral_ratio":1750,"core_exchange_rate":{"base":{"amount":1,"asset_id":"1.3.341"},"quote":{"amount":100,"asset_id":"1.3.0"}}} true

For the black swan it is required that the short position is margin called AND a sell order exists AND the short has insufficient collateral to cover the debt at the best sell price.

[xeroc]

Any update in regards to the new software on testnet?  Is there any criteria in place to verify before scheduling a fork on the production network?

A very good questions. Yesterday I have asked the witnesses about the progress with their testing, but have yet to receive an answer.
Of course anyone is welcome to test on testnet, but the responsibility really lies with the witnesses, IMO.

Perhaps this is something the BitShares foundation can accomplish.  How do we hold witnesses to a higher standard?  Have a web page dedicated to witness feedback on items requiring testing?

thats exactly what the mailing lists there are supposed to do .. they need to grow in their traffic anyways, but i really cannot do everything in my own

[xeroc]

seem I need to go through my witness votes and kick out some of those that aren't as active as they are supposed to be for the amount of money they get.
By reducing the number of active witnesses we also reduce the operational costs of the blockchain ... let's see when people start complaining real hard ..

[Brekyrself]

Any update in regards to the new software on testnet?  Is there any criteria in place to verify before scheduling a fork on the production network?

A very good questions. Yesterday I have asked the witnesses about the progress with their testing, but have yet to receive an answer.
Of course anyone is welcome to test on testnet, but the responsibility really lies with the witnesses, IMO.

Perhaps this is something the BitShares foundation can accomplish.  How do we hold witnesses to a higher standard?  Have a web page dedicated to witness feedback on items requiring testing?

[pc]

Any update in regards to the new software on testnet?  Is there any criteria in place to verify before scheduling a fork on the production network?

A very good questions. Yesterday I have asked the witnesses about the progress with their testing, but have yet to receive an answer.
Of course anyone is welcome to test on testnet, but the responsibility really lies with the witnesses, IMO.

[Brekyrself]

The hardfork on testnet went well today. We successfully revived some bitassets after artificially created black swans.

The bad news is that, so far, witness participation leaves much to be desired:
* Of the 25 active witnesses on mainnet, only 12 are currently active on testnet.
* During and after the hardfork only rnglab, bhuz and lafona showed up on telegram. Later, wackou and thom (aka verbaltech) showed up. (Xeroc and myself were also present, but we're not witnesses.)
* I'm not aware of any witnesses preparing and/or executing significant tests.

Witnesses, please perform any acceptance tests you deem necessary on testnet. Report any bugs you find on github, or here in this thread if you don't have a github account. If no showstoppers turn up, I plan to prepare the main release in about a week, with the hardfork date at least one month in the future (this is open to discussion of course).

Any update in regards to the new software on testnet?  Is there any criteria in place to verify before scheduling a fork on the production network?

[Brekyrself]

very happy to hear the revive asset process had worked in the testnet. will be nice to paste some output so the users can get familiar with the process commands needed.

in regards to the addition of testnet to the explorer proposed by @Brekyrself , it is definitely possible but will need a new server to run the testnet and the explorer backend. i think it is good to have the explorer working in the production and testnet side by side. i am not sure however if this will help knowing what witnesses are diligent, please explain me more about that.

thanks.

As far as data metrics, I was thinking just mirroring the production explorer.  Witnesses should be testing the latest and greatest to make sure no block production issues arise before hitting production.

The basics such as seeing if the production witnesses are even running a node on testnet?
How many blocks they have missed? 
Perhaps even blocks missed/last 24 hours?
Statistics around publishing feeds and how often?

[oxarbitrage]

very happy to hear the revive asset process had worked in the testnet. will be nice to paste some output so the users can get familiar with the process commands needed.

in regards to the addition of testnet to the explorer proposed by @Brekyrself , it is definitely possible but will need a new server to run the testnet and the explorer backend. i think it is good to have the explorer working in the production and testnet side by side. i am not sure however if this will help knowing what witnesses are diligent, please explain me more about that.

thanks.

[Brekyrself]

The hardfork on testnet went well today. We successfully revived some bitassets after artificially created black swans.

The bad news is that, so far, witness participation leaves much to be desired:
* Of the 25 active witnesses on mainnet, only 12 are currently active on testnet.
* During and after the hardfork only rnglab, bhuz and lafona showed up on telegram. Later, wackou and thom (aka verbaltech) showed up. (Xeroc and myself were also present, but we're not witnesses.)
* I'm not aware of any witnesses preparing and/or executing significant tests.

Witnesses, please perform any acceptance tests you deem necessary on testnet. Report any bugs you find on github, or here in this thread if you don't have a github account. If no showstoppers turn up, I plan to prepare the main release in about a week, with the hardfork date at least one month in the future (this is open to discussion of course).

Thank you for the follow up.  All witnesses should also be active on testnet to aid in development. 

@oxarbitrage any chance of adding the testnet to the explorer so we can see both networks?  This way we can see which witnesses are staying diligent to the bitshares ecosystem.
@bitcrab Can you push the witnesses you support to also run nodes on the testnet?

[pc]

The hardfork on testnet went well today. We successfully revived some bitassets after artificially created black swans.

The bad news is that, so far, witness participation leaves much to be desired:
* Of the 25 active witnesses on mainnet, only 12 are currently active on testnet.
* During and after the hardfork only rnglab, bhuz and lafona showed up on telegram. Later, wackou and thom (aka verbaltech) showed up. (Xeroc and myself were also present, but we're not witnesses.)
* I'm not aware of any witnesses preparing and/or executing significant tests.

Witnesses, please perform any acceptance tests you deem necessary on testnet. Report any bugs you find on github, or here in this thread if you don't have a github account. If no showstoppers turn up, I plan to prepare the main release in about a week, with the hardfork date at least one month in the future (this is open to discussion of course).

[pc]

The development branch was merged into testnet yesterday, with a hardfork planned for friday 2017-09-15 12:00:00 UTC.

[pc]

Sorry about the delay.

The developers (i.e. mostly Alfredo, abit and myself) have been quite busy working behind the scenes, reviewing various contributions on github and planning for the upcoming hardfork.

In addition, it has turned out that our formal processes are inadequate for small bugfixes that require changing the consensus logic. After discussing this here, consensus seems to be that for bugfixes witness approval is sufficient.

We now plan to include these three bugfixes in the upcoming BSIP-0018 hardfork:

• https://github.com/bitshares/bitshares-core/pull/348
• https://github.com/bitshares/bitshares-core/pull/369
• https://github.com/bitshares/bitshares-core/pull/384

I have asked for witness opinion on telegram. If they signal approval we will merge the PRs within the next couple of days, and then proceed to prepare a hardfork on testnet.

[pc]

Who is going to pay to make the settlement fund BACK reach the minimum required collateral? Because it should not be the responsibility of every bts holders to rescue a specific bad MPA. The exchange sould not rescue a bad asset, they should let bad assets die out and good assets survive.

I fully agree with that. The proposed mechanism does not *force* anybody to pay for the revival.

Or else, is this proposal really going to cover the above issue or just to provide a methodology (and leave this issue to be determined case by case)? This could be better IMO. I mean, each case could differ vastly. For example, if one MPA has vary little trading volume, I prefer to stop this MPA, restart a new one after coming up with a better plan.

Exactly. I see three main use cases for the mechanism:

1. When the price of BACK recovers sufficiently, no additional collateral is required and the asset is revived automatically. I believe this would be applicable to the black swans we had in the early days of BTS-2.0, i. e. SEK and RUB.
2. The creator of an MPA may be interested in keeping his asset alive, and might be willing to add the required collateral, possibly after reviewing his price feed policy and MCR. Candidates for this might be GRC (GridCoin) and some of the formula-based assets that are being discussed here in the forum.
3. When BACK recovers to a point above the nominal value of SWAN, but is still below MCR, an investor who is bullish on BACK may be willing to pay additional collateral, hoping to make a profit if BACK rises even higher.

[fav]

Or else, is this proposal really going to cover the above issue or just to provide a methodology (and leave this issue to be determined case by case)? This could be better IMO. I mean, each case could differ vastly. For example, if one MPA has vary little trading volume, I prefer to stop this MPA, restart a new one after coming up with a better plan.

exactly my thoughts. BSIP18 is only useful if say bitUSD black swans due to a bug or something.

other than that, dead assets are not profitable anyways, they can just die off in my opinion

[麥可貓]

Setup a backup pool to act as collateral to rescue those not-sufficiently backed MPA out.

Yes, that's a good simplified summary. :-)

Thank you for your reply. After discussion with others who also read the BSIP0018, we raised some further concerns:

Who is going to pay to make the settlement fund BACK reach the minimum required collateral? Because it should not be the responsibility of every bts holders to rescue a specific bad MPA. The exchange sould not rescue a bad asset, they should let bad assets die out and good assets survive.

Or else, is this proposal really going to cover the above issue or just to provide a methodology (and leave this issue to be determined case by case)? This could be better IMO. I mean, each case could differ vastly. For example, if one MPA has vary little trading volume, I prefer to stop this MPA, restart a new one after coming up with a better plan.

[pc]

Setup a backup pool to act as collateral to rescue those not-sufficiently backed MPA out.

Yes, that's a good simplified summary. :-)

[麥可貓]

I am afraid that I am confused with those financial terms, but I want to ask if I can summarize this proposal as the following:
Setup a backup pool to act as collateral to rescue those not-sufficiently backed MPA out.

Or please could you give me a take home message without those terms?
Thank you

[pc]

BSIP-0018 has been updated: https://github.com/bitshares/bsips/blob/master/bsip-0018.md

tl:dr:
* fix the bug that prevents individual settlement after price feeds have expired
* allow publishing price feed for an asset even after is has seen global settlement
* automatically turn the settlement_fund and current_supply into a call_order belonging to the issuer if the price of the collateral has recovered sufficiently
* allow users to "bid" on debt/collateral and turn settlement_funds + bids into call_orders when sufficient bids have been made (as originally suggested)

I'd appreciate your comments, because I plan to set up a worker proposal for this.

[yvv]

When a black swan happens, it is typically due to one short position becoming undercollateralized. That position has a known owner, who is in a way the culprit. You *could* force-settle that specific short position - but against whom? You'd have to pick one (or possibly more, depending on the volume of the undercollateralized short) holder of the bitasset, take the funds away from him and pay out a number of BTS to him/them that is likely insufficient to cover his/their loss.

I don't see how you can do this, if the total value of debt is greater than the total value of collateral. Whichever position(s) you chose to settle will not be enough to cover the debt created by a single culprit, and you have no choice but to settle everybody globally.
 

[pc]

The thing is, the short positions have different owners. What do you do when the short position of person A becomes insufficiently collateralized?
Take collateral from person B, who may have put in more collateral for his debt, to compensate? That would be extremely unfair to person B, and would encourage everybody to put in just as much collateral as is absolutely required.
Or would you force settle person C, who is in a long position, paying him the insufficient collateral as compensation? That would be extremely unfair on person C, and would violate the settlement guarantee.

In the end, there is no fair way out of this. The most fair thing to do is treat everyone the same, settle the asset globally and shut it down. That's how it is implemented.

And yes, that is the inherent risk with MPAs, and also their weak point.

Like @biophil, I offer my apologies in advance as I have not been involved in this conversation. However, the quote above is at a level I can understand and at least ask questions about:

Q1: Why force settle globally and not individually?
Q2: Is it not possible to force settle person A and leave the others with adequate collateral alone?
Q3: In the event of a rapidly changing market where a series of individual force settles would "clog" the asset, can't an algorithm be applied that says, "if X positions of the asset are force settled within Y time frame declare a 'black swan' event and force settle all remaining short positions".
Q4: I presume all participants have the same (minimum) collateral requirements, but can shorters provide more than the minimum when the short position is created? If so an individual settlement position makes sense, otherwise I can see why a global settlement makes sense  as all short positions are equally under collateralized. The market as a whole may not be, so long as the total collateral of all shorters does not fall below 100%.

I can well imagine some may argue that it is the largest positions that will be force settled first as they have the potential to impact the 100% threshold. I would counter-argue that is the risk to be borne by such large scale investors.

The idea is to treat everybody the same. (At least that's my understanding. The answer may be hidden in a forum thread from 2 years ago.)

When a black swan happens, it is typically due to one short position becoming undercollateralized. That position has a known owner, who is in a way the culprit. You *could* force-settle that specific short position - but against whom? You'd have to pick one (or possibly more, depending on the volume of the undercollateralized short) holder of the bitasset, take the funds away from him and pay out a number of BTS to him/them that is likely insufficient to cover his/their loss.

Selecting an arbitrary individual to take the loss of the undercollateralized position is obviously unfair. Instead, the asset is settled globally, which means everybody is treated the same, which may not be a nice thing to do, but at least it is fair.

Re Q4: yes, shorters can offer more collateral than required. In fact this is recommended, because otherwise they will be margin called.

[Thom]

Global settlement seems to say "if a single short position lacks sufficient collateral, shut the entire token down immediately AND ditch the majority of that token's collateral." Right? Just because a single short position falls below 100% collateralization doesn't mean that most short positions aren't​ appropriately collateralized, but in global settlement most of that collateral is returned to the short positions.

Right.

The thing is, the short positions have different owners. What do you do when the short position of person A becomes insufficiently collateralized?
Take collateral from person B, who may have put in more collateral for his debt, to compensate? That would be extremely unfair to person B, and would encourage everybody to put in just as much collateral as is absolutely required.
Or would you force settle person C, who is in a long position, paying him the insufficient collateral as compensation? That would be extremely unfair on person C, and would violate the settlement guarantee.

In the end, there is no fair way out of this. The most fair thing to do is treat everyone the same, settle the asset globally and shut it down. That's how it is implemented.

And yes, that is the inherent risk with MPAs, and also their weak point.

Like @biophil, I offer my apologies in advance as I have not been involved in this conversation. However, the quote above is at a level I can understand and at least ask questions about:

Q1: Why force settle globally and not individually?
Q2: Is it not possible to force settle person A and leave the others with adequate collateral alone?
Q3: In the event of a rapidly changing market where a series of individual force settles would "clog" the asset, can't an algorithm be applied that says, "if X positions of the asset are force settled within Y time frame declare a 'black swan' event and force settle all remaining short positions".
Q4: I presume all participants have the same (minimum) collateral requirements, but can shorters provide more than the minimum when the short position is created? If so an individual settlement position makes sense, otherwise I can see why a global settlement makes sense  as all short positions are equally under collateralized. The market as a whole may not be, so long as the total collateral of all shorters does not fall below 100%.

I can well imagine some may argue that it is the largest positions that will be force settled first as they have the potential to impact the 100% threshold. I would counter-argue that is the risk to be borne by such large scale investors.

[pc]

Global settlement seems to say "if a single short position lacks sufficient collateral, shut the entire token down immediately AND ditch the majority of that token's collateral." Right? Just because a single short position falls below 100% collateralization doesn't mean that most short positions aren't​ appropriately collateralized, but in global settlement most of that collateral is returned to the short positions.

Right.

The thing is, the short positions have different owners. What do you do when the short position of person A becomes insufficiently collateralized?
Take collateral from person B, who may have put in more collateral for his debt, to compensate? That would be extremely unfair to person B, and would encourage everybody to put in just as much collateral as is absolutely required.
Or would you force settle person C, who is in a long position, paying him the insufficient collateral as compensation? That would be extremely unfair on person C, and would violate the settlement guarantee.

In the end, there is no fair way out of this. The most fair thing to do is treat everyone the same, settle the asset globally and shut it down. That's how it is implemented.

And yes, that is the inherent risk with MPAs, and also their weak point.

[biophil]

Doesn't the global settlement operation seem like it's what should be fixed?

Global settlement happens in two situations:

1. In a prediction market, after the to-be-predicted event has a defined outcome, and
2. when a short position of an MPA has insufficient collateral to buy back the debt.

How would you fix that?

Offhand? I don't know how I'd fix it, and I realize that I've not been here for the lengthy discussions on it. But it seems like an incredibly weak point of the MPA system.

Global settlement seems to say "if a single short position lacks sufficient collateral, shut the entire token down immediately AND ditch the majority of that token's collateral." Right? Just because a single short position falls below 100% collateralization doesn't mean that most short positions aren't​ appropriately collateralized, but in global settlement most of that collateral is returned to the short positions. It's like at the first sign of danger we burn our safety net.

It just seems like a bizzarely extreme measure. But like I said, I'm aware that this has been discussed before and I'm ignorant of all those issues.

[xeroc]

Instead of requiring the settlement pool to be purchased all in one go, why not let multiple accounts "bid" for it? Anybody who wants to can say "I want X amount of settlement_funds, and I'll commit Y amount of additional_collateral and Z amount of additional_bitasset." Then when all the settlement funds have been accounted for and there is sufficient collateral committed, all the bidders' bids are filled and the bitasset is revived. I haven't thought through how exactly you'd split the funds between the bidders, but I suspect there's a natural way that will be obvious once someone sits down and plays with the math.

This is exactly what I tried to manage with the `obtain_settlement_funds` parameter so that people can "bid" for a fraction of the settlement funds.
I'll add more text to clarify this.

additional_debt is superfluous and should be removed. It can be replaced with a preceding asset_settle_operation and adjusting additional_collateral accordingly.

Agreed

Also, I'm unclear what the purpose of the obtain_settlement_funds parameter is. Surely the command cannot be used to extract value from the settlement fund?

It is meant to define how much of the settlement fund you'd like to "obtain" (of course together with the corresponding debt)

[pc]

Some more comments:

This operation is all that is needed empty the settlement pool and re-enable price feeds. It has the following payload:

• fee (asset_type): The operation requires a fee to be paid
• symbol (asset_id_typ): Symbol that has a settlement fund to be claimed.
• account (account_type): This account obtains the collateral as well as the debt (i.e. call position) and has to either pay additional collateral, provide shares of the BitAsset to reduce the outstanding debt, or a combination of both.
• additional_collateral (asset_type): Collateral paid by the account in order to support the call position
• additional_debt (asset_type): Debt that is paid by the account in order to reduce the debt (while keeping the full settlement pool as collateral)
• obtain_settlement_funds (asset_type): The amount of settlement funds the account is willing to obtain

The operation works as follows:

• It pays a fee
• It reduces the account's balance by debt. The debt is used to reduce the outstanding shares of the globally settled BitAsset.
• It reduces the account's balance by collateral. The collateral is used to initially support the accounts' call position. However, technically, only little additional collateral is required (if the valuation of the collateral hasn't change since the global settlement) if the owner accepts a margin call.
• The global settlement flag is removed from the asset.
• The asset is re-enabled such that price feeds can be produced again.
• After sufficient price feeds, the asset can be borrowed again.

additional_debt is superfluous and should be removed. It can be replaced with a preceding asset_settle_operation and adjusting additional_collateral accordingly.

Please explain what the resulting call_order_object looks like.

Also, I'm unclear what the purpose of the obtain_settlement_funds parameter is. Surely the command cannot be used to extract value from the settlement fund?

[pc]

Doesn't the global settlement operation seem like it's what should be fixed?

Global settlement happens in two situations:

1. In a prediction market, after the to-be-predicted event has a defined outcome, and
2. when a short position of an MPA has insufficient collateral to buy back the debt.

How would you fix that?

[pc]

Please read through this proposal:

    https://github.com/bitshares/bsips/blob/master/bsip-0018.md

Good job! Actually, I was working on something similar since we last talked about it. (Credits for the idea belong to Xeroc!) Here's a preliminary version: https://github.com/pmconrad/bsips/blob/bsip-0017a/bsip-0017a.md

I think we should enable price feeds for MPAs even after a black swan. That way, we know how much additional collateral is needed before the asset can be revived.

I've also thrown in parts of bsip-0017, because I see this as a first step towards implementing the full bsip-0017.

"Black swan" is incorrect term in this context. It refers to an event that is impossible or at least very difficult to foresee.

"Black swan" is the term traditionally used in this community for the problem of short positions becoming undercollateralized. (It may well be that the original intention was in fact that this should never happen. Reality thought different, though. :-/ )

The term is also used in the source code, so I suggest we stick to it.

[biophil]

I was away from bitshares for a long time and I'm definitely not up to speed on all the discussions that got us here, but this feels a tiny bit like using a second hack to cover the issues created by a first hack.

Doesn't the global settlement operation seem like it's what should be fixed? rather than saying "oops, global settlement puts us in an incredibly awkward position so we better create a new operation to clean up that mess."

But anyway, maybe it's easier to add a new operation than fix the old one. In that case, I just have one concern with your proposal:

The way your proposal is worded makes it sound like a single account would have to buy the entire settlement pool. I would think about a slight variant instead:

Instead of requiring the settlement pool to be purchased all in one go, why not let multiple accounts "bid" for it? Anybody who wants to can say "I want X amount of settlement_funds, and I'll commit Y amount of additional_collateral and Z amount of additional_bitasset." Then when all the settlement funds have been accounted for and there is sufficient collateral committed, all the bidders' bids are filled and the bitasset is revived. I haven't thought through how exactly you'd split the funds between the bidders, but I suspect there's a natural way that will be obvious once someone sits down and plays with the math.

Also I'd let people cancel their bids if they want.

BTW, I pull-requested a couple typos in the github document.

[Samupaha]

Here is the full explanation: https://en.wikipedia.org/wiki/Black_swan_theory

[xeroc]

"Black swan" is incorrect term in this context. It refers to an event that is impossible or at least very difficult to foresee. Global settlement is very well known risk so it's not a black swan event. Please change the terminology or Nassim Taleb will laugh at you.

Thanks for the input .. I wasn't aware of that ..

[Samupaha]

"Black swan" is incorrect term in this context. It refers to an event that is impossible or at least very difficult to foresee. Global settlement is very well known risk so it's not a black swan event. Please change the terminology or Nassim Taleb will laugh at you.

[xeroc]

Hey there,

Please read through this proposal:

    https://github.com/bitshares/bsips/blob/master/bsip-0018.md

In short: It offers a new operation that can be used to obtain the funds (and the debt) in the settlement pool of a bitasset after a black swan event.
This would add a feature that can be used to revive black swan-ed bitassets at the costs of one (or many) individuals that are bullish on BitShares and are willing to obtain a *instant short position*.

Looking forward to reading your throughts.