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!

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.

Quote

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 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.

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.

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' .

@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.

@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.