New BSIP:Reform of loopholes in feed price mechanism

[wenhuadream]

BSIP: 
Title: Reform of loopholes in feed price mechanism
Authors: cn-vote  [email protected]
Status: Draft
Type:  Protocol 
Created: 2019-10-18

Abstract

This BSIP defines reforms to the current feed price mechanism vulnerability. The specific program is: The feed price is the highest between the current price and the two-day moving average price .

Motivation

After the failure of BSIP42, the current feed price mechanism has major loopholes and serious negatives, many cex exchanges use our vulnerability to maliciously short,which seriously damaged the ecological balance, which caused us to suffer many unnecessary losses and hindered the development of the entire ecology.
When the vulnerability has been expanded to be intolerable, in an emergency, the passage and execution of BSIP76 has temporarily blocked the expansion of the vulnerability. However, the current feed price mechanism is still in urgent need of reform.

Rational

"The feed price is the highest between the current price and the two-day moving average price ".
This BSIP does not conflict with the previous consensus on the feed price of all the communities. The feed provider continue to collect the feed price according to the original community consensus, and the community consensus on the protection of the black swan(BSIP58) and the minimum feed price is continued(BSIP76).
This BSIP only requires the introduction of the abstract described in the feed price script, which is
"The feed price is the highest between the current price and the two-day moving average price ".

Specifications

Implementing measures

If (current price >  two-day moving average price) {
  feed price = current price;
}
Else{
  feed price = two-day moving average price;
}

Noun explanation

• Current price : The real-time feed price of the current feed price mechanism before the reform.
• Two-day moving average price : two-day moving average price =( current price (1) + current price (2) + current price ( 3) ...+ current price (n) )/n.
  • n is the sampling frequency, which is 48 times, that is, n = 48*m; m is positive: m = 1, 2, 3....
  • current price (k) is the current price at the time of sampling. The current price (1) is the
    current price at this moment. The current price (n) is the current price at the time of 48 hours ago.
  • Sampling interval (in hours): sampling interval = 48 / n = 48 / (48 * m). That is: m = 1, two- day moving average price every hour to sample once,;m = 2, two-day moving average price half an hour to sample once, And so on.

supplementary explanation

To decide whether to reform of loopholes in feed price mechanism, 2 poll worker proposals will be created for voting:

• Poll-BSIP**- Reform of loopholes in feed price mechanism.
• Poll-BSIP**-Not reform of loopholes in feed price mechanism.

If the voting confirm the change, committee will announce the change at least 3 days before the change is implemented by feed provider.

Summary for Shareholders

This program is simple and effective, and can prevent malicious short-selling or increase malicious short-selling costs to a certain extent.

See Also

https://bitsharestalk.org/index.php?topic=29698.0
https://bitsharestalk.org/index.php?topic=29699.0
https://bitsharestalk.org/index.php?topic=29635.0
https://bitsharestalk.org/index.php?topic=28418.0
https://bitsharestalk.org/index.php?topic=29684.0
https://bitsharestalk.org/index.php?topic=29687.0

Copyright

This document is placed in the public domain.

[pmconrad]

Please clarify: this BSIP proposes a change in how the price feed scripts work, not a change how the core code makes use of the price feed. Correct?

Please explain: why two days for the moving average? (E. g. why not 1 day or 3 days?)

Please replace the term "witness" with "feed provider". (The committee is currently managing the feed provider list manually for bitCNY and bitUSD. I. e. witnesses are not automatically feed providers, and feed providers need not be witnesses.)

[wenhuadream]

Please clarify: this BSIP proposes a change in how the price feed scripts work, not a change how the core code makes use of the price feed. Correct?

Please explain: why two days for the moving average? (E. g. why not 1 day or 3 days?)

Please replace the term "witness" with "feed provider". (The committee is currently managing the feed provider list manually for bitCNY and bitUSD. I. e. witnesses are not automatically feed providers, and feed providers need not be witnesses.)

1： how the price feed scripts work is the witness' things.
2: why two days for the moving average?It is our comprehensive consideration of the stability of
the smartcoin. Otherwise, the higher the average time, the better the effect. This is the
result of comprehensive consideration.
3：The current consensus is that witnesses are still feed providers.

[pmconrad]

Please clarify: this BSIP proposes a change in how the price feed scripts work, not a change how the core code makes use of the price feed. Correct?

how the price feed scripts work is the witness' things.

Does that mean "yes"?

