0 Members and 1 Guest are viewing this topic.
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
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.
We must give 3rd parties (exchanges and other businesses) sufficient time to get notified and upgrade.
Any know if this information was sent to Bittrex? Could be why they are going to delist BTS on the 13th?
seems you hired another fuck worker taska 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 workermaybe a custom service worker.blockchain fuckerQuote from: pc on October 02, 2017, 08:38:16 pmTesters (other than myself) are not paid through the proposal, see http://www.bitshares.foundation/workers/2017-07-peter-conrad .
Testers (other than myself) are not paid through the proposal, see http://www.bitshares.foundation/workers/2017-07-peter-conrad .
one question, if testing is part of the BSIP18 work, should the testers be paid from the fund of the worker proposal?
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.
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 ..
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
get_asset CLOSED.USD
update_asset_feed_producers CLOSED.USD ["crn"] true
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
borrow_asset crn 1000 CLOSED.USD 0.2 true
settle_asset crn 10 CLOSED.USD true
sell_asset crn 10 CLOSED.USD .01 TEST 0 false truepublish_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
Quote from: pc on September 26, 2017, 06:51:52 pmQuote from: Brekyrself on September 26, 2017, 06:12:51 pmAny 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?
Quote from: Brekyrself on September 26, 2017, 06:12:51 pmAny 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.
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?
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).
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.
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.
Quote from: 麥可貓 on July 13, 2017, 06:02:32 pmSetup a backup pool to act as collateral to rescue those not-sufficiently backed MPA out.Yes, that's a good simplified summary. :-)
Setup a backup pool to act as collateral to rescue those not-sufficiently backed MPA out.
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.
QuoteThe 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 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.
Quote from: biophil on June 07, 2017, 02:29:28 pmGlobal 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.
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.
Quote from: biophil on June 06, 2017, 03:02:17 pmDoesn'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, and2. when a short position of an MPA has insufficient collateral to buy back the debt.How would you fix that?
Doesn't the global settlement operation seem like it's what should be fixed?
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.
additional_debt is superfluous and should be removed. It can be replaced with a preceding asset_settle_operation and adjusting additional_collateral accordingly.
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?
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 paidsymbol (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 positionadditional_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 obtainThe operation works as follows:It pays a feeIt 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.
Please read through this proposal: https://github.com/bitshares/bsips/blob/master/bsip-0018.md
"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 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.