Main > Stakeholder Proposals

[Poll] BSIP42: adjust price feed dynamically

(1/7) > >>

abit:

--- Quote from: Thul3 on September 24, 2018, 02:58:29 pm ---
--- Quote ---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.
--- End quote ---

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

--- End quote ---
No.

Thul3:

--- Quote ---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.
--- End quote ---

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

abit:

--- Quote from: roelandp on September 24, 2018, 08:20:14 am ---
--- Quote from: bitcrab on September 23, 2018, 07:55:37 pm ---
--- Quote from: roelandp on September 22, 2018, 01:22:44 pm ---@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.

--- End quote ---

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.

--- End quote ---

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.

--- End quote ---
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:

--- Quote from: bitcrab on September 23, 2018, 07:55:37 pm ---
--- Quote from: roelandp on September 22, 2018, 01:22:44 pm ---@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.

--- End quote ---

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.

--- End quote ---

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:

--- Quote from: roelandp on September 22, 2018, 01:22:44 pm ---@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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

Go to full version