BitShares Forum
Main => General Discussion => Topic started by: Shentist on September 28, 2014, 05:50:13 pm
-
i don't like the idea that all the feeds are provided via the delegates, if we need them in the long run, i would like to have a different source of feeds.
why?
it looks like the delegates are not really incentived to do their "job" on the feed side. And i understand it and i don't see them to do it at all.
idea:
at the moment the trading bots are coming. what about to introducing "feed bots" to do the job of the delegates. maybe to vote them into power as well.
A feed bot has 2 jobs.
1. publish a feed from a selected source every hour once.
2. provide X amount "bids" orders with 1% difference to the ask/bid side of the average feed price
incentive for a feed bot owner
1. 10% of the trading fees are paid to them
2. if they are trading they have to pay 50% of the trading fee and not 100% (not much now)
with this change we could attract interested people to make a kind of market maker
what do you think?
-
I think we should first start down voting delegates that don't do there job properly
I mentioned already that some delegates seem to be too lazy while standby delegates most certainly are not.
-
why not punish delegates that do not do their job properly? I.e. charge them btsx that will go into the kitty as yield or something like that. Or even better that charge will go devided to charity delegates or any charity DAC we might have in the future
-
I think we should first start down voting delegates that don't do there job properly
I mentioned already that some delegates seem to be too lazy while standby delegates most certainly are not.
+5%
How do we do it? Is it by choosing thumbs down?
-
This my problem with posting feeds, it too hard to manually publish feeds on a consistent basis. So there's a script for this. Where is the bot's source for posting a feed? It pulls api from btc38 or some exchange. All delegates start using this, or you want all delegates to post feeds based on the same script as everything else. Tell me what is the difference from just hard coding the feed into the program?
-
we already have TWO different scripts which take DIFFERENT sources and do different operations on them ..
plus .. they are "simple" python scripts that can be modified to your needs/policies
-
This is a good example of why I think we will eventually have to add the ability to add arbitrary new "power roles" that have "write access" normal users don't, which could act as smart oracles, but which don't produce blocks. In the short term delegates make very good substitutes for this type of worker role.
-
we already have TWO different scripts which take DIFFERENT sources and do different operations on them ..
plus .. they are "simple" python scripts that can be modified to your needs/policies
If all delegates employ the same scripts, there will be no difference from the case that wallet embeds the price feed internally.
-
This my problem with posting feeds, it too hard to manually publish feeds on a consistent basis. So there's a script for this. Where is the bot's source for posting a feed? It pulls api from btc38 or some exchange. All delegates start using this, or you want all delegates to post feeds based on the same script as everything else. Tell me what is the difference from just hard coding the feed into the program?
Good point. Everyone looks at the major exchanges for BTSX. At the moment BTER and BTC38. In the future maybe this will change but it would be "insane" not to look to them as a ressource. 2 ressources with liquidity at the moment, not a bad thing, but clearly not decentralised. This is just the start.
-
we already have TWO different scripts which take DIFFERENT sources and do different operations on them ..
plus .. they are "simple" python scripts that can be modified to your needs/policies
If all delegates employ the same scripts, there will be no difference from the case that wallet embeds the price feed internally.
Exactly.
-
I'm going to start downvoting all delegates that dont maintain a feed by the end of the week.. giving them a bit more time to get their shit together
-
I think we should first start down voting delegates that don't do there job properly
I mentioned already that some delegates seem to be too lazy while standby delegates most certainly are not.
As a standby delegate, I tried to put in a feed but encountered error. So no go. Standby delegate cannot publish feeds.
I believe there are other standby delegates like me who are eager and capable to perform this role, and are waiting for the opportunity to be given. :)
-
Any delegates not publishing a feed will be voted out when I get back from Vegas.
-
Tell me what is the difference from just hard coding the feed into the program?
the difference is that some delegates (like me) are publishing feeds manually.
Sent from my ALCATEL ONE TOUCH 997D
-
I thought you couldn't downvote due to the "emski attack"? I went through all my votes and "unvoted" delegates who were not publishing BitGLD feeds. I no longer care about the pay rate, I just vote for delegates who maintain their feeds.
-
I thought you couldn't downvote due to the "emski attack"?
you still cannot downvote .. it's a feature that comes with slate voting .. If you were to vote as recommended by a delegate you can exclude some of his recommendations
http://wiki.bitshares.org/index.php/ApprovalVoting
-
So who's voting for all the init's?
-
some stakeholders :) ... who knows
-
They not publishing.. I assumed they were in control of i3 or dacsun. Not a good example... :O
-
They not publishing.. I assumed they were in control of i3 or dacsun. Not a good example... :O
*agreed*
-
They not publishing.. I assumed they were in control of i3 or dacsun. Not a good example... :O
*agreed*
If inits were publishing feeds that might cause significant centralisation. Inits were voted in because there were not enough delegates updated to current version.
Unless there are enough serious delegates willing to do their job - inits cannot be removed (without hurting the network).
Even now there are people (including me) running multiple delegates and still there aren't enough people willing and able to be decent delegates.
-
If inits were publishing feeds that might cause significant centralisation. Inits were voted in because there were not enough delegates updated to current version.
Unless there are enough serious delegates willing to do their job - inits cannot be removed (without hurting the network).
Even now there are people (including me) running multiple delegates and still there aren't enough people willing and able to be decent delegates.
Yes and no. I've only noticed the 're-rise' of the init's to the top 101 in the last day or three. I can see a good number of standby delegates below the 101 threshold that are advertising 0.4.18.
If whoever's responsible wants to make more btsx, that's fine. They own the stake and that's how the game works. I'm cool with that.
No need to make version excuses though. Active delegates have to upgrade or they'll be on a fork before they know it.
I find the truth ... cool. ;)
prob due to timezones, I was (one of) the first to make it to 0.4.18 RC1 according to bitsharesblocks.com.
-
If inits were publishing feeds that might cause significant centralisation. Inits were voted in because there were not enough delegates updated to current version.
Unless there are enough serious delegates willing to do their job - inits cannot be removed (without hurting the network).
Even now there are people (including me) running multiple delegates and still there aren't enough people willing and able to be decent delegates.
Yes and no. I've only noticed the 're-rise' of the init's to the top 101 in the last day or three. I can see a good number of standby delegates below the 101 threshold that are advertising 0.4.18.
If whoever's responsible wants to make more btsx, that's fine. They own the stake and that's how the game works. I'm cool with that.
No need to make version excuses though. Active delegates have to upgrade or they'll be on a fork before they know it.
I find the truth ... cool. ;)
prob due to timezones, I was (one of) the first to make it to 0.4.18 RC1 according to bitsharesblocks.com.
Init delegates were voted in just before v0.4.17 hardfork started. There weren't enough delegates that upgraded to 0.4.17 on time. Perhaps some of the delegates updated to 0.4.18 were slow/unreliable previously and that is why they weren't voted in. Its a free system - anyone can vote.
-
They own the stake and that's how the game works. I'm cool with that.
Check! Good to see we're on the same page.