It is our comprehensive consideration of the stability of the smartcoin.

Please add a "Discussion" section so shareholders can follow your reasoning instead of believing in the outcome.

The current consensus is that witnesses are still feed providers.

No. In case you missed it: https://bitsharestalk.org/index.php?topic=29702.0

[wenhuadream]

Please add a "Discussion" section so shareholders can follow your reasoning instead of believing in the outcome.

The current consensus is that witnesses are still feed providers.

No. In case you missed it: https://bitsharestalk.org/index.php?topic=29702.0

Thanks for reminding that the witness has now been replaced by feed provider.

[grctest]

Reform of loopholes

Can a more descriptive title be given? You only make one proposed price feed script change, so only one 'loophole' is potentially addressed.

A more accurate title would be something like "moving average reference asset price reference backup mechanism for bitUSD & bitCNY".

Please clarify: this BSIP proposes a change in how the price feed scripts work, not a change how the core code makes use of the price feed. Correct?

Sounds about right, it could instead be a direct request to the committee (asset owner) for permission & issues on multiple price feed script github repos to improve the FIAT reference asset evaluation mechanisms than a BSIP directed at price feed publishers.

1： how the price feed scripts work is the witness' things.

It's not solely a price feed publisher 'thing'; It's the asset owner's decision that matters regarding price feeding strategy, then it's the multiple price feed script developer's responsibility to interpret pull requests (which have implemented the asset owner's requested change), then the price feed publisher's responsibility to use the latest accurate mechanism.

feed price = two-day moving average price;

Can you include the full pseudocode implementation within the specification's implementation measures please?

m is positive: m = 1, 2, 3....

What does m represent? When/how does it change? Is it just a value for price feed publishers to tweak to increase price feed sampling?

many cex exchanges use our vulnerability to maliciously short,which seriously damaged the ecological balance, which caused us to suffer many unnecessary losses

Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?

When the vulnerability has been expanded to be intolerable, in an emergency, the passage and execution of BSIP76 has temporarily blocked the expansion of the vulnerability.

The execution came before the passage of BSIP76 related WP. [1], [2]. Why was this change forced onto price feed publishers ahead of any BSIP76 related WP being passed?

However, the current feed price mechanism is still in urgent need of reform.

The price feeding mechanism within bitshares core & ui is fully operational and not in need of any reform. The reference asset price sampling mechanism for select smartcoins on the Bitshares platform are arguably in need of reform, that would require changes from price feed script developers.

The specific program is: The feed price is the highest between the current price and the two-day moving average price.

How does this specific program plan to address CEX which perform further 'short attacks'? There's no proposed change to the 'current price' reference in this BSIP which like removing reference price sources if they act abnormally to other sources in a short time frame.

If the 'short attack' was to last 2 days it would have an effect on the two-day moving average price which would cease being an effective solution.

The witnesses continue to collect the feed price according to the original community consensus, and the community consensus on the protection of the black swan(BSIP58) and the minimum feed price is continued(BSIP76).

So this BSIP you propose doesn't solve the 'loopholes' which justified BSIP76? It won't have any impact on bitCNY nor bitUSD until BSIP76 eventually disables when/if BTS price recovers significantly enough? When do you estimate this will occur?

This program is simple and effective, and can prevent malicious short-selling or increase malicious short-selling costs to a certain extent.

It doesn't prevent malicious short selling. It does increase the cost of a short selling attack if real BTS funds are being used, however if no real BTS are behind the CEX based attack it doesn't increase the cost of the attack.

[wenhuadream]

Please add a "Discussion" section so shareholders can follow your reasoning instead of believing in the outcome.

In also see, there are links to talk about

[MichelSantos]

I can understand the reasoning for a moving average of the price rather than the current price to smooth out "unusual" spikes. I don't agree with feed providers implementing the moving average because I think the feed providers should provide the true price (to the extent that anyone can believe that a single price for an asset exists everywhere and at any moment) to the blockchain.

But why not propose to always use a moving average instead of proposing to conditionally (when the price is below the average) use a moving average? Why is the current price acceptable when it is higher than the average?

[pmconrad]

In also see, there are links to talk about

Most of these are in Chinese. It would be helpful for the english-speaking community if you could add a comprehensive version of the discussion that has taken place.

[abitmore]

I don't agree with feed providers implementing the moving average because I think the feed providers should provide the true price (to the extent that anyone can believe that a single price for an asset exists everywhere and at any moment) to the blockchain.

