[Poll] BSIP42: adjust price feed dynamically

[abit]

However, even when it's able to adjust MCR, the code doesn't allow us to adjust it to less than 100%. That means black swan is unavoidable by adjusting MCR alone when time comes.

So you admit now that BSIP42 is massivly increasing the danger of getting a global settlement ?

No.

[Thul3]

However, even when it's able to adjust MCR, the code doesn't allow us to adjust it to less than 100%. That means black swan is unavoidable by adjusting MCR alone when time comes.

So you admit now that BSIP42 is massivly increasing the danger of getting a global settlement ?

[abit]

@abit I'm walking around here on Bitfest and we've been discussing the BSIP42. If we are looking into updating the software with a future hardfork or major release, irregardless of whether to continue the BSIP 42 or it might get voted out we could move and seperate the "pricefeed"-data and the "premium" (modifier) data into a new variable set by witnesses publishing this 'modifier/premium'.

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

1. This would mean that witnesses can continue to publish pricefeeds according to the old "market reflecting" data as sampled from all sources.
2. The pricefeed data reflects "true" reflection of the market and can continue to be used as trusted source for input for other projects whatever they may be.
3. Then inside the new software version code the final price to be calculated could be as simple as "pricefeed median * 'modifier median".

- If BSIP42 gets voted out it could be as simple as everyone publishing a "1.0"-value as "modifier".
- If BSIP42 stays active it is way easier to see witnesses' premiums/modifiers and the pricefeeds can stay usefull for other projects beyond and inside the Bitshares realm.

actually I think one other solution may be better: keep feed price as the "real market price" as before, and let witnesses adjust MCR based on the premium/discount get from market. this will give same impact to the the market as BSIP42 and can lead to pegging accuracy.

this need not to add more variables, but need to overcome some technical problem/fix some bugs as @abit has mentioned.

however I think either solution need a long time(several months?) to fix bugs or even do hard fork,  I don't think we should just wait for the solution come, we can just push BSIP42 at current time to make smartcoins better, until the "transparent" solution come.

Yes indeed changing the MCR would be the best solution, but if it would be technically unfeasible or to much demanding for the chain the suggested solution might at least be a good alternative i think, especially since I think that it might be easier to integrate with the current software instead of changing much to the Smart Assets code.

The bug about changing MCR is being fixed. Actually the code is ready, but need testing. https://github.com/bitshares/bitshares-core/pull/1324

However, even when it's able to adjust MCR, the code doesn't allow us to adjust it to less than 100%. That means black swan is unavoidable by adjusting MCR alone when time comes.

By adjusting price, theoretically black swan event is avoidable. More discussion in this post https://bitsharestalk.org/index.php?topic=27170.msg322381#msg322381 .


@roelandp: I don't like the change you proposed because it is not a simple change if want to make it into consensus, to implement it we need to change quite some code, but the gain is little.
* If someone wants to feed something not for the system to use, he can use custom_operation.
* If someone want to track price, he can use latest market trading price.

[roelandp]

@abit I'm walking around here on Bitfest and we've been discussing the BSIP42. If we are looking into updating the software with a future hardfork or major release, irregardless of whether to continue the BSIP 42 or it might get voted out we could move and seperate the "pricefeed"-data and the "premium" (modifier) data into a new variable set by witnesses publishing this 'modifier/premium'.

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

1. This would mean that witnesses can continue to publish pricefeeds according to the old "market reflecting" data as sampled from all sources.
2. The pricefeed data reflects "true" reflection of the market and can continue to be used as trusted source for input for other projects whatever they may be.
3. Then inside the new software version code the final price to be calculated could be as simple as "pricefeed median * 'modifier median".

- If BSIP42 gets voted out it could be as simple as everyone publishing a "1.0"-value as "modifier".
- If BSIP42 stays active it is way easier to see witnesses' premiums/modifiers and the pricefeeds can stay usefull for other projects beyond and inside the Bitshares realm.

actually I think one other solution may be better: keep feed price as the "real market price" as before, and let witnesses adjust MCR based on the premium/discount get from market. this will give same impact to the the market as BSIP42 and can lead to pegging accuracy.

