Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BSIP59: Adjustment of MSSR and MCR through voting #140

Closed
bitcrab opened this issue Jan 27, 2019 · 36 comments

Comments

@bitcrab
Copy link
Contributor

@bitcrab bitcrab commented Jan 27, 2019

Title: Adjustment of MSSR and MCR through voting
Authors: Jerry Liu bitcrab@qq.com
Status: Draft
Type: Protocol
Created: 2019-01-27

Abstract

This BSIP define a process to change MSSR and/or MCR for one specific smartcoin through poll voting.

Motivation

In smartcoin system, debt and supply are the 2 sides of the same thing, increasing supply also means increasing debt, paying debt also means reducing supply, to make the smartcoin peg well and make the supply match the market demand is always the system goal.

We have done a lot to remove the unnecessary punishment to margin called debt position owners - Target CR, MSSR reduction, Global Settlement Protection, all these is to add more energy to the smartcoin system.

MSSR and MCR are the 2 key parameters in smartcoin system, MCR has big impact on smartcoin supply, MSSR has big impact on smartcoin premium and also the supply.

Now the 2 parameters are published by witnesses, generally speaking, witnesses publish MSSR&MCR following the consensus of the stakeholders, at the begin of BTS2.0, MSSR=1.1 and MCR=1.75 applied to all the smart coins, no changed has beed done until several weeks ago MSSR has been changed to 1.05 for bitCNY through BSIP41.

We can expect that in the future it's also necessary to change MSSR or/and MCR, some more complex proposal - dynamic MCR and MSSR are also discussed, before this advanced solution can get sufficient consensus and be available, we need to define a common process to change MSSR or/and MCR through voting.

Rationale

Here bitCNY is an example, the logic is same for all the smartcoins.

Definition: ratio = P[bitCNY/CNY] - 1

bitCNY discount = -ratio while ratio<0
bitCNY premium = ratio while ratio>0

While BTS price moves from high to low, bitCNY premium moves from low to high, the whole market condition can be divided into 4 phases:

1.bitCNY discount > force settlement offset (current value 2%)
Because of the force settlement, even bitCNY enter into this phase it will soon get out.

2.bitCNY discount < force settlement offset & bitCNY premium < (MSSR-1)  
In this phase, the margin call orders will be eaten immediately after it is generated, risk will not be accumulated and bitCNY peg well, this is the ideal phase.

3.bitCNY premium > (MSSR-1) 
In this phase the margin call orders will stay there without being eaten, global settlement price will not drop while the feed price drop, risk accumulate.

4.market price drop below the global settlement price
While global settlement protection measure is implemented, global settlement will not happen, feed price will stop to drop following the market price, if BTS price continue to drop, bitCNY will devalue.

It’s best for bitCNY to be always in phase 2, the system should always avoid bitCNY to fall in phase 4 in comparatively high BTS price.
If bitCNY fall in phase 3 for long time, it will be good to reduce the premium by reducing MSSR.
Decreasing of MCR will help to supply more bitCNY and help bitCNY to jump from phase 3 to phase

Specifications

In current Bitshares mechanism the witnesses are elected by voters. The values of MSSR and MCR for any smart asset issued by the BitShares Committee (i.e. bitAssets) are published by elected witnesses and then used by the blockchain to calculate the median value of the MSSR and MCR settings.

The above mechanisms will not be changed in this BSIP. This BSIP just establish a formal process to reach consensus on MSSR/MCR value setting and convey the consensus to witnesses.

Changes to MSSR/MCR will be decided on each smartcoin separately by voting, each time one change is issued 2 poll worker proposals will be created standing FOR and AGAINST the change.

For example, to decide whether to reduce MSSR to 1.02 for bitCNY, 2 poll worker proposals will be created for voting:

Poll-BSIP**-Reduce MSSR to 1.02 on bitCNY

Poll-BSIP**-No Reduce MSSR to 1.02 on bitCNY

If the voting confirm the change, committee will announce the change at least 3 days before the change is implemented by witnesses.

As change to MCR is not available because of a bug, this BSIP will apply only to MSSR change until the bug is fixed.

Potential Risks

Adjustment to one direction has both pros and cons.
Decreasing of MCR will help to supply more smartcoins, but will also make the average collateral ratio more close to 1 and may increase the possibility to fall in phase 4.
Decreasing of MSSR will help to reduce premium, but may also reduce the possibility for the margin called orders to be filled and increase the possibility to fall in phase 4.

Although the proposed values for MSSR and MCR could be selected carefully to comply with the market status and to avoid the risk, there is no way to guarantee that they will work well enough. Voters will need to evaluate each setting that is proposed in a BSIP poll.

References

Suggestion on bitCNY rules update after BSIP42

Summary for Shareholders

It is important to define a process for the stakeholders to decide to change MSSR/MCR through voting, This can currently be achieved with the technical options that are available to the witnesses.

