Author Topic: Does publishing feeds too frequently harm the network?(喂价太快会伤害网络吗?)  (Read 4185 times)

0 Members and 1 Guest are viewing this topic.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Interesting issue.  Alternatively, do we plan on eliminating price feeds at some point?

No, the peg cannot operate without feeds.
It could .. once the liquidity in a market is large enough ..

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: 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

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

  • Hero Member
  • *****
  • Posts: 3737
  • Inch by inch, play by play
    • View Profile
    • My detailed info
  • BitShares: liondani
  • GitHub: 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....

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • 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 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 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 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 emski

  • Hero Member
  • *****
  • Posts: 1282
    • 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 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 jsidhu

  • Hero Member
  • *****
  • Posts: 1335
    • 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 xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: 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

Offline Ander

  • Hero Member
  • *****
  • Posts: 3506
    • View Profile
  • BitShares: 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