Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Does publishing feeds too frequently harm the network?(喂价太快会伤害网络吗?)  (Read 596 times)

Offline theoretical


The "provocative" post [1] raises an interesting point.  Does publishing feeds with high frequency harm the network?

The idea is if everyone's publishing price feeds very frequently, the cost to manipulate the feed is small -- the attacker can simply dump BTS on exchanges, causing a dip in the price feed, then sell much larger BitUSD holdings into margin calls at artificially high prices.  A relatively small manipulation -- only needing to clear out the order book depth immediately available on the exchanges -- can be amplified into a much larger manipulation -- margin calls to force covering at inflated prices by the entire short float.

OTOH if you have a random update interval (with some known expected value), the attack is much more expensive.  E.g. if average feed publish interval is 8 hours, then (assuming all delegates are online and honestly reporting prices) it takes 4 hours to update the median feed, so the attacker would have to sustain his dump for 4 hours, making it more expensive.

Also, "reactive" publishing -- publishing after a sudden price movement -- would also have a downside, it would mean a lot of delegates would update at the moment the attack commences.

I think we should consider the possibility that feed updates need to be done more slowly so that traders have time to move funds into / across exchanges and force any dump to break through the all the actively trading capital in the ecosystem, not just whatever happened to be immediately available on the exchange(s) when the dump occurred.

The main cost is that if there's a news event at a single discrete point in time that causes a quick price change, margin positions may not immediately be liquidated and the price would have time to fall further before the feed caught up and the positions started to unwind.

Thoughts?

[1] https://bitsharestalk.org/index.php?topic=13865.0

Translation:
总的来说,是讨论受托人喂价是否应该频繁和即时的问题。如果受托人喂价是频繁的,那么在外盘就很容易通过砸穿外盘来带动内盘的实时连环反应。但如果受托人喂价是随机的、不及时的、受托人之间频率相差很大的话,那么在外盘砸盘就需要持续很久才能达到这个目的,也增大了恶意砸盘的成本。

楼主还感觉,如果喂价变化速度慢点,那么就有利于搬砖、套利等行为,从而制约恶意砸盘。

不过,楼主认为这个方法可能有一个缺陷,如果价格变化得太快,空头仓位不能及时被平仓,等缓慢节奏的喂价改变后,这时候空头仓位的抵押品可能就没有那么充足了。 大家有啥想法?
« Last Edit: February 02, 2015, 06:01:24 PM by cn-members »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline Ander

  • Hero Member
  • *****
  • Posts: 3488
    • View Profile
  • BTS: Ander
I agree.

It seems important that different feeds do lots of different things.  That is, they don't all update at the same times, they get their prices from different sources and different markets, etc.  There needs to be some unpredictability in feeds so that they are harder to manipulate, and that manipulation is subject to some risk, rather than allowing for a guaranteed profit arbitrage opportunity. 
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11958
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Wouldnt the attackee require to dip multiple markets with high volume .. at least my script takes volume into account .. so that would be a rather expenaive attack ... but its a valid point .. we should write down some guidelines for feed publishing
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline jsidhu

  • Hero Member
  • *****
  • Posts: 1337
    • View Profile
bitsharesblocks shows red if your feed is too slow like under 10 times a minute or something... so as a delegate you assume you need a fast update time.. look at mine its topping 200! (I thought its a good thing) but on second thought maybe it should be reduced, the scripts themselves set the update intervals to random numbers and minimum amount of movement to random percentage std dev around 5-10% and adjusted 5-10% either way. That way there are less things to configure for delegates and they dont have to worry about if they are doing it right based on red numbers showing up in places like the block explorer.
Hired by blockchain | Developer
delegate: dev.sidhujag

Offline theoretical

Wouldnt the attacke[r] require to dip multiple markets with high volume .. at least my script takes volume into account .. so that would be a rather expenive attack ...

Yeah, the attacker would take losses in the beginning, but the point is that the volume from triggered cover orders would be way bigger than the volume on the exchanges, so the attacker would be able to recoup his losses and overall get a profit.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
Wouldnt the attacke[r] require to dip multiple markets with high volume .. at least my script takes volume into account .. so that would be a rather expenive attack ...

Yeah, the attacker would take losses in the beginning, but the point is that the volume from triggered cover orders would be way bigger than the volume on the exchanges, so the attacker would be able to recoup his losses and overall get a profit.

Isn't that a free market ? The "attacker" is just trading and this influences the price. Regardless of his intentions. In any case everyone is free to add more collateral.

Any entity with sufficient capital can manipulate the market regardless of the feed frequency or other rules.

Offline svk