Copyright

This document is placed in the public domain.

@xeroc

This comment has been minimized.

Copy link
Member

@xeroc xeroc commented Jan 31, 2019

To be clear, MSSR and MCR are witness-fed through their price feeds and not static.
That means, this feature would merely allow witnesses to poll for the desire of BTS holders.
Right now, I am not sure why we need this feature on-chain. It is probably much easier to use any kind of messaging with on-chain cryptographic proof to make a poll off-chain and indicate to a witness what he should use as parameters.

Ignore that, I read it wrong. This spec basically explains how workers are used to change the parameter and that witnesses are supposed to follow the outcome of the worker proposals

@ryanRfox

This comment has been minimized.

Copy link
Member

@ryanRfox ryanRfox commented Jan 31, 2019

I appreciate the direction @bitcrab it taking with his recent series of related BSIP drafts. Taken together, they inform about the market mechanics and offer insights in how, why and when to adjust them and what doing so may impact.

I do support allowing the BTS Token holders a vote in the parameters for the smartcoins. However, I feel an alternative mechanism should be considered as follows:

BTS Token Holders: vote for Committee Members and Block Producers
Elected Committee Members: Vote to adjust (to-be-defined) smartcoin parameters
Elected Block Producers: Publish smartcoin parameters

Resulting changes:
BTS Token Holders need not be consulted to update smartcoin parameters by vote, rather they delegate this duty to the Committee with their votes. BTS Token Holders retain the ability to vote for Block Producers, and may also vote for those that are directly publishing parameters they align with (allowing separation of responsibilities and decentralizing control of the smartcoins).

The Committee now has greater responsibility to maintain thoughtful and timely updates to the smartcoins on offer to the benefit of the DAC. They are viewed as the custodians of the parameters to keep the markets efficient.

Block Producers would likely publish the on-chain reference data provided by the Committee as smartcoin parameters. However, a Block Producer may choose to publish independent data as well, allowing BTS Token Holders an opportunity to more directly influence the smartcoin parameters.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 1, 2019

I do support allowing the BTS Token holders a vote in the parameters for the smartcoins. However, I feel an alternative mechanism should be considered as follows:

BTS Token Holders: vote for Committee Members and Block Producers
Elected Committee Members: Vote to adjust (to-be-defined) smartcoin parameters
Elected Block Producers: Publish smartcoin parameters

Currently the smartcoin parameters can be divided into 2 parts:

  1. committee controlled: force settlement offset, delay, max volume, etc.
  2. fed by witnesses: MCR, MSSR

Surely the committee controlled parameters can be always updated by committee, but regarding the witnesses fed parameters, committee has no power to update it.

Maybe committee can reach a consensus and request witnesses to update MCR/MSSR, but why should witnesses follow the request from committee?

Maybe MCR/MSSR can be modified to committee controlled parameters, but it need complex process and long time, and I am not sure whether the community can reach a consensus to do that, so we need to define how to update MCR/MSSR under current infrastructure, at least the poll worker proposal can work as witnesses need always follow the stake holders' decision.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 2, 2019

I am opposed to this proposal as it subverts the governance structure of this platform, as Ryan explained. I see this proposal as a way to grab power that should not be in the hands of a few investors as this would do.

Unlike Ryan I do not appreciate bitcrab's efforts to manipulate the platform or asset prices. Instead, I wish bitcrab and others would focus their attention on the problem of bad debt holders, specifically to design a penalty to disincentivise such individuals that repeadedly ignore best practices of self regulating their own risk by increasing or decreasing their smartcoin asset collateral ratio based on market volatility, not on how low they can drive their collateral.

With the proper penalty this problem will go away, and smartcoins will be the safe havens they were intended to be, and fair for all.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 4, 2019

I am opposed to this proposal as it subverts the governance structure of this platform, as Ryan explained. I see this proposal as a way to grab power that should not be in the hands of a few investors as this would do.

Unlike Ryan I do not appreciate bitcrab's efforts to manipulate the platform or asset prices. Instead, I wish bitcrab and others would focus their attention on the problem of bad debt holders, specifically to design a penalty to disincentivise such individuals that repeadedly ignore best practices of self regulating their own risk by increasing or decreasing their smartcoin asset collateral ratio based on market volatility, not on how low they can drive their collateral.

With the proper penalty this problem will go away, and smartcoins will be the safe havens they were intended to be, and fair for all.

penalty cannot remove the problems.

frankly speaking, MSSR/MCR are designed to be dynamic, but we seldom change it, I just like to ask you, if the community want to change these parameters, how can they do the decision?

I just want to make this decision process clearly.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 4, 2019

penalty cannot remove the problems.

