Just to be clear, using UDP to broadcast ticker data would be, for all intents and purposes, IMMUNE from DDoS attacks
I guess there simply would not be be anything to broadcast during the times when the engine is down or when nobody can make any trades. It would broadcast only silence. Maybe it could broadcast "Help!!! Help!!! We're under attack!". |
|
|
|
The article is quite fair, even if we don't our embarrasment of yesterday smeared all over the net. They are simply stating the facts
Except that there was no price drop. Price spiked from 100 to 145 bounced at resistance and consolidated around 125, thats not exactly what I would call a price drop. Maybe they turned their charts upside down? |
|
|
|
|
They must have looked at different exchange rates over there at the BBC, the price did not drop, it did not exeed avarage volatility, Bitcoin price was and is higher than it was the day before, nothing bad happened to the exchange rate at all. Why cant they report news based on facts (and simply report nothing if nothing happened) instead of making up pure nonsense and blatant lies out of journalistic boredom?
|
|
|
|
DESCRIPTION
however the ticks are delayed in time by approximately 15 minutes as described in the API documentation
How about going one step further and using MtGox websocket or socket.io API for live streaming data and also make a simple trading API (that is similar to MT4 API) so that any EA (after only small modifications) can trade on MtGox? |
|
|
|
 500 is also a round number. and around 30 will then be the re-test of previous breakout. Therefore sell at 500, put buy orders near 30 and then ride it to the moon! |