Technically it's better to implement the moving average or median price in core, like what's done in Steem (Steem witnesses do use a somewhat subjective bias parameter to adjust price feeds though).

Again, IMHO, if this BSIP is desired to be long-term, it's better to implement it in core; if it's an experiment or something urgent, it's better to ask feed producers to apply it.

[pmconrad]

1. Please write in english.
2. Discussing proposals is good practice, because discussion usually helps all parties to better understand the issue at hand, and it often leads to a better proposal as well.
3. So far I can't see that anyone here is opposed to the BSIP, so what are you complaining about? At least keep a civilized tone.

[bangzi1001]

Decouple BitAssets from Bitshares BSIPS Repository
https://github.com/bitshares/committee-tools/issues/11

[wenhuadream]

Can a more descriptive title be given? You only make one proposed price feed script change, so only one 'loophole' is potentially addressed.

I only said the reform, and did not say that it was removed, so I think it is correct.

It's not solely a price feed publisher 'thing'; It's the asset owner's decision that matters regarding price feeding strategy, then it's the multiple price feed script developer's responsibility to interpret pull requests (which have implemented the asset owner's requested change), then the price feed publisher's responsibility to use the latest accurate mechanism.

I have already said that the feed provider only needs to add the relevant script code to comply with this BSIP designation rule.

Can you include the full pseudocode implementation within the specification's implementation measures please?

I only specify the rules that need to be followed.

What does m represent? When/how does it change? Is it just a value for price feed publishers to tweak to increase price feed sampling?

m I have explained enough. The feed provider can freely choose the value of m. Of course, the bigger m is, the better, the better you do, the bigger the m, the more votes you will vote for.>

Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?

https://bitsharestalk.org/index.php?topic=29633.0

The execution came before the passage of BSIP76 related WP. [1], [2]. Why was this change forced onto price feed publishers ahead of any BSIP76 related WP being passed?

BSIP76 is beyond the scope of my discussion, you should go to BSIP76 to discuss

The price feeding mechanism within bitshares core & ui is fully operational and not in need of any reform. The reference asset price sampling mechanism for select smartcoins on the Bitshares platform are arguably in need of reform, that would require changes from price feed script developers.

I explained that it is clear that the feed script can add scripts that conform to this BSIP rule.

If the 'short attack' was to last 2 days it would have an effect on the two-day moving average price which would cease being an effective solution.

Summary for Shareholders has been answered very well, I hope you read it carefully

So this BSIP you propose doesn't solve the 'loopholes' which justified BSIP76? It won't have any impact on bitCNY nor bitUSD until BSIP76 eventually disables when/if BTS price recovers significantly enough? When do you estimate this will occur?

Regarding the BSIP76 issue, you should go to BSIP76 to talk about it. I think BSIP76 is a consensus. I follow this consensus.

It doesn't prevent malicious short selling. It does increase the cost of a short selling attack if real BTS funds are being used, however if no real BTS are behind the CEX based attack it doesn't increase the cost of the attack.

You have not denied that it is indeed effective. There is never a perfect solution, as long as it works, it is even feasible.

[wenhuadream]

Most of these are in Chinese. It would be helpful for the english-speaking community if you could add a comprehensive version of the discussion that has taken place.

There are also forums in the English community to talk about, and I have to admit that this program is talked about, the Chinese community is mostly.

[wenhuadream]

Decouple BitAssets from Bitshares BSIPS Repository
bitshares/committee-tools#11

I have to admit that you have diverted people's attention very well.

[wenhuadream]

2. Discussing proposals is good practice, because discussion usually helps all parties to better understand the issue at hand, and it often leads to a better proposal as well.

I will do this. I hope that everyone will talk about it here, as the basis for my subsequent addition.

3. So far I can't see that anyone here is opposed to the BSIP, so what are you complaining about? At least keep a civilized tone.

You may have misunderstood, I have not complained to anyone. I have to be sorry for replying you late because of the weekend. I hope that everyone will give me more advice, which will make this BSIP more progressive.

[wenhuadream]

Technically it's better to implement the moving average or median price in core, like what's done in Steem (Steem witnesses do use a somewhat subjective bias parameter to adjust price feeds though).

Again, IMHO, if this BSIP is desired to be long-term, it's better to implement it in core; if it's an experiment or something urgent, it's better to ask feed producers to apply it.

I think this is a good suggestion.

[abitmore]