You don't know that, it may. A penalty certainly will encourage better treatment of keeping a reasonable collateral level. Your proposals don't address root causes, only the symptoms of bad trade practices. I wish you would focus on the root causes instead of trying to fix the results of bad debt.

The logic of providing incentives to encourage a behavior and penalties to discourage undesired behavior is simple and well known. If global settlement is a problem, and I don't know anyone that thinks it's not, then how do we avoid it? If a single position can trigger it, what can we do to persuade traders to keep their collateral level "well above" a safe minimum of 1:1 ratio? I believe the answer is to penalize those who poorly manage their collateral.

IMO GS can be resolved in all but one single case: when the asset's market value drops too low or too rapidly for corrective human reaction. Has that ever occurred? Not for BitUSD or BitCNY, the dips could have been covered by a larger CR, which is entirely in the hands and responsibility of individual traders. There is no excuse besides greed to allow the CR to get anywhere near 1:1, and condoning those that do (by not penalizing them individually) simply shifts the burden of their responsibility onto the community to cover.

@pmconrad

This comment has been minimized.

Copy link
Contributor

@pmconrad pmconrad commented Feb 5, 2019

You cannot penalize people. You can only penalize accounts.
Accounts are cheap, so if you start penalizing them, traders will use throwaway accounts for shorting assets.
The result is that your penalty has no effect on the people involved, which means penalizing accounts is useless.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 5, 2019

Although your distinction between accounts and people is indeed correct, it makes zero difference. So they go to a new account to trade. If the penalty exists (on accounts, as that is the only "entity" a penalty can be applied to), and it tries to minimize collateral too low, the penalty will kick in on that account as well. If they upgraded the account to LTM to get cheapest trades, they would loose that advantage there as well.

I'm not necessarily referring to the penalty being the loss of LTM benefits, but that would be one way to impose a penalty. Point is your distinction is meaningless - they go to another account and whatever the penalty is would apply to that account as well if their behavior using it goes against the rule to keep collateral high enough to provide safety for all traders.

Those who try to minimize collateral trading on volatile markets are taking advantage of everyone else who recognizes why the collateral requirement is well above 1:1. Why do you argue to protect such people (accounts)?

I just don't get why this concept has such opposition, especially from BitShares veterans like you. Why haven't you opposed the 1.75 CR long ago? Why didn't anyone, b/c it was too easy to ignore?

This is such an obvious fix.

BitShares is a pioneer in this space, and one reason is we don't use the failed methods of traditional models. The design intent of BitShares is to provide safety, in several ways, one of them is well backed collateral for derivatives. That design intent is being ignored and we need to put measures in place to stop it, not patch the results of it that give bad actors an advantage over good actors.

Perhaps I'm simply witnessing the infiltration of bad actors into the platform who have gained enough power (by ignoring such rules as 1.75 CR) to subvert the design to their advantage. It is similar to an inflation "penalty" in how bypassing the rule gives an advantage to one at the expense of the many. It penalizes good actors in a subtle and collectivized manor.

I will speak out against that as long as I'm here. I say we protect good actors and penalize bad actors. Simple.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 6, 2019

Here I do not want to argue more on what a penalty should be, I suggest we focus on below question:

Can Bitshares Community change MCR and/or MSSR for a smartcoin? if yes, how to decide?

This BSIP is to define a process to do that change, actually the change can be decreasing or increasing the penalty, I can propose to reduce MSSR for bitCNY to 1.02, you can also propose to increase it to, say, 1.2.

But anyway we need to define a process to decide to do or not to do that kind of change.

Poll worker proposals will give the final results.

@pmconrad

This comment has been minimized.

Copy link
Contributor

@pmconrad pmconrad commented Feb 6, 2019

Why do you argue to protect such people (accounts)?

I am not arguing to protect such people, I'm arguing that your proposed "fix" doesn't work! Stop twisting my words please.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 6, 2019

I agree with you bitcrab, there no need to discuss the nature / type of penalty here. I only mentioned revocation of LTM as an example to make my point about the effectiveness of a penalty.

@pc, my understanding of your comment is that you claim my suggestion won't work due to your distinction between people and accounts. I saw no other rationale in your comment. As I said, accounts == people. How is that not correct in terms of how the system manages activities? The system has no awareness of "people", only accounts. For all practical purposes they are the same thing. Not trying to put words in your mouth, no need to get testy.

Are you thinking the penalty I suggested is only for specific, named accounts? I am suggesting that the penalty is activated on every account that has a short position whose CR drops below 1:1. The logic that triggers gs could spawn a task to be run at next maintenance to identify the account(s) whose CR is below 1:1.

As I think thru this I believe I understand why it may be difficult to do. However, to address the cause of the problem rather than the results of it we must find a way to identify the culprit(s). Anything short of that is a serious flaw IMO for reasons I continue to hammer. I'm not the only one that dislikes gs, but it seems like I am the only one trying to address the root cause of it.