|
|
|
are you plotting volume also? if so do you find the live numbers sum closely to the history?
Not yet. I'm only plotting a quick & dirty price chart of the last 24 hours so I can quickly see from 5 meters distance if it has gone up or down during the night. I was too lazy until now to also write code to plot volume bars (I also don't have enough room in the terminal window to plot too many details in ascii-art with ncurses) |
|
|
|
thanks for checking it out!
your trade UUID (top) vs the one I get (bottom)
dbf1dee9-4f2e-4a08-8cb7-748919a71b21
dbf1dee9-f2e-a08-8cb7-78919a71b21
the stream I am parsing is the default stream after first connecting, this is probably the problem. I would like to unsubscribe from them but have not been able to yet. It seems odd that the default stream contains junk, why bother including it?
No, I am using them too. But all your "4" are missing! Are you trying to parse the "4::/mtgox:" by any chance and have an error there in your parser? In your previous post the "4::/mtgox:" is appearing between the json objects and is the only thing that has a "4" in it, all other "4" seem to have gone missing! |
|
|
|
This is strange. My timestamps as received here are correct. Below are some messages I have received here from socketio.mtgox.com a few minutes not long ago, the timestamps look normal. Also the trade history from https://data.mtgox.com/api/2/BTCUSD/money/trades gives me correct timestamps from today and I'm using them to plot an M15 candle chart and then use the date from the streaming trade messages to continue this chart (update the last candle until time_trade > time_candle_open + 15 minutes) and apend new candles to the chart. I could not see any mismatch between the timestamps of "money/trades" and new incoming trade messages. The first thing that catches the eye is that in your trade message the date field is only 7 digits long while mine is a complete timestamp (in seconds, 10 digits) and also your microseconds timestamps seem too short (12 digits instead of 16), how can this happen? Something eating characters and always the *same* sequence of characters? Btw I cannot see the character "4" appearing anywhere in your dump (except for the 4::/mtgox (!)) and also some of the GUID strings are too short! Below are the mesages as received by me (and pretty-printed/formatted by json.dumps()) trade {
"origin": "broadcast",
"trade": {
"price_currency": "USD",
"trade_type": "bid",
"price_int": "9120000",
"item": "BTC",
"price": 91.2,
"primary": "Y",
"tid": "1364662801201914",
"amount": 1.41528958,
"amount_int": "141528958",
"date": 1364662801,
"type": "trade",
"properties": "limit"
},
"private": "trade",
"channel": "dbf1dee9-4f2e-4a08-8cb7-748919a71b21",
"op": "private"
}
Depth {
"origin": "broadcast",
"depth": {
"volume_int": "0",
"price_int": "9120000",
"currency": "USD",
"price": "91.2",
"volume": "0",
"item": "BTC",
"type_str": "ask",
"total_volume_int": "9828724331",
"now": "1364662801229415",
"type": 1
},
"private": "depth",
"channel": "24e67e0d-1cad-4cc0-9e7a-f8523ef460fe",
"op": "private"
}
Ticker {
"origin": "broadcast",
"ticker": {
"sell": {
"value_int": "9120000",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.20000",
"value": "91.20000"
},
"last_orig": {
"value_int": "9120000",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.20000",
"value": "91.20000"
},
"now": "1364662937327085",
"buy": {
"value_int": "9119999",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.19999",
"value": "91.19999"
},
"last": {
"value_int": "9120000",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.20000",
"value": "91.20000"
},
"vol": {
"value_int": "5095833923444",
"currency": "BTC",
"display_short": "50,958.34\u00a0BTC",
"display": "50,958.33923444\u00a0BTC",
"value": "50958.33923444"
},
"last_local": {
"value_int": "9120000",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.20000",
"value": "91.20000"
},
"last_all": {
"value_int": "9120000",
"currency": "USD",
"display_short": "$91.20",
"display": "$91.20000",
"value": "91.20000"
},
"vwap": {
"value_int": "9064567",
"currency": "USD",
"display_short": "$90.65",
"display": "$90.64567",
"value": "90.64567"
},
"high": {
"value_int": "9498000",
"currency": "USD",
"display_short": "$94.98",
"display": "$94.98000",
"value": "94.98000"
},
"low": {
"value_int": "8550000",
"currency": "USD",
"display_short": "$85.50",
"display": "$85.50000",
"value": "85.50000"
},
"avg": {
"value_int": "9037305",
"currency": "USD",
"display_short": "$90.37",
"display": "$90.37305",
"value": "90.37305"
}
},
"private": "ticker",
"channel": "d5f06780-30a8-4a48-a2f8-7ed181b4a13f",
"op": "private"
}
Lag {
"origin": "broadcast",
"lag": {
"stamp": "1364663115576119",
"qid": "74655212-1bc0-4b69-95da-79e40f4f771f",
"age": 329545
},
"private": "lag",
"channel": "85174711-be64-4de1-b783-0628995d7914",
"op": "private"
}
|
|
|
|
irc has always been like that. the best move is to just /quit
find something productive to do then sit on irc.
yeah you're right: when someone censors you, you should just give up and go do something else because free speech isn't worth the effort.  LOL, its just an IRC channel! How old are you? |
|
|
|
|
Also ich hätte gerne 5 Anteile,
5 * 0.34 = 1.7 ist der preis noch aktuell?
|
|
|
|
Much of the new ask volume is due to large walls between 150-600.
Hmm, a bear could just add 1000 coins for sale at 1,000,000,000 to manipulate that chart. No. It doesn't matter at which price he adds it, the ask sum is always in BTC so he can add only as many BTC as he has. The same is true for the bid sum, its in USD [in this chart], one can only add so many USD to the bids as he actually has in his account. |
|
|
|
I seem to be receiving trade tickers with following unix timestamp:
1365219272
which is a future date:
2013-APRIL-06 04:34:32 UTC
How is the bitcoin price next week? Is it above 100 already? I knew that C++ code can be quite fast but this seems to be a remarkable breakthrogh  |
|
|
|
I use Chrome and it bothers me every time I see that damn red squiggly line under "bitcoin". I know I can just click add to dictionary, but it should be considered a legitimate word.
"Bitcoin" is a name and "bitcoin" would be a noun. If the spellchecker flags names then it is broken anyways. |
|
|
|
Sometimes I worry that I will wake up and Bitcoin will all have been a dream.
Should this ever happen then you can always implement it yourself from scratch because then you will be the first one who had the idea and become the Satoishi of this other reality. I would do the same in my reality. |
|
|
|
I noticed that my server socket.io-client is connected for more 10 hours already without any reconnects whille my local dev server reconnects often but reconnects stably.
Can it be gox fixed the new socket.io server you were taling about to be able to connect without any patches?
Yes, this socketio-beta from yesterday is now reachable via the main hostname socketio (apperently he fixed the bug so it works with all clients) and the hostname socketio-beta does no longer exist. And the old server is still reachable with socketio-old (and its lightening fast now because it has only few users now) but I don't know when he will switch it off. |
|
|
|
|
We can stop worrying about socketio-beta, MT has taken it live. socketio is now the new server and socketio-beta is obsolete and the old server is now socketio-old.mtgox.com
|
|
|
|
Yes, now it works again. Big Thanks!
It works with md5? Then the bug is not fixed! It must NOT work with md5! Please show a json dump of one of your api calls, let me see how it looks like. |
|
|
|
But what is the difference& between sockeio and socketio-beta?
Why do I need to use GET request and all those things you describe?
There seems a bug in the server, MT has promised to fix it. Therefore its only "beta" and he hasn't replaced the old server yet. I have no idea when this will happen. Some client implementations can handle this bug (the bug is that both requests MUST come over the same socket), some other clients cant (until he fixes this bug). The ones who happen to have a working client (like me) are lucky because this server seems much more reliable and has had 0% downtime so far. The GET requests and basically the entire last few pages of this thread with all their technical details about socket.io and GET requests and frames are only of interest if one must write his own socket.io/websocket client from scratch because there exist no socket.io libraries for many (most) programming languages except JavaScript (and this is because socket.io is not an internet protocol and not a standard of any kind, socket.io is just a private hobby project from some guys who hacked some code together as a non-solution for a non-problem and uploaded it to github and unfortunately MagicalTux somehow accidentally found this hobby-protocol and thought it was a good idea to use it for MtGox-API and now we all have to suffer from the consequences). |
|
|
|
prof7bit
Thanks! I have not changed anything in the message signing function, my nonce is MD5 of timestamp.
There we have the reason why it is not working. It *MUST* be a numeric value and it MUST be strictly incrementing. You MUST NEVER send the same or lower number ever again or it will answer with "Invalid call". It will remember the value of the last nonce you sent indefinitely on a per-key basis (to reset this to 0 again you need a new key) Last week I found by accident that it accepted non-numeric values without complaint, I told MagicalTux about this security bug and I assume he has fixed it now. |
|
|
|
|
Show Posts