this need not to add more variables, but need to overcome some technical problem/fix some bugs as @abit has mentioned.

however I think either solution need a long time(several months?) to fix bugs or even do hard fork,  I don't think we should just wait for the solution come, we can just push BSIP42 at current time to make smartcoins better, until the "transparent" solution come.

Yes indeed changing the MCR would be the best solution, but if it would be technically unfeasible or to much demanding for the chain the suggested solution might at least be a good alternative i think, especially since I think that it might be easier to integrate with the current software instead of changing much to the Smart Assets code.

[bitcrab]

@abit I'm walking around here on Bitfest and we've been discussing the BSIP42. If we are looking into updating the software with a future hardfork or major release, irregardless of whether to continue the BSIP 42 or it might get voted out we could move and seperate the "pricefeed"-data and the "premium" (modifier) data into a new variable set by witnesses publishing this 'modifier/premium'.

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

1. This would mean that witnesses can continue to publish pricefeeds according to the old "market reflecting" data as sampled from all sources.
2. The pricefeed data reflects "true" reflection of the market and can continue to be used as trusted source for input for other projects whatever they may be.
3. Then inside the new software version code the final price to be calculated could be as simple as "pricefeed median * 'modifier median".

- If BSIP42 gets voted out it could be as simple as everyone publishing a "1.0"-value as "modifier".
- If BSIP42 stays active it is way easier to see witnesses' premiums/modifiers and the pricefeeds can stay usefull for other projects beyond and inside the Bitshares realm.

actually I think one other solution may be better: keep feed price as the "real market price" as before, and let witnesses adjust MCR based on the premium/discount get from market. this will give same impact to the the market as BSIP42 and can lead to pegging accuracy.

this need not to add more variables, but need to overcome some technical problem/fix some bugs as @abit has mentioned.

however I think either solution need a long time(several months?) to fix bugs or even do hard fork,  I don't think we should just wait for the solution come, we can just push BSIP42 at current time to make smartcoins better, until the "transparent" solution come.

[pc]

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

[j.galt]

Your proposal is far better for the community and for transparency RoelandP.

The "fast track" of bsip42 and now seeing signs of push for BitUSD for a similar scheme indicates there is an agenda at play here which goes beyond simply wanting a tighter peg. Although I haven't seen much, it has been mentioned to eliminate the global settlement price, so Thul3's comments about that may right.

Are we witnessing the "controlled demolition" of this ecosystem? When major shareholders propose price feed manipulation (i.e. bsip42) and other proxies and the committee don't jump in to stop it or at least demand a more careful plan to conduct testing, I have to ask.

Making adjustments to increase a derivative's peg "tightness" is one thing, removing global settlement is another.

BTW, when will this bsip42 experiment be over? When will we see a report or something written up about this? When will we have seen enough variations in the market to know the PID parameters are optimized for all market conditions?

Or, are witnesses endlessly supposed to keep making adjustments to the PID settings? That's hardly an improved feed algorithm.

I sure hope bsip42 is heavily discussed at Bitfest and a solid plan is considered to prevent a catastrophe.

[roelandp]

@abit I'm walking around here on Bitfest and we've been discussing the BSIP42. If we are looking into updating the software with a future hardfork or major release, irregardless of whether to continue the BSIP 42 or it might get voted out we could move and seperate the "pricefeed"-data and the "premium" (modifier) data into a new variable set by witnesses publishing this 'modifier/premium'.

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

1. This would mean that witnesses can continue to publish pricefeeds according to the old "market reflecting" data as sampled from all sources.
2. The pricefeed data reflects "true" reflection of the market and can continue to be used as trusted source for input for other projects whatever they may be.
3. Then inside the new software version code the final price to be calculated could be as simple as "pricefeed median * 'modifier median".

- If BSIP42 gets voted out it could be as simple as everyone publishing a "1.0"-value as "modifier".
- If BSIP42 stays active it is way easier to see witnesses' premiums/modifiers and the pricefeeds can stay usefull for other projects beyond and inside the Bitshares realm.