Clearly scanning every account to check for short positions and then further chk if the CR for each shorted asset is below 1:1 would be a performance problem. If the problem set were reduced to only accounts with short positions, would that reduce the effort adequately?

This BSIP is about a stop gap measure to mitigate the results of the problem, it does not address the problem directly.

You will see me comment similarly on every such proposal until the discussion turns toward addressing the underlying cause, "bad debt". I have a difficult time believing a solution for identifying which accounts have under-collateralized positions is impossible without severe performance penalties. I see no need for that to be an instantaneous process.

The same could have been said of providing comprehensive account history & queries, prior to the development of ES. Perhaps a similar "out of the box" approach could be created for identifying problem accounts that short assets without maintaining adequate collateral. Perhaps a 2 stage approach could be employed, wherein the 1st stage is the current gs detection, and the 2nd stage (yet to be thought of) is identifying the causal account(s) and application of a penalty.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 7, 2019

This BSIP is about a stop gap measure to mitigate the results of the problem, it does not address the problem directly.

If now MCR is technically changeable, I'll propose to change it to 1.5 for bitCNY.

This is not just mitigating the results of the problem, the too high MCR is the problem itself, or part of it, under current market condition.

I believe the right way is to remove the unnecessary penalty to debt position owners.

Anyway, above topics are not what this BSIP focus. this BSIP is just to define a process to decide.

So if you agree that MCR and MSSR are changeable and we need a process to decide the change, I don't think you are against this BSIP.

If you have advanced solution to the smartcoin problems, please draft another BSIP and ask for consensus.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 7, 2019

This is not just mitigating the results of the problem, the too high MCR is the problem itself, or part of it, under current market condition.

Perhaps you are right about that, however I am very skeptical if that is true. I have observed you consistently make various proposals that reduce collateral requirements. I have also observed you have lost much of your own stake due to shorting without adequate collateral. This is your own risk to take, in an effort to maximize your profit. If that is how you wish to invest I have no issue with that, you are free to do so.

However, it is not the safest way to invest and IMO should not be imposed as a rule for all on the platform. That is my opinion, and the voters are free to vote otherwise. If so, it reflects a change to the original design philosophy of the platform which is to provide a platform safe for all, not just aggressive traders.

Reducing collateral requirements on assets as volatile as crypto derivatives is simply unwise, and results in less safety. That is why the 1.75 MCR was established as the norm for bit assets.

I believe the right way is to remove the unnecessary penalty to debt position owners.

"Unnecessary" as you put it is a subjective value judgment. It is also not a penalty, in the same sense I used that word above.

It is unwise to allow collateral to drop too low, which risks gs / black swan for all who trade an asset. Allowing collateral requirements to be reduced increases risk.

The tradeoff is less collateral to maximize profit potential for some, at the risk of trade safety for all.

My hope is that more people regardless of how much or how little they trade will voice their opinion on the underlying principles established for derivatives here, and heed the hard lessons from low collateral and high margins demonstrated in the ever worsening mainstream financial markets.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 8, 2019

1.75 is just a initial value of MCR at the start point, no one can say it is the best value for MCR.

even in the initial design MCR is not a fixed value, witnesses can feed different value based on their judgment, we now just think that stakeholders should decide.

debt and supply are the two sides of the same thing in smartcoin system, surely you can set MCR to 3 or higher to maximize the "safety", but that will make the smartcoin system senseless.

we need a balance.

please let the stakeholders decide, OK?

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 8, 2019

I agree, that MCR is not an absolute, it needs to be managed. However, I have zero confidence it will be managed properly by shareholders collectively or timely. There are too many profit-only seeking shareholders that don't care about the ecosystem, only their own stake. They don't understand or care about the principles that crypto was invented for. Let them go back to mainstream markets if they want high leverage and low collateral.

If we let every decision be made by shareholder whims BitShares will turn to shit, b/c most have no clue about why crypto was invented in the first place.

Each shareholder has total control over their collateral. My objection is they should never be allowed to reduce collateral below 1:1, and those that try to get as close to that as possible, or even want lower, are risking EVERYONE'S stake in the asset. The fact gs occurs at all shows more safety is required.

So no, I am not in favor of turning control of MCR over to shareholders. I am sad to see there are other big stake holders that are willing to allow shareholders to control this parameter. They value mass opinion over the long term safety and reputation of smartcoins. I may be in the minority, but so be it. I stand on principle, not profit or popularity.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 9, 2019

In my view, you under evaluate the logical ability of big proxies and whales.

From the system design perspective, individual user can use leverage freely as they like, and make profit or lose according to the market price change, system designers need to focus on how the system risk is controlled, not the risk of individual users.

Under this logic, the current global settlement logic has big problems, because individual bad debt may lead to black swan of the whole system, that's why BSIP58 is implemented on bitCNY before advanced bad debt handling rule comes out.

