BSIP71 - Change Request: Incorporate core changes necessary for BSIP-0076 to allow a threshhold price #224
Conversation
ryanRfox
changed the title
|
Updated wording. Now looks good to me. |
|
Yes. Looks good to me. Thank you @sschiessl-bcp for updating this BSIP. I've requested @pmconrad or @MichelSantos to provide the final review as they contributed on the previously merged BSIP71. |
|
I will not support such a protocol change, not even with a review. |
|
The realization of this BSIP allows debt holders to massively increase voting power, artifically in my opinion. This might hinder progress in the future, or give incentive to drive progress into one single direction (to accomodate margin position holders). Thinking more about this I think it is a necessary, simple and justifiable addition to this BSIP is that the voting power of a margin position is reduced, and only the voting power of the excess BTS count towards the margin position holders. Then we have one question to discuss: Should we do anything with the "lost voting power", or simply have it lost? Example: Margin position with CR 1.6. The voting power of this margin position is reduced by a BTS amount equivalent of CR 1. Thoughts? |
|
This BSIP allows EVERYONE to increase their voting power not just existing debt holders |
|
It's essentially a negotiation between smartcoin holders and smartcoin creators (aka borrowers or debt position holders). Let's score the options on the desk. Assuming the option that gives the smartcoin holders the most benefits has a score of Here are my scores for the options:
People are taking sides. |
That is correct. It assumes that all BTS holders are risk lovers and want to participate like that. |
|
What do we want to do with BSIP71 at this time?
|
What if we give the option to bitASSETs holders to give the "lost" voting power (or even generate more voting power!) back to margin position holders by activating a yearly interest rate of 1% (or more) to bitASSETs owners that get's paid straight from the margin position holders pockets + partially from a worker if absolutely necessary? |
There was a problem hiding this comment.
Three risks should be added
First, the abstract states that "this BSIP allows the asset owner to define an optional threshold price to prevent external market manipulation." The obvious risk is that the asset owner may actually use any justification for setting the threshold.
Second, the holder's fundamental ability to redeem the asset at a market price through force settlement is potentially being changed after the fact by the asset holder if the new threshold price is set.
Third, this effectively transforms the asset issuer into a currency board that can effectively suspend redemption claims. This may potentially be a conflict of interest if the issuer is also borrowing the asset into existence.
|
@sschiessl-bcp Please also change "%div;" to "÷" |
|
i adressed all comments.
|
|
I'd like to hear some more opinions. Option a) Option b) |
That's the whole point. Including it in the BSIP forces the affected parties to compromise. |
You're misleading. The main point is not whether to put them into one BSIP, but whether to have the voting power change in the BSIP.
Why to force? |
because as you said...it would never get voted on its own. When its in one BSIP it's give and take |
creator |
Yes |
There was a problem hiding this comment.
I think it's better to create a new BSIP for this feature rather than adding it to BSIP71. Some voters may want the GSP feature but not this one, some others may want this but not the GSP feature.
agree, actually I feel maybe it's too early to add the feed price threshold feature to core code level, I believe we need the feed price threshold feature but we still need to see the impact it bring to the smartcoin system, so it's not bad to let it stay at witness level some longer period, and push it to core code level when we learn enough about it and reach stronger consensus, as GS protection has experienced.
| #### Adjustment to voting power | ||
|
|
||
| The voting power for BTS backed SmartCoins added to the owner of a margin position is reduced. Only the exccess collateral counts as voting power. Example: If a position has CR 1.8, the voting power from this position only counts the BTS that represent the excess of 0.8. Reasoning for this is given in the section Discussion / Voting power. | ||
|
|
There was a problem hiding this comment.
I totally disagree with the adjustment to voting power, voting power is inside BTS, one should own the voting power of the BTS in his account, either his account is debt free or not, debt just means he would like to bear the relevant risk, no others.
There was a problem hiding this comment.
The core development team's main responsibility is to make sure that the system code runs safely and reliably,and add new feature into system which shall has no negative impact on the original business logic or function . however,for a system like bts running for many years, voting rights adjustments obviously beyond the duty of the development team. The development team is not authorized to modify voting power or discuss how to change such power of bts holder.
|
it is a important reminder for everyone on the core team that you are not authorized to infringe the voting rights of the bts holder. voting power is also property arrribute attached to bts coin, that is,you are not allowed to infringe the property of bts holders. if the voting right adjustment is approved, the call for a vote of no-confidence in the core team is possible. |
|
"which shall has no negative impact on the original business logic or function" So no changing the original business logic? Stop making silly arguments only when it suits you |
|
After price recovery, I no longer support gs, bsip76. without bitcny, I couldn't find any reason to support it. |
We developers know that. We do not change consensus without following proper procedures, i. e. creating a BSIP and have it approved by shareholders. Unlike others.
We are also shareholders, and as such we are of course authorized to discuss changes.
You guys had no problems with infringing the property of bitCNY/bitUSD holders when you approved BSIP-76, and now you are complaining that others are discussing the same? |
|
Related or not related to this topic, this was posted in Telegram just now.
Like Peter said, this is a discussion thread. Any and all changes will need to pass voting first. |
|
|
||
| - traders could no longer borrow bitUSD; | ||
| - the price of bitUSD dropped below USD because of insufficient collateral; and, | ||
| - it will take a long time for bitUSD to be revived. | ||
|
|
||
| The community has had extensive discussions about how to handle the bad debt in a better way in the future. However an easy way, [BSIP58](https://github.com/bitshares/bsips/blob/master/bsip-0058.md), has been implemented for smartcoins like bitCNY and bitUSD; it has worked successfully to prevent GS from happening with no other obvious impact. However, BSIP58 has some issues - it is suspected of market manipulation and it risks witnesses independence. Moving forward, this BSIP will be built based on BSIP58 and eliminate all its disadvantages. | ||
| The community has had extensive discussions about how to handle the bad debt in a better way in the future. |
There was a problem hiding this comment.
That doesn't sound like a bad consequence of global settlement.
| @@ -39,9 +60,12 @@ We now have several choices on handling bad debt: | |||
|
|
|||
| We need to do a deep review on bad debt before evaluating above solutions. | |||
There was a problem hiding this comment.
When can we expect this deep review on bad debt? Why can't we work on improving the price feed scripts in parallel?
There was a problem hiding this comment.
Don't know. Certainly we can, care to join?
|
|
||
| At this moment, the system should accept the fact that the smartcoin will possibly devalue, find ways to minimize the impact to different parties in the market and the time to revive. | ||
| At this moment, the system should accept the fact that the smartcoin will possibly devalue, |
There was a problem hiding this comment.
It's not just a possibility, but now a fact that the CNY & USD assets have been devalued by BSIP 76.
bsip-0071.md
Outdated
| if flag "Prevent Global Settlement" is enabled | ||
| settlement price = max(FP_M * (1 - settlement_offset), P_gs) | ||
| call execution price = max(FP_M * (1 + MSSR), P_gs) | ||
| if flag "Prevent Global Settlement and External Attacks" is enabled |
There was a problem hiding this comment.
Add flags "Prevent Global Settlement"
flag "Prevent Global Settlement and External Attacks"
Which is the final name for the flag?
| Variant B would have let bad debt positions matched at their own collateral ratio while matching other margin calls as before at FP<sub>M</sub> × MSSR, hoping to improve the overall collateralization. This also means that debt positions with better collateral ratio would have been preferred over bad debt, meaning that bad debt positions will remain sitting on the market for a longer time. | ||
| - If the Threshhold is set, conflict of interest exists if the asset owner is also borrowing the asset into existence | ||
|
|
||
| - If the Threshhold price is set, margin positions creators essentially have a call price limit that they can set in order to avoid ever being margin called. This means the position carries no risk for the margin position holder anymore, which can be seen as incentive to borrow as much as possible without considering the consequences. This is the reason to adjust the voting weight of a BitAsset position | ||
|
|
||
| # Summary for Shareholders |
There was a problem hiding this comment.
impact on smartcoin, debt & bts holders?
|
Fixed the calculation wording when flags are set, so at least the idea is correctly presented. |
To accomodate #221 from core side in #179
Premise is that independent how you stand towards the ongoing feed price alterations, we need to allow witnesses to feed outside market price while still being able to affect margin calls and force settlements in the desired way.