[Thul3]

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

BSIP42 is a total failure moving BitCNY directly and quickly to a global settlement.
We already have at this high BTS price a BTS sell wall of 21 million BTS on a CTR of 1.65 and the global settlement price will be already reached at 0.47 CNY .


This is fucking nuts what you guys are doing.You fucking play with everyones collateral.
You guys are clearly out of control and should be kicked out of commitee for these steps.....
In my private opinion to protect your own assets against margin call.

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

Yeah lets quickly change bitusd too to protect your assets on bitusd too before people realise what shit they implemented and what its causing.
Hurry hurry to implement bitusd calling bsip42 after a few days a full success ignoring now the big margin walls we have in the smallest downtrend .
Once its changed it will stay like your fucking 5% settlement fee.

You deserve the price of the biggest manipulator on bitshares thinking being so smart to always be able to sell the community stupid trojan horses

[abit]

data at this moment:
bitCNY: BTS price:0.818, feed price:0.917, premium:0.1%
bitUSD: BTS price:0.115, feed price:0.119, premium: 4% 

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

how did you calculate this premium?

You can also check here https://coinmarketcap.com/currencies/bitcny/ , remember to set CNY as base currency.

[yvv]

This guy is trying to trick witnesses into preferring his private exchange for deriving a feed price. This is BULLSHIT! This is attack on the network, happening right now. This attack is initiated by few malicious committee members. Proxies, wake up and use your voting power to stop this!

[bitcrab]

data at this moment:
bitCNY: BTS price:0.818, feed price:0.917, premium:0.1%
bitUSD: BTS price:0.115, feed price:0.119, premium: 4% 

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

how did you calculate this premium?

for bitCNY one reference is the deposit fee in magicwallet, currently as shown below the deposit fee is -0.06%, means now the premium is -0.06, or bitCNY has a 0.06% discount.




on the other hand, you can also compare the BTS price in bitCNY and in fiat CNY to get the premium, same for USD.

[yvv]

data at this moment:
bitCNY: BTS price:0.818, feed price:0.917, premium:0.1%
bitUSD: BTS price:0.115, feed price:0.119, premium: 4% 

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

Bullshit! Right now

Feed price: 1.07539 BTS/CNY
Last price: 1.21065 BTS/CNY

(1.21065-1.07539)/1.07539~0.13, which is 13% premium, not 0.1%. Fix your calculator.

[paliboy]

data at this moment:
bitCNY: BTS price:0.818, feed price:0.917, premium:0.1%
bitUSD: BTS price:0.115, feed price:0.119, premium: 4% 

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

how did you calculate this premium?

[sschiessl]

Witnesses are still tweaking their algorithms. I think a little more time buffer would be well advised to have stable code base before moving to less liquid markets

[bitcrab]

data at this moment:
bitCNY: BTS price:0.818, feed price:0.917, premium:0.1%
bitUSD: BTS price:0.115, feed price:0.119, premium: 4% 

BSIP42 worked fairly well on bitCNY, we need to apply it on bitUSD in the next step.

[sschiessl]

Ok cool.

I have included the comment to use bitCNY first. Please have a look once and comment your support of the changes in the PR https://github.com/bitshares/bsips/pull/105 .

[bitcrab]

https://github.com/bitshares/bsips/pull/106

add discussion and voting relevant content.

Did you see my post above? I did the exact same thing. Shall we merge the PRs?

oh, sorry I haven't checked your PR details when I write my PR, now seems my PR can be ignored...

[sschiessl]

https://github.com/bitshares/bsips/pull/106

add discussion and voting relevant content.

Did you see my post above? I did the exact same thing. Shall we merge the PRs?

[bitcrab]

https://github.com/bitshares/bsips/pull/106

add discussion and voting relevant content.

[sschiessl]

https://github.com/bitshares/bsips/pull/105

Please consider this, and please to also honor it if accepted.

[sschiessl]

Appreciate the answer. My point is on the formalities though, not the content of the BSIP.

we give 2 weeks for community to review the BSIP and vote, in 7th Sep if the worker proposal is active and the votes is greater than that of the oppose worker proposal, then the BSIP is accepted.