@ryanRfox how about assigning a BSIP number?

[pmconrad]

You may have misunderstood, I have not complained to anyone.

Sorry, my comments were not addressed to you but to @ning-xiao . I should have made that clear.

[wenhuadream]

You may have misunderstood, I have not complained to anyone.

Sorry, my comments were not addressed to you but to @ning-xiao . I should have made that clear.

It's ok。

[grctest]

Can a more descriptive title be given? You only make one proposed price feed script change, so only one 'loophole' is potentially addressed.

I only said the reform, and did not say that it was removed, so I think it is correct.

I disagree, I don't think it's an accurate summary; At the very least there's an unnecessary pluralization of 'loophole'.

If your proposed changes do not fully remove the loopholes, can you fully elaborate on the remaining loopholes?

I have already said that the feed provider only needs to add the relevant script code to comply with this BSIP designation rule.

It's not just a request to the price feed publisher though, it's a request to change multiple price feed scripts - some of which can take a while to change 3.

Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?

https://bitsharestalk.org/index.php?topic=29633.0

These are somewhat baseless accusations & suspicions. AFAIK ZB hasn't publicly acknowledged this incident despite actively participating in the Bitshares voting process.

Couldn't we have temporarily removed ZB from the pool of USD price reference sources instead of setting a fixed price? Automating such a response would improve response time to suspected price feed focused short attacks in the future.

The execution came before the passage of BSIP76 related WP. [1], [2]. Why was this change forced onto price feed publishers ahead of any BSIP76 related WP being passed?

BSIP76 is beyond the scope of my discussion, you should go to BSIP76 to discuss

BSIP76 is mentioned in both the motivation and rationale sections of this BSIP, so it's in scope for discussion. I was primarily referring to the correct sequence of events.

Already posted in BSIP76 about the questions you may consider out of scope.

The price feeding mechanism within bitshares core & ui is fully operational and not in need of any reform. The reference asset price sampling mechanism for select smartcoins on the Bitshares platform are arguably in need of reform, that would require changes from price feed script developers.

I explained that it is clear that the feed script can add scripts that conform to this BSIP rule.

The quoted section wasn't clear, it read as placing responsibility/blame on the internal Bitshares core price feed mechanisms rather than on external price feed scripts & their correct configuration.

If the 'short attack' was to last 2 days it would have an effect on the two-day moving average price which would cease being an effective solution.

Summary for Shareholders has been answered very well, I hope you read it carefully

Current Summary for Shareholders: "This program is simple and effective, and can prevent malicious short-selling or increase malicious short-selling costs to a certain extent."

Have you tested the proposed changes prior to claiming it's effective? Had this been in place prior to the ZB incident, how would it have faired?

The use of 'to a certain extent' is not a transparent disclosure of ineffectiveness against longer term incidents. BSIP76 proposed changes have been active for about 4 weeks now, that's much longer than 2 days.

So this BSIP you propose doesn't solve the 'loopholes' which justified BSIP76? It won't have any impact on bitCNY nor bitUSD until BSIP76 eventually disables when/if BTS price recovers significantly enough? When do you estimate this will occur?

Regarding the BSIP76 issue, you should go to BSIP76 to talk about it. I think BSIP76 is a consensus. I follow this consensus.

Fair enough BSIP76 recovery estimate is out of scope.

However the other 2 questions are for you - would this BSIP have negated the need for BSIP76? And this BSIP won't have any impact on CNY/USD until BSIP76 is over?

It doesn't prevent malicious short selling. It does increase the cost of a short selling attack if real BTS funds are being used, however if no real BTS are behind the CEX based attack it doesn't increase the cost of the attack.

You have not denied that it is indeed effective. There is never a perfect solution, as long as it works, it is even feasible.

I do disagree that this is an effective solution if the incident lasts longer than the moving average duration (2 days), given that BSIP76 has lasted 4 weeks now shows longer term incidents are probable.

I do not have concrete proof of effectiveness to make final judgement on the solution.

[tonyniu352]

in china，a lot of individual investors also enter the futures market, which is very different from the western market. However, individual investors and institutional investors are not balanced in terms of financial strength, and manipulation of settlement price by financial strength often happens.so, in china,all furtures exchanger determine the furture settlement price by taking the volume weighted average price during a trading day ,so as to effectively prevent the risk of market manipulation.
For the BTS system, investors' debt holdings are completely exposed to cex, and there is a complete imbalance between individual investors and cex. Furthermore, some cex used to sell fake BTS to cause the price to fall sharply which influence the trading price of BTS in all markets,and trigger a series of bts debt explosive .
Considering the above discussion, it is necessary to introduce some price protection algorithm in the core code. For example, mentioned by this bsip，the feed price is the larger one selected between the average value and current value so as to resist price manipulation and improve the price recovery ability of BTS.