bitsharesblocks shows red if your feed is too slow like under 10 times a minute or something... so as a delegate you assume you need a fast update time.. look at mine its topping 200! (I thought its a good thing) but on second thought maybe it should be reduced, the scripts themselves set the update intervals to random numbers and minimum amount of movement to random percentage std dev around 5-10% and adjusted 5-10% either way. That way there are less things to configure for delegates and they dont have to worry about if they are doing it right based on red numbers showing up in places like the block explorer.

It's green for a frequency >= 24 = 1 update per hour. A few months back there were some discussions about this and I believe it was BM who said feeds should be updated at least that often. The scripts we had back then were not as sophisticated as they are now though, so it's probably ok to soften that requirement.
Worker: dev.bitsharesblocks

Offline bytemaster

bitsharesblocks shows red if your feed is too slow like under 10 times a minute or something... so as a delegate you assume you need a fast update time.. look at mine its topping 200! (I thought its a good thing) but on second thought maybe it should be reduced, the scripts themselves set the update intervals to random numbers and minimum amount of movement to random percentage std dev around 5-10% and adjusted 5-10% either way. That way there are less things to configure for delegates and they dont have to worry about if they are doing it right based on red numbers showing up in places like the block explorer.

It's green for a frequency >= 24 = 1 update per hour. A few months back there were some discussions about this and I believe it was BM who said feeds should be updated at least that often. The scripts we had back then were not as sophisticated as they are now though, so it's probably ok to soften that requirement.

It is important to confirm falling BTS price quickly but rising BTS price can be slow.  If you don't then shorts will execute below the real price. 

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline davidpbrown

On a related note, is there a risk having non-101 delegates publishing feeds? I just wonder that it would be a trivial attack to setup a rush of bad feeds..
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline emski

  • Hero Member
  • *****
  • Posts: 1283
    • View Profile
    • http://lnkd.in/nPbhxG
On a related note, is there a risk having non-101 delegates publishing feeds? I just wonder that it would be a trivial attack to setup a rush of bad feeds..
non-101 delegate feeds are recorded but ignored for median calculations.

Offline liondani

On a related note, is there a risk having non-101 delegates publishing feeds? I just wonder that it would be a trivial attack to setup a rush of bad feeds..
non-101 delegate feeds are recorded but ignored for median calculations.

I think it would be great that they would not get ignored, at least not from place 101-151 for example ...
I don't see an easy attack in that case since these places demands some voting power also (and the numbers will normally  increase in future....

Another solution would maybe be to have a penalty of a 5% reduce on the pay rate for 2-3 days(?) or better to reduce the payrate to zero for the time they fall below a threshold of 24 feeds per day and get only back if they publish feeds again above this threshold (?)  And this penalty could go to delegates on place 101-151 if they publish feeds....
  https://bitshares.OPENLEDGER.info/?r=GREECE  | You are in Control | BUY | SELL | SHORT | SWAP | LOAN | TRADE |  

Offline davidpbrown

...And this penalty could go to delegates on place 101-151 if they publish feeds....

Slightly off topic but for those of us stuck outside the 101, there comes a point where we will wonder why should we run delegates?.. If those 102-151 are reserves on the bench, then that is fine but perhaps they could be paid for feeds by way of incentive?.. then included in those where votes matter. Otherwise we might have a sudden discontinuity in quality at 102 and when a change is wanted there won't be good options to vote in.

My BTS delegate with vote% stuck at ~158, perhaps may never be useful? :|
฿://1CBxm54Ah5hiYxiUtD7JGYRXykT5Z6ZuMc

Offline Chronos

if everyone's publishing price feeds very frequently, the cost to manipulate the feed is small -- the attacker can simply dump BTS on exchanges, causing a dip in the price feed, then sell much larger BitUSD holdings into margin calls at artificially high prices.
If price feeds are not updated frequently, the cost to attack is even smaller. Simply wait for the feed to get out of sync with the market, and then take advantage of the gap.

I don't think a solution could be less frequent or randomized feeds, because this would make gaps more common.

Offline carpet ride

  • Hero Member
  • *****
  • Posts: 544
    • View Profile
Interesting issue.  Alternatively, do we plan on eliminating price feeds at some point?


Sent from my iPhone using Tapatalk
All opinions are my own. Anything said on this forum does not constitute an intent to create a legal obligation between myself and anyone else.
Check out my blog: http://CertainAssets.com
Buy the ticket, take the ride.

Offline Ander

  • Hero Member
  • *****
  • Posts: 3488
    • View Profile
  • BTS: Ander
Interesting issue.  Alternatively, do we plan on eliminating price feeds at some point?

No, the peg cannot operate without feeds.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

 

Google+