All this information needs to be included in the BSIP, please carefully consider my questions and suggestions above.

[bitcrab]

Appreciate the answer. My point is on the formalities though, not the content of the BSIP.

we give 2 weeks for community to review the BSIP and vote, in 7th Sep if the worker proposal is active and the votes is greater than that of the oppose worker proposal, then the BSIP is accepted.

[sschiessl]

As it stands right now, the worker proposal has no definition when it will become active, nor is it complete. No one should vote for it. But it seems with 400 million and more votes, it will be done. I strongly disagree that proper formalities were skipped, simply because our whales want to push it through.

I do like your suggestion to have it in a constantly evaluated stage. The BSIP is considered accepted, if the proposal is active AND carries more votes than the against proposal (one vote more is enough).

My suggestion:

a) Finish the proposal by including the discussion and shareholder summary. Also include an exact definition when it is considered active. This should be done by @abit or @bitcrab as the driving force behind it
b) Once the BSIP is completed, give at least 1 week grace period so shareholders can vote for or against it (the date when it can earliest become active should be included in the BSIP as well)

My personal opinion:
As the proposal stands right now I can not vote for it for formal reason, completely independent of the content. I would be rather forced to vote for "status quo" until the formalities are reinstated. Currently, everyone is swayed by the mere overwhelming power that bitcrab carries, yet I want to see that even he upholds formal procedure. This is crucial for me, as it only empowers the power abuse discussion involving our whales.

BSIP42 can be regarded as a request to community to permit witnesses to try some new way of feeding.

the core idea in the BSIP42 is "negative feed back feed price" based on the premium/discount of smartcoin, however, no detailed specification are provided, because I think it may be not a good way for abit or me to provide a detailed algorithm and ask the witnesses to adopt, discussion are on going and we keep on suggesting, but I think finally witnesses will develop different algorithms to feed price based on their own understanding. this diversity is also essential for decentralization.

I will try to add more discussion to the BSIP later.

Appreciate the answer. My point is on the formalities though, not the content of the BSIP.

[bitcrab]

As it stands right now, the worker proposal has no definition when it will become active, nor is it complete. No one should vote for it. But it seems with 400 million and more votes, it will be done. I strongly disagree that proper formalities were skipped, simply because our whales want to push it through.

I do like your suggestion to have it in a constantly evaluated stage. The BSIP is considered accepted, if the proposal is active AND carries more votes than the against proposal (one vote more is enough).

My suggestion:

a) Finish the proposal by including the discussion and shareholder summary. Also include an exact definition when it is considered active. This should be done by @abit or @bitcrab as the driving force behind it
b) Once the BSIP is completed, give at least 1 week grace period so shareholders can vote for or against it (the date when it can earliest become active should be included in the BSIP as well)

My personal opinion:
As the proposal stands right now I can not vote for it for formal reason, completely independent of the content. I would be rather forced to vote for "status quo" until the formalities are reinstated. Currently, everyone is swayed by the mere overwhelming power that bitcrab carries, yet I want to see that even he upholds formal procedure. This is crucial for me, as it only empowers the power abuse discussion involving our whales.

BSIP42 can be regarded as a request to community to permit witnesses to try some new way of feeding.

the core idea in the BSIP42 is "negative feed back feed price" based on the premium/discount of smartcoin, however, no detailed specification are provided, because I think it may be not a good way for abit or me to provide a detailed algorithm and ask the witnesses to adopt, discussion are on going and we keep on suggesting, but I think finally witnesses will develop different algorithms to feed price based on their own understanding. this diversity is also essential for decentralization.

I will try to add more discussion to the BSIP later.

[gghi]

       This plan is not proposed by bitcrab, but bitcrab is only a propellant.

[sschiessl]

abit can you please clarify how the two workers are intended?

My assumption:

a) If the "support" proposal becomes active AND has more votes then the "dont support" proposal, then the BSIP is considered accepted?

I agree, although 1) "active" is relative so perhaps doesn't apply here, and 2) IMHO the quantity of "more votes" need to be significant.