[pmconrad]

in china,all furtures exchanger determine the furture settlement price by taking the volume weighted average price during a trading day ,so as to effectively prevent the risk of market manipulation

Thanks. That is an interesting piece of information that many probably aren't aware of. It should go into the "Discussion" section.

IMHO, if this BSIP is desired to be long-term, it's better to implement it in core; if it's an experiment or something urgent, it's better to ask feed producers to apply it.

Agree.
However, I think at this time this will be an experiment. It should be implemented by feed producers, which can be done with comparatively little effort. If it turns out to be a working solution it should be implemented in core so that feed providers can return back to publishing the current market price.

[wenhuadream]

Can a more descriptive title be given? You only make one proposed price feed script change, so only one 'loophole' is potentially addressed.

I only said the reform, and did not say that it was removed, so I think it is correct.

I disagree, I don't think it's an accurate summary; At the very least there's an unnecessary pluralization of 'loophole'.
If your proposed changes do not fully remove the loopholes, can you fully elaborate on the remaining loopholes?

I insist that my topic is correct. Because I am talking about reform, reform means just making the situation better. There are indeed many loopholes. You also admit this. I just reformed part of it and did not say that it was completely removed.

I have already said that the feed provider only needs to add the relevant script code to comply with this BSIP designation rule.

It's not just a request to the price feed publisher though, it's a request to change multiple price feed scripts - some of which can take a while to change 3.

I don't think so, refer to the passage and execution process of BSIP58.

Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?

https://bitsharestalk.org/index.php?topic=29633.0

These are somewhat baseless accusations & suspicions. AFAIK ZB hasn't publicly acknowledged this incident despite actively participating in the Bitshares voting process.

Couldn't we have temporarily removed ZB from the pool of USD price reference sources instead of setting a fixed price? Automating such a response would improve response time to suspected price feed focused short attacks in the future.

If you don't recognize this fact, I think you are not wise. The other thing I want to tell you is that if someone is a bad person and does something bad, will he say to others: hi, I tell you, I am a bad person, doing bad things?

The execution came before the passage of BSIP76 related WP. [1], [2]. Why was this change forced onto price feed publishers ahead of any BSIP76 related WP being passed?

BSIP76 is beyond the scope of my discussion, you should go to BSIP76 to discuss

BSIP76 is mentioned in both the motivation and rationale sections of this BSIP, so it's in scope for discussion. I was primarily referring to the correct sequence of events.

Already posted in BSIP76 about the questions you may consider out of scope.

I insist that this issue needs to be discussed in BSIP76. I follow all the consensus. Should all the BSIPs that are passed should be discussed here?

The price feeding mechanism within bitshares core & ui is fully operational and not in need of any reform. The reference asset price sampling mechanism for select smartcoins on the Bitshares platform are arguably in need of reform, that would require changes from price feed script developers.

I explained that it is clear that the feed script can add scripts that conform to this BSIP rule.

The quoted section wasn't clear, it read as placing responsibility/blame on the internal Bitshares core price feed mechanisms rather than on external price feed scripts & their correct configuration.

As abitmore said: if this BSIP is desired to be long-term, it's better to implement it in core; if it's an experiment or something urgent, it's better to ask feed producers to apply it.

If the 'short attack' was to last 2 days it would have an effect on the two-day moving average price which would cease being an effective solution.

Summary for Shareholders has been answered very well, I hope you read it carefully

Current Summary for Shareholders: "This program is simple and effective, and can prevent malicious short-selling or increase malicious short-selling costs to a certain extent."

Have you tested the proposed changes prior to claiming it's effective? Had this been in place prior to the ZB incident, how would it have faired?

The use of 'to a certain extent' is not a transparent disclosure of ineffectiveness against longer term incidents. BSIP76 proposed changes have been active for about 4 weeks now, that's much longer than 2 days.

I think you talked too much about BSIP76. If you have any comments on BSIP76, you should go to the BSIP76 area to talk about it. BSIP is already a community consensus and I follow him. I follow all of the community consensus we have adopted.

