|
total bid: 8,358,889 USD | total ask: 83,665 BTC | ratio: 99.91 USD/BTC
|
|
|
|
I'm a little bit disappointed because I have set up all my orders to buy a huge dip all the way down to 30 and now my evil plan does not play out as intended.
I hope you buy back in before it's way to late. Its only the mtgox-gamble-money, 90% of my money is BTC at home. |
|
|
|
|
I'm a little bit disappointed because I have set up all my orders to buy a huge dip all the way down to 30 and now my evil plan does not play out as intended.
|
|
|
|
|
total_ask reduced from >100000 BTC to 90000 BTC
total_bid unchanged 8.3 MUSD
total_bid/total_ask = 92 USD/BTC (never seen this number so high)
|
|
|
|
or redoing most of the work trying to reverse engineering the socketio server to use websockets. Bah!
If you have a working version for plain websocket already then it should be trivial to add the little socketio overhead on top of it without needing a complete socketio library. basically instead of just connecting to websocket.mtgox.com like you do it now you do the following: send a http request to socketio.mtgox.com (look for the example somewhere in this thread for the exact URL), parse the result to get the session ID which is part of your personalized websocket url and then you use *that* to do the websocket connect. The rest is adding (or removing) the "1::" and "4::/mtgox:" headers before/after send/receive and the rest stays the same, its effectively only a handful of code you have to add, you don't have to implement everything of socketio, just these few things, its actually simpler than it might seem. There was a python example near the beginning (or somewhere in the middle) of this thread that helped me a lot, and of course also the official socketio specification. |
|
|
|
...I'm not totally sure ...
There is a specification describing socket.io protocol. With "I'm not totally sure" I was referring to websocket framing (0xff and friends), not to socketio. For websocket there exists an RFC. Websocket is actually not the problem, client implementations exist for many languages. I actually just wanted to explain that these two MtGox servers are not the same and after writing down the bytes I realized that I might have forgotten some tiny details and therefore wanted to make clear that this is NOT a protocol specification, I just wrote it down as I remember it and so I wrote "I'm not totally sure" as a warning that it might be not 100% correct and nobody tries to implement something based on this posting. |
|
|
|
Thanks for confirming its not just me. I thought socketio was implemented on top of websockets though, so its weird that still works?
its a separate server. And on the socketio websocket all messages look like this: 0x00 "4::/mtgox:{a json message}" 0xff 0x00 "4::/mtgox:{another json msg}" 0xff and occasionally: 0x00 "2::" 0xff <-- this is a ping, must be answered with "2::" (I'm not totally sure about the 0xff 0x00 thing, there exist 13 different (no joke!) versions of websocket and there exist also different ways to delimit the messages, crazy stuff like: if bit7=1 then bit 0..6 = message length and when the next byte also has bit7=1 then its even more bits for the message length until a byte comes along that has bit7=0 but if all bits = 0 then its variable length ascii, 0xff terminated. Fortunately the binary stuff is abstracted away by libraries like websocket.py in Python and other client implementations for other languages, so usually you just have a send() and a recv() method and don't need to care about 0x00 and 0xff etc., only the socketio "1::", "2::" and "4::" must be done manually. The "/mtgox" part is some kind of "channel" name on the socketio layer but MtGox actually does not make any use of this feature, there is only one channel, the channels you subscribe *through* the websocket actually are an MtGox-internal thing, not part of the socketio layer. So there is some socketio protocol related stuff going on and wrapped around it that is not actually used for anything but its needed to satisfy the protocol rules. On the plain websocket server you just connect, send the request header and it immediately begins talking to you with no additional handshake or other overhead: 0x00 "{a json message}" 0xff 0x00 "{another json msg}" 0xff So its not the *same* websocket server (also it has a different hostname and IP address). Socketio is using websocket transport but a totally different handshake and protocol and framing. Either way, Ill make a HTTP fallback option. Do you know how often you can poll it? The documentation says no more than once per 10 seconds, but Im not sure if that is per request or for all requests (I need trades, depth, and ticker) ?
depth (fulldepth) definitely has a limit and I ran into this once while testing (and it tried to ban me from calling this API for 24 hours [getting a new IP address on my DSL line fixed it]). I don't know about the other APIs. |
|
|
|
is websocket service down? I can connected but I cant get any response (nor via telnet).
Clarkmoody and the other sites still seem to work though?
Yes, its down again (for almost 3 hours now [this is nothing, sometimes its down for a few days]). And in the 24/7 IRC support channel #mtgox on freenode (btw. why does a commercial company use freenode?) there is currently nobody answering any questions. Socketio works (clarkmoody is using socketio) but trading via the socketio server is no fun at all because of the 10 seconds lag (on top of the usual goxlag) even during quiet times and becomes totally unusable when there is some more action. |
|
|
|
by an artificially manipulated selling wall.
Everytime I see the word "manipulated" in such discussions to explain things that are not immediately explainable through the (always incomplete and often plain wrong) model of the fundamentalists I usually stop reading. Everything is "manipulated"! Even my small 5 BTC orders are manipulated because I created them manually with totally evil and egoistic intentions that others may lose and I may profit. These orders did not happen naturally. Its a market, thats how it works. Also I am not separating the charts and the fundamentals, quite the opposite, I regard the chart as the ultimate manifestation and the sum of *all* these influences, *BUT* I don't look at them separately because it is most often totally impossible to know exactly how strong each of them will affect price until after it has actually happened. Because I know my model is most likely plain wrong I don't use it at all! Using only the chart and the orderbook and trying to guess the subtle changes in market sentiment and the strength of bulls and bears from there alone and NOT trying to interpret any misunderstood/overvalued/underestimated/unknown fundamentals at all has made me a better trader during all these many years. |
|
|
|
|
This triangle is not bullish, if you look closely the upper line is slightly descending (and not ascending as you have wrongly painted it in your chart), it is trying hard to look bullish but failing to reach at least the previous level on each new attempt (and therefore failing to paint at least a horizontal upper line into the chart) is actually bearish, expect a serious drop (short term, buying opportunity) before it actually breaks the $50.
Note that this is not the ultimate reversal but its also not a continuation pattern. There will be a serious correction before it can continue.
|
|
|
|
One thing isnt clear to me. when a trade occurs. does the API also send a depth message that reflects this trade? Or do I need to subscribe to the trade channel as well and then match the trade with the orderbook to keep the orderbook up to date?
On trade messages you need to update the orderbook yourself, there will be no depth message. [ Edit: this is wrong, there is a depth message following every trade message but it can't do any damage if you always only use the total_volume and never use the volume difference] If the trade is type:"bid" then it has filled an ask order, update your asks, if trade is type:"ask" then it has filled a bid order, update your bids. On *own* trades there will be two trade messages: One public that everybody receives (like above), use that to update your orderbook like above and one private only to notify you about your trade that happened. Also on every trade that affects your *own* orders there will be user_order messages, at least one that sets the volume to the remaining volume (or zero and another one to finally remove it). [Edit: the code below is flawed (maybe even outright wrong: You should not use the volume difference in the depth message, you should use the total volume]WRONG WRONG WRONGdef on_trade(typ, price, volume, own):
typ_filled = {"ask":"bid", "bid":"ask"}[typ]
if own:
# do nothing as far as bookkeeping the order lists is concerned
# maybe notify your bot about this event, or notify the user.
pass
else:
update_orderbook(typ_filled, price, -volume)
def on_depth(typ, price, volume):
update_orderbook(typ, price, volume)
def on_user_order(oid, price, new_volume, new_status):
update_own_orders(oid, price, new_volume, new_status)
Here is a corrected version: you would have two methods updating the orderbook, one that accepts a delta and one that accepts the new total volume. def on_trade(typ, price, trade_volume, own):
typ_filled = {"ask":"bid", "bid":"ask"}[typ]
if own:
# do nothing as far as bookkeeping the order lists is concerned
# maybe notify your bot about this event, or notify the user.
pass
else:
update_orderbook_with_delta(typ_filled, price, -trade_volume)
def on_depth(typ, price, total_volumel):
update_orderbook_with_absolute(typ, price, total_volume)
def on_user_order(oid, price, new_volume, new_status):
update_own_orders(oid, price, new_volume, new_status)
def update_orderbook_with_delta(typ, price, delta_volume):
# do whatever is needed to update a price level,
# remove it if it is <= 0 after the update
[...]
def update_orderbook_with_absolute(typ, price, total_volume);
# do whatever is needed to update a price level to the new total_volume
# remove the level if total_volume == 0
[...]
And here is a simplified version that just waits for the inevitable depth message and completely ignores the trade message: def on_trade(typ, price, trade_volume, own):
if own:
# an own order has been filled (this is only received in the private channel)
# do nothing as far as bookkeeping the order lists is concerned
# maybe notify your bot about this event, or notify the user.
# the same message will be fired again with vol=False in the public
# channel like all other trade message too.
pass
else:
# a trade has happened on mtgox (this is the public message)
# do nothing as far as bookkeeping the order lists is concerned
# maybe log the message or notify your bot if it needs it
pass
def on_depth(typ, price, total_volumel):
update_orderbook_with_absolute(typ, price, total_volume)
def on_user_order(oid, price, new_volume, new_status):
update_own_orders(oid, price, new_volume, new_status)
def update_orderbook_with_absolute(typ, price, total_volume);
# do whatever is needed to update a price level to the new total_volume
# remove the level if total_volume == 0
[...]
|
|
|
|
|
This might be a dumb question but I wonder how does this work:
Say for example there are two different exchanges (for example bitfunder and btct, these two I have found accidentally through some quick google search, lets call them A and B) and a company XYZ has issued a number of nnn shares in total and they are traded on both exchanges.
* how do (some of) these shares initially end up at A or B where the investors can buy them
* If I buy 100*XYZ at A, can I move them to B and sell them at B (or can I completely take them home with me and/or sell them elsewhere/offline or here in the forum (I have seen at least one thread here where they traded ASICMINER shares here in the forum and at the same time I also see ASICMINER shares being traded at aforementioned exchanges A and B)?
* who keeps track of who owns how many shares (globally because there (should) exist only nnn of them), is there some global registry, what if some exchange decides to sell more shares than they have? Is there some established protocol that solves the double-spending problem for these shares that all these exchanges implement? How does this work?
* Is there a list of such exchanges?
|
|
|
|
What's wrong with bitcoin? One wall can stop everything??
What is stopped? Bitcoin is working just fine. |
|
|
|
I'ld really wish this guy would put his charts with ask in USDs too (# of BTCs * price/BTC)
This doesn't make sense. On the ask side they are selling BTC, on the bid side they are selling USD. Its perfectly natural and intuitive to denominate the amount of BTC that are up for sale in BTC and the amount of USD that are up for sale in USD. Besides one could sell 1 BTC for 100.000.000 and completely invalidate the whole graph if it was USD on both sides. Exactly. If one would multiply the amount of $thing that is up for sale with some wishful thinking $price of the seller then all you get are meaningless phantasy numbers. If you instead just count the number of $thing that is up for sale without any price you always get the same exact amount of $thing that is actually currently available on this market, no matter how much its seller actually wants for it today. |
|
|
|
I'ld really wish this guy would put his charts with ask in USDs too (# of BTCs * price/BTC) This doesn't make sense. On the ask side they are selling BTC, on the bid side they are selling USD. Its perfectly natural and intuitive to denominate the amount of BTC that are up for sale in BTC and the amount of USD that are up for sale in USD. |
|
|
|
if i had $2million to buy btc and was a bull I'd just set up a bot to buy 25 BTC every 10 minutes and let it run for a week or two. An experienced trader who knows how price usually moves would just put his bid at $30 and wait. |
|
|
|
The graphs do look suspiciously like the $5 rate did just prior to the big crash way back then.
The graphs remind me of XAG/USD in 2010-2011, the way it suddenly started rising in a straight line for a few months (straight line on the semi log chart). Even the numbers match: It went to *almost* 50 and then crashed down into the 30's and stayed there (thats where the huge 1Million bid is sitting). Same type of Market forces at work? Edit: and it crashed on a Friday if I remember correctly (I even mentioned this possibility on one of these not-so-serious trading forums a few hours(!) before it happened, then shorted silver, called Tyler Durden from ZH an idiot, switched off my PC and the next day I looked at the chart it was crashed (the price, not my PC). |
|
|
|
This is too extreme, last week it was below 5 Million, yesterday it was 7.5 now its 8.2. (and the ratio was 50 last week, now its over 75) This is rising too fast! Something extreme is about to happen. Has anybody noticed where these dollars are added? Are they spread evenly across the book or do they accumulate at a certain level?  |
|
|
|
Yeah, I'm seeing this to. Also seeing "invalid call".
I have had invalid call before i changed the way my nonce was created. Now I'm just using 8 bytes from urandom to make a 64 bit integer and no invalid calls anymore, before i used something like time.Time()*1E6 and saaw a lot of "invalid call" Thanks, I'll try this out. The documentation and PHP example code led me to believe that the nonce needs to increment for each message. STOP forget everything I just wrote about the nonce, I had a bug in my program (I used struct.unpack() which creates a tuple and put that tuple with the random number into my json instead of only the nonce). And the mtgox-server also has a bug so that it *accepts* this without complaining! It will *not* accept it if the nonce is a plain random number and not incrementing. And it will never forget, you need a new API key after the change. I have just spent another hour with my code and now my code look like this, I also requested a brand new virgin API key and now it works: def send_signed_call(self, api_endpoint, params, reqid):
"""send a signed (authenticated) API call over the socket.io.
This method will only succeed if the secret key is available,
otherwise it will just log a warning and do nothing."""
if (not self.secret) or (not self.secret.know_secret()):
self.debug("### don't know secret, cannot call %s" % api_endpoint)
return
key = self.secret.key
sec = self.secret.secret
nonce = str(int(time.time() * 1E6))
call = json.dumps({
"id" : reqid,
"call" : api_endpoint,
"nonce" : nonce,
"params" : params,
"currency" : self.currency,
"item" : "BTC"
})
# pylint: disable=E1101
sign = hmac.new(base64.b64decode(sec), call, hashlib.sha512).digest()
signedcall = key.replace("-", "").decode("hex") + sign + call
self.debug("### calling %s" % api_endpoint)
self.send(json.dumps({
"op" : "call",
"call" : base64.b64encode(signedcall),
"id" : reqid,
"context" : "mtgox.com"
}))
you find it at github: prof7bit/goxtool |
|
|
|
Yeah, I'm seeing this to. Also seeing "invalid call".
I have had invalid call before i changed the way my nonce was created. Now I'm just using 8 bytes from urandom to make an unsigned 64 bit integer and not one invalid calls anymore since the day I made that change, before i used something like time.time()*1E6 and saw a lot of "invalid call". One day I'm going to investigate what exactly it was that was wrong with my microseconds and why it works now. The socketio server only accepts the socketio protocol (http request, then get a session ID, then use that ID to have a new URL to connect to a websocket service but this is not the same websocket as the plain old websocket, all messages are wrapped into some socketio protocol ("1::/mtgox" headers and the like). This is a whole new complicated layer on top of websocket. According to the person I just talked to the plain websocket server is NOT (I repeat: NOT) deprecated, we can use it! Its also 10 seconds faster (no annoying lag, no sluggishness), reacts instantly to all commands. |
|
|
|
|
Show Posts
