New BSIP:Reform of loopholes in feed price mechanism #244
Comments
wenhuadream
changed the title
|
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. |
Does that mean "yes"?
Please add a "Discussion" section so shareholders can follow your reasoning instead of believing in the outcome.
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. |
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".
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.
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.
Can you include the full pseudocode implementation within the specification's implementation measures please?
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?
Can you please include proof that this occurred? Have the affected CEX acknowledged these incidents? Have malicious CEX been disavowed?
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?
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.
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.
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?
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. |
In also see, there are links to talk about |
|
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? |
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. |
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 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. |
This comment has been minimized.
This comment has been minimized.
|
|
Decouple BitAssets from Bitshares BSIPS Repository |
I only said the reform, and did not say that it was removed, so I think it is correct.
I have already said that the feed provider only needs to add the relevant script code to comply with this BSIP designation rule.
I only specify the rules that need to be followed.
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.>
https://bitsharestalk.org/index.php?topic=29633.0
BSIP76 is beyond the scope of my discussion, you should go to BSIP76 to discuss
I explained that it is clear that the feed script can add scripts that conform to this BSIP rule.
Summary for Shareholders has been answered very well, I hope you read it carefully
Regarding the BSIP76 issue, you should go to BSIP76 to talk about it. I think BSIP76 is a consensus. I follow this consensus.
You have not denied that it is indeed effective. There is never a perfect solution, as long as it works, it is even feasible. |
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. |
I have to admit that you have diverted people's attention very well. |
I will do this. I hope that everyone will talk about it here, as the basis for my subsequent addition.
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. |
I think this is a good suggestion. |
|
@ryanRfox how about assigning a BSIP number? |
Sorry, my comments were not addressed to you but to @ning-xiao . I should have made that clear. |
It's ok。 |
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?
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.
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.
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 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.
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.
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?
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. |
|
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. |
Thanks. That is an interesting piece of information that many probably aren't aware of. It should go into the "Discussion" section.
Agree. |
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 think so, refer to the passage and execution process of BSIP58.
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?
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?
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.
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.
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.
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. |
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. |
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).
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.
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.
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.
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.
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? |
|
@abitmore @wenhuadream This specific draft is out of scope for the BSIP repository based on:
@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. |
|
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. |
|
Also curious about this discussion. |
|
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 |
|
@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 |
|
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 |
1: The type has been changed and continues to participate in the discussion. And please consider assigning the BSIP number |
|
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>
.
|
|
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. |
|
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>
.
|
@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. |
|
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 |
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 have to say that this rule is slightly beneficial to the Shareholders I am very sorry that I replied slowly and ignored your question. Because I think the short text is hard to say clearly. |
|
FWIW non-protocol discussion moved to bitshares/baips#4 . |
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.
That is no problem at all. Thank you for the reply @wenhuadream . |
Abstract
This BSIP defines reforms to the current feed price mechanism vulnerability. The specific program is: The
feed priceis the highest between thecurrent priceand thetwo-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 priceand thetwo-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 priceand thetwo-day moving average price".Specifications
Implementing measures
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.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. Thecurrent price (1)is thecurrent 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 priceevery hour to sample once,;m = 2,two-day moving average pricehalf 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:
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.
The text was updated successfully, but these errors were encountered: