bsips icon indicating copy to clipboard operation
bsips copied to clipboard

BSIP71 - Change Request: Incorporate core changes necessary for BSIP-0076 to allow a threshhold price

Open sschiessl-bcp opened this issue 5 years ago • 28 comments

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.

sschiessl-bcp avatar Sep 30 '19 08:09 sschiessl-bcp

Updated wording. Now looks good to me.

abitmore avatar Sep 30 '19 19:09 abitmore

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.

ryanRfox avatar Sep 30 '19 20:09 ryanRfox

I will not support such a protocol change, not even with a review.

pmconrad avatar Oct 01 '19 14:10 pmconrad

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?

sschiessl-bcp avatar Oct 02 '19 07:10 sschiessl-bcp

IMHO the logic around voting (or weight) is in the scope of BSIP24 and #83, but not this BSIP.

abitmore avatar Oct 02 '19 12:10 abitmore

This BSIP allows EVERYONE to increase their voting power not just existing debt holders

thul3 avatar Oct 02 '19 12:10 thul3

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 1, the option that gives the smartcoin creators the most benefits has a score of 5.

Here are my scores for the options:

  • the old GS rule, score 3.
  • the already-merged draft of BSIP71 favors smartcoin holders over creators, but still shows some merit for the creators e.g. the "fill the least collateralized call order first" rule, score 2;
  • in the discussion when drafting BSIP71 (#193), some people came up with ideas that favors smartcoin holder more (IMHO), e.g. "always settle at feed price" and "filling as much margin-called debt as possible", score 1;
  • the "price threshold" rule discussed in this issue and BSIP76 favors smartcoin creators over smartcoin holders under certain circumstances, score 4.

People are taking sides.

abitmore avatar Oct 02 '19 13:10 abitmore

This BSIP allows EVERYONE to increase their voting power not just existing debt holders

That is correct. It assumes that all BTS holders are risk lovers and want to participate like that.

sschiessl-bcp avatar Oct 02 '19 13:10 sschiessl-bcp

IMHO the logic around voting (or weight) is in the scope of BSIP24 and #83, but not this BSIP.

Also correct. This BSIP allows debt holders to margin to the max risk-free, while significantly and overwhelmingly increasing their voting power. That is why I see it relevant in here.

sschiessl-bcp avatar Oct 02 '19 13:10 sschiessl-bcp

What do we want to do with BSIP71 at this time?

  • Vote on the merged BSIP71 draft
  • Continue discussions on this Change Request

ryanRfox avatar Oct 02 '19 15:10 ryanRfox

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?

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?

liondani avatar Oct 02 '19 23:10 liondani

@sschiessl-bcp Please also change "%div;" to "÷"

MichelSantos avatar Oct 04 '19 00:10 MichelSantos

i adressed all comments.

  • now two flags, one for threshold one for prevent GS
  • added voting reduction

sschiessl-bcp avatar Oct 04 '19 08:10 sschiessl-bcp

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.

abitmore avatar Oct 07 '19 12:10 abitmore

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.

In a perfect world, yes. And that is the point. Surely you can say, this is what the voters want. I say the voting power distribution is already heavily skewed (was already in the past, simply not so much apparent to me), and I am trying to present reasonable compromises. If given the choice, I don't believe that voting power correction for margin positions will ever make it.

sschiessl-bcp avatar Oct 07 '19 14:10 sschiessl-bcp

If given the choice, I don't believe that voting power correction for margin positions will ever make it.

I believe it won't pass the voting, so why we waste time/efforts/funds including it in the BSIP? Having it in the BSIP means other features in the BSIP won't pass as well.

abitmore avatar Oct 07 '19 14:10 abitmore

I'd like to hear some more opinions.

Option a) Put it up in one BSIP

Option b) Put threshold as one, and margin position correction as another. Both would need to be available for voting at the same time.

sschiessl-bcp avatar Oct 08 '19 06:10 sschiessl-bcp

If given the choice, I don't believe that voting power correction for margin positions will ever make it.