By the way there are discussions about opinion workers here: https://github.com/bitshares/bsips/issues/4

b) What is the time period that people are asked to vote for this before the judgment in a) is being done?

Hard to tell. Perhaps one week? What's your opinion?

Actually we can make it a "permanent" poll, because we can stop/revert the change (to new feed of course) at any time. Then we need to make decision more than once.

The Shareholder Summary is still missing, Discussion as well. Can you please add it?

Hope people will create pull requests for adding new info.

As it stands right now, the worker proposal has no definition when it will become active, nor is it complete. No one should vote for it. But it seems with 400 million and more votes, it will be done. I strongly disagree that proper formalities were skipped, simply because our whales want to push it through.

I do like your suggestion to have it in a constantly evaluated stage. The BSIP is considered accepted, if the proposal is active AND carries more votes than the against proposal (one vote more is enough).

My suggestion:

a) Finish the proposal by including the discussion and shareholder summary. Also include an exact definition when it is considered active. This should be done by @abit or @bitcrab as the driving force behind it
b) Once the BSIP is completed, give at least 1 week grace period so shareholders can vote for or against it (the date when it can earliest become active should be included in the BSIP as well)

My personal opinion:
As the proposal stands right now I can not vote for it for formal reason, completely independent of the content. I would be rather forced to vote for "status quo" until the formalities are reinstated. Currently, everyone is swayed by the mere overwhelming power that bitcrab carries, yet I want to see that even he upholds formal procedure. This is crucial for me, as it only empowers the power abuse discussion involving our whales.

[abit]

abit can you please clarify how the two workers are intended?

My assumption:

a) If the "support" proposal becomes active AND has more votes then the "dont support" proposal, then the BSIP is considered accepted?

I agree, although 1) "active" is relative so perhaps doesn't apply here, and 2) IMHO the quantity of "more votes" need to be significant.

By the way there are discussions about opinion workers here: https://github.com/bitshares/bsips/issues/4

b) What is the time period that people are asked to vote for this before the judgment in a) is being done?

Hard to tell. Perhaps one week? What's your opinion?

Actually we can make it a "permanent" poll, because we can stop/revert the change (to new feed of course) at any time. Then we need to make decision more than once.

The Shareholder Summary is still missing, Discussion as well. Can you please add it?

Hope people will create pull requests for adding new info.

[sschiessl]

abit can you please clarify how the two workers are intended?

My assumption:

a) If the "support" proposal becomes active AND has more votes then the "dont support" proposal, then the BSIP is considered accepted?

b) What is the time period that people are asked to vote for this before the judgment in a) is being done?

The Shareholder Summary is still missing, Discussion as well. Can you please add it?

[bitcrab]

Summary for Shareholders as well as discussion links are missing in the BSIP, can you please add it?

Why did this get split in two workers? Can you please clarify the intent?

Questions that pop up:

• What if none get active?
• What if both remain inactive?
• Does a non active "don't support it" proposal lead to implementation even if the "support it" is not active?

one for support and one for oppose.

I think only when "support" proposal get active and get more voting than the "oppose" proposal then implementation can begin.

although this BSIP is generally for smartcoins, but I think it should be firstly implemented in bitCNY if it pass the voting, only when the result is satisfactory enough then will implement it in bitUSD.

[sschiessl]

Summary for Shareholders as well as discussion links are missing in the BSIP, can you please add it?

Why did this get split in two workers? Can you please clarify the intent?

Questions that pop up:

• What if none get active?
• What if both remain inactive?
• Does a non active "don't support it" proposal lead to implementation even if the "support it" is not active?

 

[bitcrab]

voted to support.

discussion are here: https://bitsharestalk.org/index.php?topic=26948.0

[abit]

BSIP doc: https://github.com/bitshares/bsips/blob/master/bsip-0042.md


Poll workers:

1.14.118 Poll - BSIP42 - Adjust price feed dynamically

1.14.119 Poll - BSIP42 - NO adjustment to price feed


That said, if you support the change, please vote for 1.14.118, if you don't support, please vote for 1.14.119.