We should not encourage or discourage users to borrow at CR=1.75, they borrow means they agree to put the collateral into risk and at worst all the collateral will be lost.

Surely MCR will be above 1, no doubt.

@cogutvalera

This comment has been minimized.

Copy link
Member

@cogutvalera cogutvalera commented Feb 9, 2019

In my view, you under evaluate the logical ability of big proxies and whales.

From the system design perspective, individual user can use leverage freely as they like, and make profit or lose according to the market price change, system designers need to focus on how the system risk is controlled, not the risk of individual users.

Under this logic, the current global settlement logic has big problems, because individual bad debt may lead to black swan of the whole system, that's why BSIP58 is implemented on bitCNY before advanced bad debt handling rule comes out.

We should not encourage or discourage users to borrow at CR=1.75, they borrow means they agree to put the collateral into risk and at worst all the collateral will be lost.

Surely MCR will be above 1, no doubt.

I agree with you that individual bad debt may lead to black swan of the whole system, just wonder why it wasn't thought before much earlier within community and developers. My 2 cents are: individual bad debt should not lead to black swan of the whole system, but maybe just to individual black swan only for that account with bad debt and that's all, simply enough and imho more efficient, maybe I've missed some details and maybe I'm wrong, but I think this is good solution ... let's discuss ...

@cogutvalera

This comment has been minimized.

Copy link
Member

@cogutvalera cogutvalera commented Feb 9, 2019

so accounts with bad debt must be punished by system, but not all accounts must be punished because of 1 account with bad debt, isn't fair enough implemented currently ... just thinking loudly ...

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 9, 2019

In my view, you under evaluate the logical ability of big proxies and whales.

You were once and perhaps still are a "big whale", and look what happened to your stake. So no, I disagree with that statement, and trust my own observations of your actions. You are not alone, I also see other traders that IMO show a pattern of not acting in the best interest of the platform.

From the system design perspective, individual user can use leverage freely as they like, and make profit or lose according to the market price change, system designers need to focus on how the system risk is controlled, not the risk of individual users.

The risk to the individual is also a risk to the collective, as you state below. This too is a principle of life, tho most believe and act in ignorance of this principle, some intentionally. It is an ego trap. The only solution is personal awareness and responsibility, which is sadly lacking in todays world, and I see it increasing with the influx of more mainstream oriented traders and newbies coming into the crypto space that don't value individual financial freedom or want to trade the way they do in crypto markets as they do in corrupt and highly leveraged mainstream markets.

Under this logic, the current global settlement logic has big problems, because individual bad debt may lead to black swan of the whole system, that's why BSIP58 is implemented on bitCNY before advanced bad debt handling rule comes out.

We all agree that the current gs implementation needs refinement, but that is difficult. It won't happen if we don't focus on that but rather on patches and stop gap measures such as this BSIP. I have wavered on this BSIP b/c I initially I saw it as yet another attempt to introduce a method to manipulate prices. Then I relaxed that position when I thought the GSP was a fixed price for all witnesses and would be easy to verify when witnesses switched in or out of GSP. Now I see that isn't the case, and it would be difficult to determine if a particular witness is publishing the correct GSP after GS, as the GSP price is dynamic. This opens a vulnerability to price manipulation that may have subtle and undetermined ramifications. I don't want to see a repeat of the chaos and lack of consensus we saw under BSIP42.

We should not encourage or discourage users to borrow at CR=1.75, they borrow means they agree to put the collateral into risk and at worst all the collateral will be lost.

There is a reason designers set CR to 1.75 and why no consensus to change it has occurred among witnesses. In earlier times it was even higher. It keeps dropping due to pressure from traders that don't want to tie up (or risk as you put it) any more capital than they have to. Some have learned they can allow their collateral to go as low as they want, as there is nothing to stop them or penalize them from doing so. I'm actually a bit surprised that the witnesses favorable to collateral reduction have not reduced their MCR more than it has been.

Surely MCR will be above 1, no doubt.

Again, you can't know that. If left up to shareholders and bsip authors who suggest the changes for them to vote on, it could go quite low under the guise of stimulating liquidity but may in fact be a manipulation by whales that want to maximize their profit and defer their risk to the collective.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 10, 2019

You were once and perhaps still are a "big whale", and look what happened to your stake. So no, I disagree with that statement, and trust my own observations of your actions. You are not alone, I also see other traders that IMO show a pattern of not acting in the best interest of the platform.

I lost a lot in the bear market, but how then? traders always experience success and failure, you just judge one person based on success/failure?

The risk to the individual is also a risk to the collective, as you state below. This too is a principle of life, tho most believe and act in ignorance of this principle, some intentionally. It is an ego trap. The only solution is personal awareness and responsibility, which is sadly lacking in todays world, and I see it increasing with the influx of more mainstream oriented traders and newbies coming into the crypto space that don't value individual financial freedom or want to trade the way they do in crypto markets as they do in corrupt and highly leveraged mainstream markets.