I believe it won't pass the voting, so why we waste time/efforts/funds including it in the BSIP? Having it in the BSIP means other features in the BSIP won't pass as well.

That's the whole point. Including it in the BSIP forces the affected parties to compromise.

clockworkgr avatar Oct 08 '19 07:10 clockworkgr

I'd like to hear some more opinions.

Option a) Put it up in one BSIP

Option b) Put threshold as one, and margin position correction as another. Both would need to be available for voting at the same time.

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.

Including it in the BSIP forces the affected parties to compromise.

Why to force?

abitmore avatar Oct 08 '19 12:10 abitmore

I'd like to hear some more opinions. Option a) Put it up in one BSIP Option b) Put threshold as one, and margin position correction as another. Both would need to be available for voting at the same time.

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.

Including it in the BSIP forces the affected parties to compromise.

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

clockworkgr avatar Oct 08 '19 12:10 clockworkgr

从本质上讲,这是Smartcoin持有者与Smartcoin创造者(又名借款人或债务头寸持有者)之间的谈判。

让我们在桌子上打分。假定为smartcoin持有者带来最大收益1的期权得分为,则为smartcoin创造者带来最大收益的期权得分为5

这是我的选项得分:

  • 旧的GS规则,得分3
  • 已经合并的BSIP71草案更偏向于Smartcoin持有者,而不是创建者,但仍对创建者显示出一些好处,例如“先填写最低抵押呼叫顺序”规则,得分2
  • 在讨论中,在起草BSIP71(#193)时,有人提出了更偏爱智能币持有人(IMHO)的想法,例如“总是以进料价格结算”和“尽可能多地填补所谓的保证金债务” 1
  • 在某些情况下,本期讨论的“价格门槛”规则和BSIP76会优先考虑smartcoin的创建者而不是smartcoin的持有者4

人们站在一边。

creator

Yamtt avatar Oct 08 '19 15:10 Yamtt

应该增加三个风险

首先,摘要指出:“该BSIP允许资产所有者定义可选的阈值价格,以防止外部市场操纵。” 明显的风险是资产所有者可能实际上会使用任何理由来设置阈值。

其次,如果设定了新的阈值价格,资产持有人_在事后_可能会改变持有人通过强制结算以市场价格赎回资产的基本能力。

第三,这有效地将资产发行人转变为可以有效暂停赎回要求的货币发行局。如果发行人也在借入资产,则可能存在利益冲突。

Yes

bitProfessor avatar Oct 08 '19 15:10 bitProfessor

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.

tonyniu352 avatar Oct 09 '19 03:10 tonyniu352

"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

clockworkgr avatar Oct 09 '19 05:10 clockworkgr

After price recovery, I no longer support gs, bsip76. without bitcny, I couldn't find any reason to support it.

bitProfessor avatar Oct 09 '19 05:10 bitProfessor

The development team is not authorized to modify voting power

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.

or discuss how to change such power of bts holder.

We are also shareholders, and as such we are of course authorized to discuss changes.

you are not allowed to infringe the property of bts holders

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?

pmconrad avatar Oct 09 '19 06:10 pmconrad

Related or not related to this topic, this was posted in Telegram just now.

cn-vote, [09.10.19 12:39] I want to remind the current core development team. Cn-vote has always supported the core development team, please do not live up to everyone's expectations. The core development team should not forget what they are and what they should do. Do your own job, because there are already many excellent and cheaper teams who have repeatedly sought to compete for the core team.

cn-vote, [09.10.19 12:44] BM left, and the bitshares have been running steadily for so many years. Therefore, no one is indispensable. Don't forget who you are and what you should do. Do your job well and everyone will always support you. Otherwise, there will be more suitable teams and people. Thank you all. A job like this high salary and not so busy can be difficult to find. Many excellent teams have been coveted for a long time.

Like Peter said, this is a discussion thread. Any and all changes will need to pass voting first.

sschiessl-bcp avatar Oct 09 '19 11:10 sschiessl-bcp

Fixed the calculation wording when flags are set, so at least the idea is correctly presented.

sschiessl-bcp avatar Oct 14 '19 06:10 sschiessl-bcp