So this BSIP you propose doesn't solve the 'loopholes' which justified BSIP76? It won't have any impact on bitCNY nor bitUSD until BSIP76 eventually disables when/if BTS price recovers significantly enough? When do you estimate this will occur?

Regarding the BSIP76 issue, you should go to BSIP76 to talk about it. I think BSIP76 is a consensus. I follow this consensus.

Fair enough BSIP76 recovery estimate is out of scope.

However the other 2 questions are for you - would this BSIP have negated the need for BSIP76? And this BSIP won't have any impact on CNY/USD until BSIP76 is over?

BSIP76 is a community consensus, unless the community has agreed that it has been revoked, I have to comply with it, and it is even less likely to conflict with it.

It doesn't prevent malicious short selling. It does increase the cost of a short selling attack if real BTS funds are being used, however if no real BTS are behind the CEX based attack it doesn't increase the cost of the attack.

You have not denied that it is indeed effective. There is never a perfect solution, as long as it works, it is even feasible.

I do disagree that this is an effective solution if the incident lasts longer than the moving average duration (2 days), given that BSIP76 has lasted 4 weeks now shows longer term incidents are probable.

I do not have concrete proof of effectiveness to make final judgement on the solution.

Can you prove that it doesn't work? I think you can't because it really works. But before writing it to the core, I also recommend implementing it in an external script first. If the effect is good, write it to the core.

[wenhuadream]

in china，a lot of individual investors also enter the futures market, which is very different from the western market. However, individual investors and institutional investors are not balanced in terms of financial strength, and manipulation of settlement price by financial strength often happens.so, in china,all furtures exchanger determine the furture settlement price by taking the volume weighted average price during a trading day ,so as to effectively prevent the risk of market manipulation.
For the BTS system, investors' debt holdings are completely exposed to cex, and there is a complete imbalance between individual investors and cex. Furthermore, some cex used to sell fake BTS to cause the price to fall sharply which influence the trading price of BTS in all markets,and trigger a series of bts debt explosive .
Considering the above discussion, it is necessary to introduce some price protection algorithm in the core code. For example, mentioned by this bsip，the feed price is the larger one selected between the average value and current value so as to resist price manipulation and improve the price recovery ability of BTS.

Thanks for your suggestion, I found that many people suggested to write it into the core, I still recommend to implement it in the external script first, if it is valid, then write it to the core.

[grctest]

Can a more descriptive title be given? You only make one proposed price feed script change, so only one 'loophole' is potentially addressed.

I only said the reform, and did not say that it was removed, so I think it is correct.

I disagree, I don't think it's an accurate summary; At the very least there's an unnecessary pluralization of 'loophole'.
If your proposed changes do not fully remove the loopholes, can you fully elaborate on the remaining loopholes?

I insist that my topic is correct. Because I am talking about reform, reform means just making the situation better. There are indeed many loopholes. You also admit this. I just reformed part of it and did not say that it was completely removed.

I don't dispute the fact that this BSIP isn't an effective solution. I meant to disagree with the generalized plural 'loopholes' term & and would like request further definition of what other issues remain (since only one is currently referenced).

Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?

https://bitsharestalk.org/index.php?topic=29633.0

These are somewhat baseless accusations & suspicions. AFAIK ZB hasn't publicly acknowledged this incident despite actively participating in the Bitshares voting process.
Couldn't we have temporarily removed ZB from the pool of USD price reference sources instead of setting a fixed price? Automating such a response would improve response time to suspected price feed focused short attacks in the future.

If you don't recognize this fact, I think you are not wise.

Then I suppose I'm unwise for not recognizing random forum threads for facts when they were used to justify the suspiciously rapid implementation of BSIP76 prior to its WP gaining consensus.

The execution came before the passage of BSIP76 related WP. [1], [2]. Why was this change forced onto price feed publishers ahead of any BSIP76 related WP being passed?

BSIP76 is beyond the scope of my discussion, you should go to BSIP76 to discuss

BSIP76 is mentioned in both the motivation and rationale sections of this BSIP, so it's in scope for discussion. I was primarily referring to the correct sequence of events.
Already posted in BSIP76 about the questions you may consider out of scope.

I insist that this issue needs to be discussed in BSIP76. Should all the BSIPs that are passed should be discussed here?

If BSIP76 is not allowed to be discussed then why is it included in the motivations and rationale? Discussing a BSIP's motives and rationale should be allowed within said BSIP's issue/pull-request.

