BitShares Forum
Main => General Discussion => Topic started by: Shentist on February 01, 2015, 09:53:58 am
-
I am curious why so many 100% delegate don't provide feeds. Without feeds our decentralized exchange will not operate, so it is a really important task.
So why do this 100% delegates don't provide feeds?
1. dev-trial.misc.nikolai
2. dev0.nikolai
3. elmato
4. developer.vikram
5. media.bitscape
6. delegate-dev1.btsnow
7. delegate-dev2.btsnow
8. dev0.theoretical
9. delegate.rgcrypto
10. dev.nathanhourt.com
11. delegate-dev3.btsnow
12. delegate-dev4.btsnow
why are so many core developer in this group?
-
I noticed this too.
I understand that some delegates can't but I wouldn't have thought it would be too hard for devs.
-
https://www.quandl.com/c/markets/crude-oil
Daily feed better than no feed at all?
-
Estimation is trying to save a little fee.
-
I am curious as well :).
-
Feed price is the basic responsibility of delegate,right?
-
I think this is a very important observation of how the current system allows delegates to drop responsibilities safely because they're holding the skills they were hired to do hostage. Right now it's just price-feeds, but what else could happen in the future?
-
i would think legal concerns
-
I would like to point out that a number of these 100% delegates are not so technically inclined, but were voted up for their other contributions that would be funded by their delegate position.
Of all the information regarding delegate setup etc there really isn't much regarding feeds, and it is considered an optional element because of this I think.
I think rather than singling out the 100% delegates though, if you just make the feeds part of the standard for all delegates for their setup and provide clear documentation on that portion of the process, then it should fix itself.
Jonathan
-
I would like to point out that a number of these 100% delegates are not so technically inclined, but were voted up for their other contributions that would be funded by their delegate position.
Of all the information regarding delegate setup etc there really isn't much regarding feeds, and it is considered an optional element because of this I think.
I think rather than singling out the 100% delegates though, if you just make the feeds part of the standard for all delegates for their setup and provide clear documentation on that portion of the process, then it should fix itself.
Jonathan
I think there are a good number of people who can assist in setting up feeds. If majority of 3% delegates can set up and pay to publish feeds, there's really no reason for 100% delegates to not do so.
-
i would think legal concerns
if this is the case, we should come to a better solution. If more than 51 delegates have legal concerns we have no market at all. i would like to hear direct from some of this delegates what is the cause of not providing feeds?
-
I would like to point out that a number of these 100% delegates are not so technically inclined, but were voted up for their other contributions that would be funded by their delegate position.
Of all the information regarding delegate setup etc there really isn't much regarding feeds, and it is considered an optional element because of this I think.
I think rather than singling out the 100% delegates though, if you just make the feeds part of the standard for all delegates for their setup and provide clear documentation on that portion of the process, then it should fix itself.
Jonathan
I think there are a good number of people who can assist in setting up feeds. If majority of 3% delegates can set up and pay to publish feeds, there's really no reason for 100% delegates to not do so.
http://wiki.bitshares.org/index.php/Delegate/Feeds
-
http://wiki.bitshares.org/index.php/Delegate/Feeds
Ok.. no excuses I agree. :) +5%
-
i would think legal concerns
Yes, this could distract and burden the developers' mind.
-
I think this should be very simple. Rules should apply equally to any delegate, if you don't provide feeds you will be voted out. If you happen to be one of our core developers and are not providing feeds due to some legal reasons than get someone else to run delegate for you and pay them 3-5% as it is already being done by bytemaster and Stan. Unless there is some more serious reason for some of our developers not providing price feeds that we are not aware of we should start voting them out or we should get explanation from them why are they not doing very important part of the job they are being paid to do.
-
:'( +5% :'(
-
so far - no feedback from the mentioned delegates!!
-
so far - no feedback from the mentioned delegates!!
I will start removing my votes today from any delegate that does not publish price feeds. Feel terrible to do it as we need our great core developers, but if anybody has any better idea please enlighten me :).
-
Talked to Stan , he said no legal concerns involved . He will push them to publish feeds .
-
I'll publish feeds when I get around to making a UNIQUE feed script. Running another copy of alt's or xeroc's scripts adds no extra security (negative security due to false perceived security?) but makes me feel "done" with that task.
-
I'll publish feeds when I get around to making a UNIQUE feed script. Running another copy of alt's or xeroc's scripts adds no extra security (negative security due to false perceived security?) but makes me feel "done" with that task.
Can't we argue that some scripts can be compared to other scripts as objectively better? So stakeholders shouldn't want a poor script just because it is unique. I am sure there will be scripts that cannot be objectively compared because of some value judgement, but in that case we have a choice of having diversity in the value judgements made by these scripts or to just choose the scripts that make value judgements that is agreeable to most stakeholders (or perhaps proportional representation would be better?).
What I am trying to say is if we had one open source script that was really great (as in it would be hard to argue that any other script is better than this one) which takes the price of many different exchanges into account in a sensible way (factors in volume as well as a weight of the credibility of the exchange, which itself would somehow have to be communicated by the stakeholders to the delegates who actually set the weights in their scripts), what would be the issue if all 101 delegates use that one script? Is it a concern of putting all eggs in one basket in which a vulnerability found in the script could be exploited by whales manipulating the market in clever ways (I can't imagine the scripts are that complicated that we wouldn't quickly find nearly all of these vulnerability if we had many eyes looking at it). Or are you arguing for security through obscurity?
I think even if all 101 delegates were runnning that single uber script we would still have better security than if only 86 are running multiple scripts. For example, if 49 delegates were to collude to run a different script to, for example, profit from unfair margin calls, they would be able to seriously manipulate the median price in the BitUSD market right now. But if all 101 delegates were providing feeds (even if was through the same script), then that attack by the 49 colluding delegates would not be possible.
All of this isn't to say that I want the reduced stakeholder pressure from you providing feeds through alt or xeroc's script to prevent you from making your own awesome script. :)
-
Like Toast said, I'm not going to want to run the same script everyone else is. As far as I am concerned, every delegate should run a script with private customizations not publicly disclosed, it's much harder to game 101 different algorithms whose details are unknown, than it is to game a single published algorithm that everybody uses.
In addition, I'm not comfortable giving a third-party script access to my delegate's private key.
I've started writing a feed script, but I want to make sure it is rock solid. No feed at all is better than a feed script that's poorly tested.
But I am pretty busy doing actual work, and doing this is pretty far down on my list at the moment. Maybe after 1.0 is out.
-
As far as I am concerned, every delegate should run a script with private customizations not publicly disclosed, it's much harder to game 101 different algorithms whose details are unknown, than it is to game a single published algorithm that everybody uses.
So... security through obscurity?
In addition, I'm not comfortable giving a third-party script access to my delegate's private key.
They should definitely be audited by each delegate (another reason why it is important to separate concerns by making sure the person actually running the delegate is a tech person and not just a good worker for the DAC).
I've started writing a feed script, but I want to make sure it is rock solid. No feed at all is better than a feed script that's poorly tested.
I agree there.
-
just tweak the update rate and atleast provide some sort of feed.. we know devs are lazy but cmon
-
Lame excuses, which invariably sets a bad precedent. Part of being a delegate are these feeds.
Isn't the price feed market trading a 'core blockchain feature'?
My main area of interest is design and implementation of core blockchain features.
If you say you will do it, do it.
I will start publishing feeds just for this
-
They should definitely be audited by each delegate (_another reason why it is important to separate concerns_ by making sure the person actually running the delegate is a tech person and not just a good worker for the DAC).
This is a good point and should be a good practice for all 100% delegates.
-
I've started writing a feed script, but I want to make sure it is rock solid. No feed at all is better than a feed script that's poorly tested.
I'd like to pimp my script to "rock solid" too .. what are the missing points for that? Better exception handling? flexible exchange RPC parsing? are we even talking about code style or about doing the "calculation" right?
Can't we have one rock-solid script that pulls prices at individual times and use individual feed-publishing-rules and price calculated (weighted, non-weighted, set of exchanges, etc..)
Disclaimer: I am not selling my script here, just wanted to start a discussion about what degree of freedom is necessary
-
I'd like to pimp my script to "rock solid" too .. what are the missing points for that? Better exception handling? flexible exchange RPC parsing? are we even talking about code style or about doing the "calculation" right?
Can't we have one rock-solid script that pulls prices at individual times and use individual feed-publishing-rules and price calculated (weighted, non-weighted, set of exchanges, etc..)
Disclaimer: I am not selling my script here, just wanted to start a discussion about what degree of freedom is necessary
I am looking forward to a 'rock-solid' script too. This would raise standard across.
-
In my modification of xeroc's feed script each delegate is free to set weight to each exchange. Exchanges can even be ignored. It also accounts for relative volume between exchanges.
You could have unique configuration if you want to.
Current scripts were created in a hurry. There could be a lot of improvement over them. However they are tested and they seem to be working so far.
I think more important for security is that all delegates provide feeds regardless of the method. And then each delegate can customize and change or upgrade his script.
If there are 60 delegates publishing feeds (instead of 100) then smaller set of malicious delegates is needed to manipulate the median price.
-
In addition, I'm not comfortable giving a third-party script access to my delegate's private key.
I'm no genius in programming , but even I could spot a command that can get your private key if it's in the script .
It's really that simple .
-
In addition, I'm not comfortable giving a third-party script access to my delegate's private key.
I'm no genius in programming , but even I could spot a command that can get your private key if it's in the script .
It's really that simple .
Neither was I comfortable... That is why I reviewed and modified the script.
-
it should be a official basic feed script available/approved on the bitshares github
Sent from my ALCATEL ONE TOUCH 997D
-
In my modification of xeroc's feed script each delegate is free to set weight to each exchange. Exchanges can even be ignored. It also accounts for relative volume between exchanges.
You could have unique configuration if you want to.
Current scripts were created in a hurry. There could be a lot of improvement over them. However they are tested and they seem to be working so far.
I think more important for security is that all delegates provide feeds regardless of the method. And then each delegate can customize and change or upgrade his script.
If there are 60 delegates publishing feeds (instead of 100) then smaller set of malicious delegates is needed to manipulate the median price.
+5%