No, gambler's risk and gambling house's risk are two different things.

We all agree that the current gs implementation needs refinement, but that is difficult. It won't happen if we don't focus on that but rather on patches and stop gap measures such as this BSIP. I have wavered on this BSIP b/c I initially I saw it as yet another attempt to introduce a method to manipulate prices. Then I relaxed that position when I thought the GSP was a fixed price for all witnesses and would be easy to verify when witnesses switched in or out of GSP. Now I see that isn't the case, and it would be difficult to determine if a particular witness is publishing the correct GSP after GS, as the GSP price is dynamic. This opens a vulnerability to price manipulation that may have subtle and undetermined ramifications. I don't want to see a repeat of the chaos and lack of consensus we saw under BSIP42.

I mentioned GS just to tell "we need to continually refine the rules", this BSIP is not relevant to GS.
BSIP42 has problems and has been abandoned by the community, however, I don't what to see what we learned from BSIP42 is "we should just stay here and deny any change".

There is a reason designers set CR to 1.75 and why no consensus to change it has occurred among witnesses. In earlier times it was even higher. It keeps dropping due to pressure from traders that don't want to tie up (or risk as you put it) any more capital than they have to. Some have learned they can allow their collateral to go as low as they want, as there is nothing to stop them or penalize them from doing so. I'm actually a bit surprised that the witnesses favorable to collateral reduction have not reduced their MCR more than it has been.

IIRC, MCR is set to 1.75 from BTS2.0 without any change.

although technically witnesses can feed MSSR and MCR according to their will, now it is supposed that witnesses should follow the consensus from stakeholders to feed these parameters, several months ago, one witness has switched to feed MSSR=1.05 while others still stick on 1.1, then he is instantly voted out by a big proxy.

there is one specific BSIP-BSIP44, which is drafted specially for changing bitCNY MSSR from 1.1 to 1.05. surely we need not to draft one BSIP for every change, that's why we need this BSIP - to define a general process to reach consensus on MSSR and MCR values.

Again, you can't know that. If left up to shareholders and bsip authors who suggest the changes for them to vote on, it could go quite low under the guise of stimulating liquidity but may in fact be a manipulation by whales that want to maximize their profit and defer their risk to the collective.

that's your imagination, I haven't heard from any big proxy/whales that he support to reduce MCR to under 1.

no one can define exactly what a number is "quite low" for MCR, in my view, 1.5 is acceptable and 1.2 may be quite low, maybe in your view 1.5 is already "quite low", neither of us can/should decide separately, the conclusion should come from the stakeholders as a collective.

you can state your opinion clearly as a KOL while each change is suggested and is on vote, you can lobby the voters to follow your selection. but you should not oppose to define a process to reach consensus. which is a basic process in the governance of a DPoS system.

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 11, 2019

@bitcrab Here are a couple of typos to fix

has been changed to 1.05 for bitCNY through BSIP44.

I think that this is a typo and that you intended to refer to BSIP-41

Poll-BSIP**-Ruduce MSSR to 1.02 on bitCNY

Typo: Poll-BSIP**-Reduce MSSR to 1.02 on bitCNY

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 11, 2019

2.bitCNY discount < force settlement offset & bitCNY premium < (MSSR-1)

Maybe a definition of discount and premium and what the asset is measured against (e.g. the CNY-price of bitCNY (PbitCNY/CNY)) would be helpful please.

If I am understanding it correctly, is this the definition?

Ratio = (PbitCNY/CNY - 1 CNY) ÷ (1 CNY)

And when this ratio is positive it is called a "premium", and when the ratio is negative it is called a "discount"?

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 11, 2019

@bitcrab There is ambiguity about when this BSIP applies and when it does not apply. For ease of discussion, I will call this proposal BSIP-X.

When does it apply?

  • For it to apply, should both BSIP and a Yes Poll-BSIP be elected?

  • For it to apply, should only the Yes Poll-BSIP be elected?

    • Suggestion: Maybe the Yes poll-BSIP could be "Poll-BSIP**-Reduce MSSR to 1.02 on bitCNY per BSIP-X"

When does it not apply?

  • Does this BSIP expire? Or if voted in once, does this BSIP apply forever?

  • Should witnesses pay attention to a Poll-BSIP proposed by anyone?

  • What should happen if both a Yes and No Poll-BSIP are unelected?

    • Suggestion: Maybe the witnesses should choose the value
  • What should happen if two Yes Poll-BSIPs are elected (e.g. "Yes to MCR of 1.01" and "Yes to MSSR of 1.05")?

    • Suggestion: Maybe the Poll-BSIP with more votes should apply
  • What should happen if both a Yes and No Poll-BSIP are elected?

    • Suggestion: Maybe the Poll-BSIP with more votes should apply
  • What should happen if a No Poll-BSIP is higher than all the other Yes Poll-BSIPs (e.g. "No Reduce MSSR to 1.02 on bitCNY" and "Yes to MSSR of 1.03 on bitCNY" and "Yes to MSSR of 1.05 on bitCNY")?

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 11, 2019