The price feeding mechanism within bitshares core & ui is fully operational and not in need of any reform. The reference asset price sampling mechanism for select smartcoins on the Bitshares platform are arguably in need of reform, that would require changes from price feed script developers.

I explained that it is clear that the feed script can add scripts that conform to this BSIP rule.

The quoted section wasn't clear, it read as placing responsibility/blame on the internal Bitshares core price feed mechanisms rather than on external price feed scripts & their correct configuration.

As abitmore said: if this BSIP is desired to be long-term, it's better to implement it in core; if it's an experiment or something urgent, it's better to ask feed producers to apply it.

If implemented in core, would it be added as an optional flag or would it be applied equally to all smartcoins on the bitshares platform? Not all smartcoins are exposed to the same CEX based threat as bitassets are.

If the 'short attack' was to last 2 days it would have an effect on the two-day moving average price which would cease being an effective solution.

Summary for Shareholders has been answered very well, I hope you read it carefully

Current Summary for Shareholders: "This program is simple and effective, and can prevent malicious short-selling or increase malicious short-selling costs to a certain extent."
Have you tested the proposed changes prior to claiming it's effective? Had this been in place prior to the ZB incident, how would it have faired?
The use of 'to a certain extent' is not a transparent disclosure of ineffectiveness against longer term incidents. BSIP76 proposed changes have been active for about 4 weeks now, that's much longer than 2 days.

I think you talked too much about BSIP76. If you have any comments on BSIP76, you should go to the BSIP76 area to talk about it. BSIP is already a community consensus and I follow him. I follow all of the community consensus we have adopted.

So I'm not allowed to reference BSIP76's activation duration in conversation? It's relevant when the duration of other intervening BSIPs far exceed the proposed 2 days in this BSIP.

It doesn't prevent malicious short selling. It does increase the cost of a short selling attack if real BTS funds are being used, however if no real BTS are behind the CEX based attack it doesn't increase the cost of the attack.

You have not denied that it is indeed effective. There is never a perfect solution, as long as it works, it is even feasible.

I do disagree that this is an effective solution if the incident lasts longer than the moving average duration (2 days), given that BSIP76 has lasted 4 weeks now shows longer term incidents are probable.
I do not have concrete proof of effectiveness to make final judgement on the solution.

Can you prove that it doesn't work? I think you can't because it really works.

So it's up to each individual voter to perform their own simulation to evaluate its feasibility? What if users get the calculation wrong when voting?

[ryanRfox]

@abitmore @wenhuadream This specific draft is out of scope for the BSIP repository based on:

