BitShares Forum
Main => General Discussion => Topic started by: Markus on September 11, 2014, 10:21:21 am
-
We have lots of BitAssets on the blockchain that are waiting to be traded for the first time. All it needs are price feeds and a few orders. It would be nice if some delegates started publishing those feeds. I think the orders will then follow suit as the min depth requirement was substantially reduced to 500 kBTSX on either side of the market.
This is what's missing.
Commodities
BitGLD (Gold) trading since 28 September 2014
BitSLV (Silver) 22 valid feeds
BitWTI (Oil)
Crypto
BitPTS (BitsharesPTS) 22 valid feeds
BitLTC (Litecoin) 22 valid feeds
BitPPC (Peercoin) 22 valid feeds
Fiat
BitAUD (Australian Dollars) 22 valid feeds
BitCAD (Canadian Dollars) 22 valid feeds
BitCHF (Swiss Francs) 22 valid feeds
BitEUR (Euros) 34 valid feeds
BitGBP (Pounds Sterling) 22 valid feeds
BitHKD (Hong Kong Dollars) 22 valid feeds
BitJPY (Japanese Yen) 22 valid feeds
BitMXN (Mexican Pesos) 22 valid feeds
BitNZD (New Zealand Dollars) 22 valid feeds
BitRUB (Russian Rubles) 22 valid feeds
BitSEK (Swedish Kronor) 22 valid feeds
BitSGD (Singapore Dollars) 22 valid feeds
BitTRY (Turkish Lira) 22 valid feeds
edit: I'll try to keep the current market status up to date. Live data is available here: http://bitsharesblocks.com/assets
-
+5%
-
let us first settle down .. make sure there are no flaws anywhere left ..
give the devs some time to fix bugs and most importantly:
give the devs some freedom to breath!!
We will go there soon ... but not too early ...
-
let us first settle down .. make sure there are no flaws anywhere left ..
give the devs some time to fix bugs and most importantly:
give the devs some freedom to breath!!
We will go there soon ... but not too early ...
The good thing is, this doesn't need extra dev time.
Delegates, if you want more votes, please publish feeds.
-
can we first convince the world, that the peg is holding and prepare our marketing posters ... that way people can buyin and prepare for other markets
-
for some reason.. running the experiment with an actual commodity i.e BitGLD seems riskier.. but It would be great to have BitGLD as soon as possible. since gold is down 50 dollars this week, some in the crypto community must see this as a buying opportunity and it would be nice to have a liquid virtual gold market. Right now the IOU's on ripple have very little volume. RippleSingapore since january has only issued 52 XAU total. and Gold Bullion International since july: 12 XAU.
-
*bump*
I am not sure to how to proceed with new feeds .. maybe I will talk about this the evening @ the mumble handout session
some more opinions on this?
I know some have already started publishing a feed for the EUR ..
i.e., https://bitsharestalk.org/index.php?topic=6406.msg114296#msg114296
-
My vote goes with holding off until the client is stable and the yield is sorted.
Having one/two assets (bitUSD/bitBTC) to focus on speeds this process up.
Once there is one solid peg in place the other assets can be bootstrapped very quickly.
-
From the mumble session currently ongoing, BM and I3 is all fine with launching new assets at will ..
I would call that a GO!
BM explicitly told us that I3 has no interest in dictating when to launch new assets
-
That's good news.
I think we need feeds before the first orders can be placed. For example shorting GLD right now with 0.4.14 (Win7) I get this error and no order is placed.
10 assert_exception: Assert Exception
median_delegate_price.valid():
{}
bitshares market_operations.cpp:191 bts::blockchain::short_operation::evaluate
-
At some point I would like to buy the oil asset. Would these additional assets have a dividend structure like BitUSD?
-
At some point I would like to buy the oil asset. Would these additional assets have a dividend structure like BitUSD?
you would get a yield ... no dividend ..
-
At some point I would like to buy the oil asset. Would these additional assets have a dividend structure like BitUSD?
you would get a yield ... no dividend ..
I think that's what I meant, just used the wrong word. I'll definitely be interested in buying / trading this then. Perhaps gold too. Thanks.
-
I think that's what I meant, just used the wrong word. I'll definitely be interested in buying / trading this then. Perhaps gold too. Thanks.
I have a feeling GLD will be next .. some feeds already out there .. will add mine once the new release-candidate is running
-
I think that's what I meant, just used the wrong word. I'll definitely be interested in buying / trading this then. Perhaps gold too. Thanks.
I have a feeling GLD will be next .. some feeds already out there .. will add mine once the new release-candidate is running
Cool, looking forward to it. I'm not especially bullish on fiat, especially the USD which is slowly loosing its reserve currency status, so even with the yield I'd rather have Bitcoins. But being able to put a bit of money into commodities which I think will rise in value and get a yield on top of that is quite exciting to me.
-
I encourage all active delegates to start publishing Gold price feeds...
What are you waiting for? ;)
(http://thumbs.dreamstime.com/x/gold-3d-robotic-hand-thumb-up-9373958.jpg)
-
and bitEUR
https://bitsharestalk.org/index.php?topic=8862.0
-
BitGLD is half way there. We need 51 feeds to start trading.
-
Has there been any discussion yet about whether it's better to have BitGLD and BitSLV or BitGold and BitSilver? The reason I ask is because "GLD" is the SPDR gold shares ETF and "SLV" refers to the iShares silver trust ETF. Obviously, the ETF prices are quite different from the physical metal prices. For example, the price of gold is about $1,250 per ounce, while the price of GLD is about $118.38 per share.
Quite a few precious metals "experts" have argued that the paper asset ETFs GLD and SLV do not provide as much security as the physical metals because (1) the ETFs may not be backed by as much physical bullion as they advertise; and (2) in a real economic/financial catastrophe, the paper prices could decouple from the physical prices and become basically worthless.
So, should the new Bitassets aim to track ETF per-share prices (BitGLD and BitSLV), or should they track per-ounce physical prices (BitGold and BitSilver) instead? It could be argued that the latter would be safer and more useful for those seeking to hedge against a real monetary or financial crisis.
-
The price Gold and Silver are supposed to track is definitely one ounce of physical metal, not any ETF.
I would prefer calling them BitXAU and BitXAG anyway - that way there is no language bias applied.
-
The price Gold and Silver are supposed to track is definitely one ounce of physical metal, not any ETF.
I would prefer calling them BitXAU and BitXAG anyway - that way there is no language bias applied.
Right, they shouldn't be named BitGLD and BitSLV. Those names would cause too much confusion among people familiar with the ETFs.
-
This is the purpose of the description field. It should be improved to 1 full sentence for all assets and be displayed more prominently.
Sent from my SCH-I535 using Tapatalk
-
We've got the first feeds for silver and all(!) other fiat currencies - great job.
Delegates, if you've already got feeds for gold and USD, it shouldn't be much trouble setting up the others.
If you're using alt's script please check in this thread how to: https://bitsharestalk.org/index.php?topic=7787.0;all
-
I bet I own bitGOLD the next 2 days! ;)
-
37 feeds
So close!
-
I haven't time atm.. where is the ELI5 of publishing feeds?
-
I haven't time atm.. where is the ELI5 of publishing feeds?
instructions are here, very simple:
https://github.com/Bitsuperlab/operation_tools/tree/master/btsxfeed
-
From another thread:
can we hold off on opening new markets for a week?
-
A week has passed.
New shorting rules are active that will make small markets more stable.
Coinmarketcap has an Assets section that needs to be filled.
… how about you delegates give it a shot and add some more feeds. Only 17 missing for BitGLD.
-
I might have another look at this later..
I'm wondering the benefit of being a standby delegate.. and the risk to markets of those being core support to these market feeds. Surely it's most important that the 101 and those bidding for a place in that small clique, do publish all feeds? I'm unclear why publishing feeds is not part of being a delegate. Expect I'm missing something.. the simpler it is the more likely it'll be taken up..
-
svk who runs this site (http://bitsharesblocks.com/delegates (http://bitsharesblocks.com/delegates)) plans to add a column for feed performance of the delegates.
I assume that with this information readily available delegates not publishing enough feeds will be voted out quickly.
-
IMHO publishing feeds is as crucial for delegates as keeping the software up-to-date. It's their job and they get paid for it!
-
I don't think publishing feeds for shallow markets is a good idea.
If there is not enough (honest) market depth the market is easily manipulated.
Delegates aren't supposed to blindly publish feeds.
-
hmm .. markets start with 500k BTSX on both sides .. not once 51 feeds are published ..
also the feeds take external sources .. not sure how you can manipulate a low-liquid market with this ..
-
GLD is closest to launch given the statistics.
The whole GLD sell depth is a single short at double the real price.
Is that a market?
-
No it's not .. but you don't need to trade for twice the price ..
I can remember when cryptsy starts trading new shitcoins .. they always start with ridiculous prices hoping for a fool/bot to take the order.
I am not sure if it's an issue of the asset or the delegates/feeds that people can get fooled .. further, anybody can short at reasonable prices once the market is open .. so I don't think this scenario will persist for long.
-
GLD is closest to launch given the statistics.
The whole GLD sell depth is a single short at double the real price.
Is that a market?
This is a bug in the GUI. What is actually the offered collateral ratio is displayed as the price. If you check the console the limit for this short is actually 38000 - and that is even a few per cent below the peg. And it overlaps with a small buy order at 40000. As you can see, there is a market and feeds are the only thing preventing this trade from happening. (The min market depth requirement was abolished I thought)
>> blockchain_market_list_shorts GLD
AMOUNT COLLATERAL RATIO COLLATERAL PRICE LIMIT ID
================================================================================================================================
1.000000 GLD 80000 80,000.00000 BTSX 38000. GLD / BTSX c58e39bb558e08cc6a4ca2e7c3124c97b1910f4c
-
There is a bug in the current market engine that prevents orders from being matched against the short wall if they are the first order in a block to match. This bug has been fixed along with a handful of other small issues that are fixed in 0.4.17-RC2 and scheduled to take effect in 24 hours assuming RC2 testing passes and 0.4.17 is officially tagged.
-
The price Gold and Silver are supposed to track is definitely one ounce of physical metal, not any ETF.
I would prefer calling them BitXAU and BitXAG anyway - that way there is no language bias applied.
Right, they shouldn't be named BitGLD and BitSLV. Those names would cause too much confusion among people familiar with the ETFs.
It looks like it's still called BitGLD, is this going to be changed?
-
It looks like it's still called BitGLD, is this going to be changed?
The genesis block is set in stone .. don't thing it will or can be changed.
Even if it was possible, you don't like bitGLD?
-
It looks like it's still called BitGLD, is this going to be changed?
The genesis block is set in stone .. don't thing it will or can be changed.
Even if it was possible, you don't like bitGLD?
I've never been a trader of anything other than crypto so I'm far from an expert, but I would much prefer bitGOLD. Everyone knows automatically what that is, it's virtual gold, obviously. Dropping the "o" just seems pointless. People have to then ask, 'what's bitGLD, does that stand for gold?' Gold is short enough a word. bitGOLD conjoures the image of gold, it's an awesome name, bitGLD is a step away from the actual thing, an abstraction. One of the great things about bitassets is the name, just the real thing with 'bit' in front of it. I'd be worried about holding bitGLD just because it sounds weird (though I may be foolish to feel that way).
-
there is still a description for each an every asset
{
"id": 7,
"symbol": "GLD",
"name": "Gold",
"description": "1 troy ounce .999 fine gold",
"public_data": "",
"issuer_account_id": -2,
"precision": 1000000,
"registration_date": "20140719T000000",
"last_update": "20140719T000000",
"current_share_supply": 0,
"maximum_share_supply": 1000000000000000,
"collected_fees": 0
}
-
It looks like it's still called BitGLD, is this going to be changed?
The genesis block is set in stone .. don't thing it will or can be changed.
Even if it was possible, you don't like bitGLD?
I've never been a trader of anything other than crypto so I'm far from an expert, but I would much prefer bitGOLD. Everyone knows automatically what that is, it's virtual gold, obviously. Dropping the "o" just seems pointless. People have to then ask, 'what's bitGLD, does that stand for gold?' Gold is short enough a word. bitGOLD conjoures the image of gold, it's an awesome name, bitGLD is a step away from the actual thing, an abstraction. One of the great things about bitassets is the name, just the real thing with 'bit' in front of it. I'd be worried about holding bitGLD just because it sounds weird (though I may be foolish to feel that way).
I would imagine its name came from this (which I think it more closely resembles over the real thing):
http://finance.yahoo.com/q?s=GLD
-
instructions are here, very simple:
https://github.com/Bitsuperlab/operation_tools/tree/master/btsxfeed
I'm not convinced it's so simple.. ::)
In Linux, it wanted a dependency of python_requests; and detailing exactly how to combine the sample json and the existing config would be useful for json noobs.
Running the qt seems to validate; recreate; or edit the config.json and that removes the updated detail for bts_rpc etc, which is a surprise.
It seemed to be working using the client, though I didn't get to the point of seeing feeds because in trying to then run the usual qt client in parallel clashed and had it throw a locked database error. I haven't time to battle with that just now.
Is it possible to run client and qt together?.. would be surprised if not. Is it possible to run the qt with feeds being broadcast or must that be a client only?
-
I don't think we should rush to start too many markets. Starting a market is a pretty big commitment. Every market makes the delegate job more difficult by making them publish more feeds and it's better if all delegates don't rely on the same automated script to publish feeds. I am opposed to starting any more "crypto" type markets... I don't see any point to bitLTC bitNXT etc. I don't even see a whole lot of reason/need for bitBTC.
A very small number of solid liquid markets is best at the moment, wait until the assets are really useful and people really have a desire for more. Don't do something just to do it because I don't think we have agreed on a way to stop/unwind/retire support for a market. As long as there are a few people holding on to some random asset you sort of owe it to them to keep a feed in place. Worst case we could probably discontinue a market by giving a lot of notice and saying all shorts will be closed and bitassets credited BTSX at feed price but this will probably look bad.
-
I don't think we should rush to start too many markets. Starting a market is a pretty big commitment. Every market makes the delegate job more difficult by making them publish more feeds and it's better if all delegates don't rely on the same automated script to publish feeds. I am opposed to starting any more "crypto" type markets... I don't see any point to bitLTC bitNXT etc. I don't even see a whole lot of reason/need for bitBTC.
A very small number of solid liquid markets is best at the moment, wait until the assets are really useful and people really have a desire for more. Don't do something just to do it because I don't think we have agreed on a way to stop/unwind/retire support for a market. As long as there are a few people holding on to some random asset you sort of owe it to them to keep a feed in place. Worst case we could probably discontinue a market by giving a lot of notice and saying all shorts will be closed and bitassets credited BTSX at feed price but this will probably look bad.
+5%
-
I don't think we should rush to start too many markets. Starting a market is a pretty big commitment. Every market makes the delegate job more difficult by making them publish more feeds and it's better if all delegates don't rely on the same automated script to publish feeds. I am opposed to starting any more "crypto" type markets... I don't see any point to bitLTC bitNXT etc. I don't even see a whole lot of reason/need for bitBTC.
A very small number of solid liquid markets is best at the moment, wait until the assets are really useful and people really have a desire for more. Don't do something just to do it because I don't think we have agreed on a way to stop/unwind/retire support for a market. As long as there are a few people holding on to some random asset you sort of owe it to them to keep a feed in place. Worst case we could probably discontinue a market by giving a lot of notice and saying all shorts will be closed and bitassets credited BTSX at feed price but this will probably look bad.
I completely agree with every sentence except the bold ones.
-
I don't think we should rush to start too many markets. Starting a market is a pretty big commitment. Every market makes the delegate job more difficult by making them publish more feeds and it's better if all delegates don't rely on the same automated script to publish feeds. I am opposed to starting any more "crypto" type markets... I don't see any point to bitLTC bitNXT etc. I don't even see a whole lot of reason/need for bitBTC.
A very small number of solid liquid markets is best at the moment, wait until the assets are really useful and people really have a desire for more. Don't do something just to do it because I don't think we have agreed on a way to stop/unwind/retire support for a market. As long as there are a few people holding on to some random asset you sort of owe it to them to keep a feed in place. Worst case we could probably discontinue a market by giving a lot of notice and saying all shorts will be closed and bitassets credited BTSX at feed price but this will probably look bad.
This, and I also don't want to see too many variables change at once. 0.4.17 brought a bunch more new changes to the market, let's let the established markets do their thing for a couple of days (at least) before throwing more onto the fire
-
I don't think we should rush to start too many markets. Starting a market is a pretty big commitment. Every market makes the delegate job more difficult by making them publish more feeds and it's better if all delegates don't rely on the same automated script to publish feeds. I am opposed to starting any more "crypto" type markets... I don't see any point to bitLTC bitNXT etc. I don't even see a whole lot of reason/need for bitBTC.
A very small number of solid liquid markets is best at the moment, wait until the assets are really useful and people really have a desire for more. Don't do something just to do it because I don't think we have agreed on a way to stop/unwind/retire support for a market. As long as there are a few people holding on to some random asset you sort of owe it to them to keep a feed in place. Worst case we could probably discontinue a market by giving a lot of notice and saying all shorts will be closed and bitassets credited BTSX at feed price but this will probably look bad.
Agree, a solid bitUSD with millions or billions in market cap is more useful than a bunch of smaller assets.
-
By the way, in order to increase diversity of updates you may want to check out my feed script:
It was based on alt's script but I essentially modified everything :)
https://github.com/xeroc/pytshares/blob/master/btsx_feed.py
-
Agree, a solid bitUSD with millions or billions in market cap is more useful than a bunch of smaller assets.
+5%
-
By the way, in order to increase diversity of updates you may want to check out my feed script:
It was based on alt's script but I essentially modified everything :)
https://github.com/xeroc/pytshares/blob/master/btsx_feed.py
I would love to run your feed script and help to provide a level of feed diversity. Does my delegate need to make it to the top 101 to be able to provide feeds?
-
By the way, in order to increase diversity of updates you may want to check out my feed script:
It was based on alt's script but I essentially modified everything :)
https://github.com/xeroc/pytshares/blob/master/btsx_feed.py (https://github.com/xeroc/pytshares/blob/master/btsx_feed.py)
Cool, I'll give it a try. Why did you comment out Biitrex?
-
I would love to run your feed script and help to provide a level of feed diversity. Does my delegate need to make it to the top 101 to be able to provide feeds?
yes you need to haven active delegate
-
Cool, I'll give it a try. Why did you comment out Biitrex?
there rpc api is shit and I could finish that part yet ... dont' uncomment it .. it wont work ..
Maybe I can work on it later
-
Just pimped the script .. bittrex is available now two .. however only btc to ltc and btsx are available from there
-
So, the only way I could see to get this running alongside the GUI was to host a config for the feed.py script separate from the config that the GUI looks to. I'm running https://github.com/Bitsuperlab/operation_tools/tree/master/btsxfeed ok and hoping that is visible and then useful.
I'd like to run xeroc's script to see that but what Linux package provides for Python's 'import statistics'?
-
it's a part of python3 .. do not try to use python2 ..
-
Thanks.. Just to note for Linux Mint, changing default python is a bad idea, as it could break the system.
So, easy fix is alter script to start with #!/usr/bin/env python3
Unfortunately, only that change doesn't see the script work for me.. it barfs:
================================================================================
Loading old feeds
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 542, in urlopen
body=body, headers=headers)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 367, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/lib/python3.4/http/client.py", line 1065, in request
self._send_request(method, url, body, headers)
File "/usr/lib/python3.4/http/client.py", line 1103, in _send_request
self.endheaders(body)
File "/usr/lib/python3.4/http/client.py", line 1061, in endheaders
self._send_output(message_body)
File "/usr/lib/python3.4/http/client.py", line 906, in _send_output
self.send(msg)
File "/usr/lib/python3.4/http/client.py", line 841, in send
self.connect()
File "/usr/lib/python3.4/http/client.py", line 819, in connect
self.timeout, self.source_address)
File "/usr/lib/python3.4/socket.py", line 509, in create_connection
raise err
File "/usr/lib/python3.4/socket.py", line 500, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 330, in send
timeout=timeout
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 592, in urlopen
raise MaxRetryError(self, url, e)
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='localhost', port=9989): Max retries exceeded with url: /rpc (Caused by <class 'ConnectionRefusedError'>: [Errno 111] Connection refused)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "./xeroc_btsx_feed.py", line 382, in <module>
fetch_from_wallet()
File "./xeroc_btsx_feed.py", line 242, in fetch_from_wallet
response = requests.post(url, data=json.dumps(request), headers=headers, auth=auth)
File "/usr/lib/python3/dist-packages/requests/api.py", line 88, in post
return request('post', url, data=data, **kwargs)
File "/usr/lib/python3/dist-packages/requests/api.py", line 44, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 383, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3/dist-packages/requests/sessions.py", line 486, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 378, in send
raise ConnectionError(e)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='localhost', port=9989): Max retries exceeded with url: /rpc (Caused by <class 'ConnectionRefusedError'>: [Errno 111] Connection refused)
User Error: Replace User :/
-
you cannot connect to the RPC .. maybe I can add a failsafe ...
btw.. this script was mainly intended for me and I wanted to share .. :) give me some to to fix this
-
you cannot connect to the RPC .. maybe I can add a failsafe ...
Yes.. all this needs to be foolproof or we'll only have the core devs trying. I made a noob error not running the client properly. It seems that the GUI and client cannot run on the same machine, I don't understand why that is.. client does reindex where GUI had done that etc. I'm wondering then if I am just publishing feeds and not currently acting as delegate now, without the GUI running in the way that suggests that is delegate or if the client does the same delegate function by default.
-
you cannot connect to the RPC .. maybe I can add a failsafe ...
Yes.. all this needs to be foolproof or we'll only have the core devs trying. I made a noob error not running the client properly. It seems that the GUI and client cannot run on the same machine, I don't understand why that is.. client does reindex where GUI had done that etc. I'm wondering then if I am just publishing feeds and not currently acting as delegate now, without the GUI running in the way that suggests that is delegate or if the client does the same delegate function by default.
They can run on the same machine but not share a data directory.
-
So, is client running as server, providing the same services as a delegate; or can delegates only be run from the GUI?
-
So, is client running as server, providing the same services as a delegate; or can delegates only be run from the GUI?
the delegates should NEVER be run though the GUI ..
the core (bitshares_cli) has the exact same features .. except the fancy gui :)