How important is the Rationale?

  • Is the Rationale critical to the application of this voting process, or is it just a suggestion for how and when the voting BSIP-polls might be proposed?
@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 12, 2019

thanks @MichelSantos, has updated the draft.

When does it apply?

  • For it to apply, should both BSIP and a Yes Poll-BSIP be elected?
  • For it to apply, should only the Yes Poll-BSIP be elected?

If the Yes Poll-BSIP is elected and get more votes than the No Poll-BSIP, it should be applied.

When does it not apply?

  • Does this BSIP expire? Or if voted in once, does this BSIP apply forever?

The BSIP define a process to make change, it does not expire, however, it is possible that the parameters be updated by new poll worker proposals.

For example, now MSSR has been changed to 1.05 for bitCNY, it will keep this value even after the poll worker expire, to change it back to 1.1, a new poll worker is needed and get enough votes.

  • Should witnesses pay attention to a Poll-BSIP proposed by anyone?

I suggest that only committee member can propose such poll workers to avoid spam worker proposals.

But as you know, Bitshares is a DPoS based blockchain and this BSIP is a tool to reach consensus, every user can create poll worker, so if an "anyone" created a poll worker and finally get enough votes to make change, committee and witnesses should not ignore, they should respond based on the DPoS logic.

  • What should happen if both a Yes and No Poll-BSIP are unelected?

Then there will be no change.

  • What should happen if two Yes Poll-BSIPs are elected (e.g. "Yes to MCR of 1.01" and "Yes to MSSR of 1.05")?
  • What should happen if both a Yes and No Poll-BSIP are elected?
  • What should happen if a No Poll-BSIP is higher than all the other Yes Poll-BSIPs (e.g. "No Reduce MSSR to 1.02 on bitCNY" and "Yes to MSSR of 1.03 on bitCNY" and "Yes to MSSR of 1.05 on bitCNY")?

if more than one poll worker proposals are elected, the one with most votes will be effective, either it is a Yes or No poll BSIP, if the No poll BSIP get most votes, then there will be no change.

the Rationale is to explain why we need this BSIP and how it works.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 12, 2019

The questions MichelSantos asked are very good.

@bitcrab, would you be so kind to answer each one to eliminate possible confusion, as you responded to me?

Thank you.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 13, 2019

@ThomasFreedman please check the updated comment above, Thanks.

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 13, 2019

we suppose that vote to support "Poll-BSIP**-Reduce MSSR to 1.02" also support BSIP** and vote to support "Poll-BSIP**-No Reduce MSSR to 1.02 on bitCNY" either oppose that reduction or oppose BSIP** itself.
so no need to set a poll voting specially for BSIP** itself.

@bitcrab That clarification helps

this BSIP define a process to make change, so if one WP expire, it does not mean the change expire, the parameter will stay without change when the WP expire, if necessary, a new poll voting can be issued for a new change.

In that case I do think that it is worthwhile for the BSIP to describe this: a "Yes vote" that is elected does not expire until another "Yes vote" cancels the effect of the preceding "Yes vote".

In my opinion there should also be a way for the voting to "sunset".

One possibility is to use an expiration for the WP poll. But I understand that is not your preferred option.

Another possibility is to have an optional third voting choice to delegate the settings back to witness choice: "Poll-BSIP** Delegate the selection of MSSR on bitCNY to each witness".

the Rationale is to explain why we need this BSIP and how it works.

The Rationale is certainly valuable. I submit that although this voting mechanism might be used towards the strategy that is described in the Rationale, the mechanism also permits anyone to propose settings that are motivated by a different strategy.

@MichelSantos

This comment has been minimized.

Copy link
Contributor

@MichelSantos MichelSantos commented Feb 13, 2019

@bitcrab, The potential risks that you have already described are valid and valuable in my opinion. Please consider the addition of the text below in the Risks section, either as is or in some modified form.

I have not written much about the specific Rationale described because my impression is that the BSIP is more about the process, which is described in the Specifications, than it is about the setting of specific values. I think that an analysis of specific MSSR and MCR values merits a separate document and discussion.

Comparison to Current Publishing of MSSR and MCR

The values of MSSR and MCR for any smart asset issued by the BitShares Committee (i.e. bitAssets) are published by elected witnesses and then used by the blockchain to calculate the median value of the MSSR and MCR settings. This mechanism will not be changed by this proposal.