• The BCSSCIP (BitShares Committee's SmartCoins Improvement Proposal) was recently introduced for all informational topics related to Committee-owned BitAssets.
• SCSSCIP1 https://github.com/bitshares/committee-tools/issues/11 defines the repsoitory sepatation
• All protocol changes will continue to be proposed, reviewed and approved within the scope of the established BSIP process.

@wenhuadream Please connect with Committee members @bangzi1001 @abitmore @jademont @bitcrab @xeroc @OpenLedgerApp @clockworkgr and others to raise your proposal according to their process. I suggest your new draft include a summary of the discussions herein and continue further discussions there.

Closing.

[abitmore]

I'd like to keep the discussion open since it's possible that it will lead to a protocol change. IMO the title should be more specific though.

[xeroc]

Also curious about this discussion.
I always wondered if we could adopt Steem's moving average concept, but always though it wouldn't work well in combination with margin calls. I always had the impression we wanted them to be called and executed quickly, but I need to think about if and why that might be the case.

[ryanRfox]

Requesting some feedback from others on the BSIP Review Team on the scope of their efforts. My opinion is that the Committee is a distinct entity owning BitAssets and any informational discussions are out of scope to the BSIP repository. Until such time as the Committee brings forward a protocol BSIP based on their decision and approval of a BCSSCIP, this Issue should remain closed and remain outside of the scope of the BSIP Review Team. It is a distraction to be notified about informational decisions for which I am not party to.

[xeroc]

@ryanRfox I read the proposal (buried between the lines) that the desire is to add an extra option to have a moving average on price feeds additionally to the current "real-time" price feeds. Whether such feature would then be activated (and with what parameters) on bitassets is of course left to the issuer to decide.

However, I agree that the "short-term" solution here does not require changes to core but merely to the price feed scripts. A discussion about how/if this should be part of core should still be allowed, IMHO

[ryanRfox]

I will not close this Issue again. I raised my concerns. I also will not assign a BSIP as I continue to believe its current content is out of scope for this repo. If the discussions continue and the contents change to a protocol change it would become eligible for a BSIP number assignment.

[wenhuadream]

I will not close this Issue again. I raised my concerns. I also will not assign a BSIP as I continue to believe its current content is out of scope for this repo. If the discussions continue and the contents change to a protocol change it would become eligible for a BSIP number assignment.

1: The type has been changed and continues to participate in the discussion. And please consider assigning the BSIP number
2: I think a more appropriate approach is to remind me to change first, then consider closing.

[grctest]

Can we retroactively apply this ruling to past bitasset focused bsips like bsip76? Or does this only apply to new issues moving forwards?

…

On Mon, 21 Oct 2019, 15:59 Ryan R. Fox, ***@***.***> wrote: I will not close this Issue again. I raised my concerns. I also will not assign a BSIP as I continue to believe its current content is out of scope for this repo. If the discussions continue and the contents change to a protocol change it would become eligible for a BSIP number assignment. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244?email_source=notifications&email_token=ADZAOF2563UN374FNYHGMIDQPW7WRA5CNFSM4JCC3LE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB2UBIQ#issuecomment-544555170>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZAOFYWT73QVIXXX7ETGKDQPW7WRANCNFSM4JCC3LEQ> .

[abitmore]

The baips repository has been created: https://bitshares/baips . @wenhuadream how about transferring this issue there? We can create a new issue in this repository about protocol changes.

P.S. issue transfer is a github feature, a few clicks then it's done, no need to copy & paste. If need to do so please contact me.

[grctest]

Why a whole new repo? Wasn't the prior committee repo good enough? Is this solely because of the acronym?

…

On Mon, 21 Oct 2019, 21:21 Abit, ***@***.***> wrote: The baips repository has been created: https://bitshares/baips . @wenhuadream <https://github.com/wenhuadream> how about transferring this issue there? We can create a new issue in this repository about protocol changes. P.S. issue transfer is a github feature, a few clicks then it's done, no need to copy & paste. If need to do so please contact me. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244?email_source=notifications&email_token=ADZAOF4PNLCPUGBIY6GRNITQPX6K5A5CNFSM4JCC3LE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB3PJPI#issuecomment-544666813>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADZAOFZEO4QUWC7NJJXVB43QPX6K5ANCNFSM4JCC3LEQ> .

[MichelSantos]

Thanks for your suggestion, I found that many people suggested to write it into the core, I still recommend to implement it in the external script first, if it is valid, then write it to the core.

@wenhuadream I agree that if this should be done it will be good to develop experience with it as an external script.

I had an earlier question which may have been lost in the discussion. Why is the current price acceptable when it is higher than the average? This seems inconsistent to me.

[MichelSantos]

If this were ever to go into Core, the data fusion of raw data feed should maybe be selectable by the issuer from among a set of finite algorithms

[wenhuadream]

The baips repository has been created: https://bitshares/baips . @wenhuadream how about transferring this issue there? We can create a new issue in this repository about protocol changes.

P.S. issue transfer is a github feature, a few clicks then it's done, no need to copy & paste. If need to do so please contact me.

There are still a lot of details to be developed in BAIP. After the rules are formulated, I will open a new discussion in BAIP.
I think this BSIP can be reserved. If the external script effect is ideal, then go back to this BSIP and discuss the details of the changes that will be written to the core.

[wenhuadream]

I had an earlier question which may have been lost in the discussion. Why is the current price acceptable when it is higher than the average? This seems inconsistent to me.

I have to say that this rule is slightly beneficial to the Shareholders
In fact, the current rules are serious for short selling..

I am very sorry that I replied slowly and ignored your question. Because I think the short text is hard to say clearly.

[abitmore]

FWIW non-protocol discussion moved to bitshares/baips#4 .

[MichelSantos]

I had an earlier question which may have been lost in the discussion. Why is the current price acceptable when it is higher than the average? This seems inconsistent to me.

I have to say that this rule is slightly beneficial to the Shareholders
In fact, the current rules are serious for short selling..

I see. In my opinion an asset and the asset issuer will be much better regarded by potential holders if the feed price mechanism does not have favoritism.

I am very sorry that I replied slowly and ignored your question. Because I think the short text is hard to say clearly.

That is no problem at all. Thank you for the reply @wenhuadream .