The witnesses are elected by BTS token holders. This mechanism will not be changed by this proposal.

Therefore BTS token holders have always had indirect influence on these bitAssets settings through their delegation to witnesses. If a witness published a setting that was considered undesirable by certain BTS token holders then those holders could and sometimes did withdraw their vote for that witness. This mechanism will not be changed by this proposal.

This proposal establishes a formal process for BTS token holders to convey their desires to the witnesses. If this formal process is approved by BTS token holders then any specific parameter changes that are elected by a poll (e.g. "Reduce MSSR to 1.03 for bitCNY") will be expected to be published by witnesses.

Values of MSSR and MCR Settings

Although the values for MSSR and MCR could be selected to comply with the description in the Rationale, there is no way to guarantee that they will comply because anyone can publish a poll with settings motivated by any rationale. Voters will need to evaluate each setting that is proposed in a BSIP poll.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 13, 2019

I very much like the suggestions, and believe Michel's ideas are good additions to the bsip.

Thank you @bitcrab and @MichelSantos.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 14, 2019

thanks @MichelSantos, I adopt some of your suggestion and add them into the BSIP after modification.

I don't think we need to waste time on concepts like "sunset" here.

MSSR, MCR are key parameters, they should be stable, each time we need change them we should be very careful. when one change is finished, it should be stable, when new change is necessary, we should go the same process to get consensus from stake holders and announce the changes to public. "return to old value" is also such a change, nothing specific.

and history shows that it's not good to just let the witnesses to publish MCR/MSSR on their will, they should follow the consensus from stake holders.

from system design perspective, maybe it's better to set MCR and MSSR as committee controlled parameters, not witnesses published parameters, values like price that changes every minute should be published by witnesses. but this is not this BSIP concern. this BSIP just try to introduce a process to optimize the system under current infrastructure.

@ThomasFreedman

This comment has been minimized.

Copy link

@ThomasFreedman ThomasFreedman commented Feb 14, 2019

The concept of sunset is essentially to "compartmentalize" or isolate which change of parameters the activate/deactivate vote applies to. In USA law for example there are literally 1000s of laws still active which are not only obsolete, but also complicate which understanding of law should be applied.

The concept of sunset is simple, and provides an explicit rather than implicit limitation on the applicability of the activate/deactivate vote. It just provides a safeguard to eliminate potential ambiguity on what witnesses should do, when the activate/deactivate votes change.

No condition for a particular MSSR/MCR will exist forever, and consensus on what may or may not be required changes, so rather than allow a previous parameter setting persist (potentially longer than it should), it makes sense for the understanding of consensus to be renewed and consensus on parameter value be explicitly tied to a given vote result.

IMO no effort to clarify or be precise is wasted effort.

@bitcrab

This comment has been minimized.

Copy link
Contributor Author

@bitcrab bitcrab commented Feb 14, 2019

as I know, the sunset clause is used in clarifying how a new created institution/project will persist/be withdrew after expiration.

but I don't think we need it in this BSIP, here the rule is clear:

MSSR or MCR should not be changed, until stake holder reach a consensus to do a change through poll voting worker proposals.

similar to the committee controlled parameters like force settlement offset, each time committee changed it, the updated value will persist until committee change it the next time.

I don't think we need to set a period to timely review the MSSR/MCR value, anytime a poll can be created for updating consensus if necessary.

@pmconrad

This comment has been minimized.

Copy link
Contributor

@pmconrad pmconrad commented Feb 15, 2019

PR: #145

@bitcrab bitcrab changed the title New BSIP: Adjustment of MSSR and MCR through voting BSIP59: Adjustment of MSSR and MCR through voting Feb 17, 2019
@bangzi1001

This comment has been minimized.

Copy link

@bangzi1001 bangzi1001 commented Mar 9, 2019

thanks @MichelSantos, I adopt some of your suggestion and add them into the BSIP after modification.

I don't think we need to waste time on concepts like "sunset" here.

MSSR, MCR are key parameters, they should be stable, each time we need change them we should be very careful. when one change is finished, it should be stable, when new change is necessary, we should go the same process to get consensus from stake holders and announce the changes to public. "return to old value" is also such a change, nothing specific.

and history shows that it's not good to just let the witnesses to publish MCR/MSSR on their will, they should follow the consensus from stake holders.

from system design perspective, maybe it's better to set MCR and MSSR as committee controlled parameters, not witnesses published parameters, values like price that changes every minute should be published by witnesses. but this is not this BSIP concern. this BSIP just try to introduce a process to optimize the system under current infrastructure.

New BSIP: MCR & MSSR Should Set By Asset Owner rather than Price Feed Publisher
#96

@pmconrad

This comment has been minimized.

Copy link
Contributor

@pmconrad pmconrad commented Mar 10, 2019

BSIP has been merged in #145. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
8 participants
You can’t perform that action at this time.