Whats wrong with scalping? It adds liquidity and removes volatility.

if you have Linux or Unix you might want to try this: https://bitcointalk.org/index.php?topic=148462.0

it can be configured to use the plain old websockets protocol (ClarkMoody is connecting to MtGox using their newer (but more unreliable) socketio server)

I have had it running yesterday all the time and it did not disconnect me, I could watch the entire drama (the slow-motion replay of orders that were already 20 minutes old) from beginning to end.

Unfortunately being able to watch what is going on there won't help you with the giant order-lag on MtGox, if you want to place an order you will also need access to a time-machine to look 20 Minutes into the future to find the right price for your order at the time it will be activated.

is plain websocket still considered deprecated? On https://en.bitcoin.it/wiki/MtGox/API/Streaming I cannot find a word mentioning this (anymore). Did they finally get back some common sense? Now the next step would be to fire the PHP-kiddies and hire some experienced Erlang programmers instead to build a brand new matching engine from scratch (or buy one) *before* it all collapses under the sheer weight of unbelievable 5 orders per second.

Added:
* y-axis labels for chart
* better looking candle bodies in chart
* display current order-lag
* display last trade price, bid and ask in the xterm window title bar
* fixed some bugs and flaws (and probably also introduced new ones)

Today is again one of these days where MtGox's SocketIO server is almost unusable.

Open the .ini file and switch to plain old websocket protocol:

use_plain_old_websocket = True

Both protocols are implemented, you can compare how they behave and which one is better for you, default is socketio because they say the other one is deprecated but it turns out that plain old websocket is *much* more reliable on days like today while socketio won't connect at all or the messages lag behind websocket by 20 seconds or more!

(If you are going to experiment with a lot of restarts of the application then please temporarily turn off load_fulldepth and load_history because this is eating a lot of bandwidth)

yes, its a websocket connection too, but before connecting you first do a http request to get your own session ID and then use that to get your very own websocket stream. This puts a lot of unnecessary load on the server during connection for *nothing*, especially when one needs to reconnect often because it drops the connection often. The first step of allocating this personalized websocket URL alone takes 30 seconds or longer sometimes, one can almost hear the server groaning on the other side while it is lifting heavy stuff around to allocate me a personalized socket.io session before I can even connect to it.

Plain websocket most of the time connects instantly.


No, there is no bug on my side, I'm logging the messaes to the console as they arrive, its lagging behind severely. Just try it yourself, run a minimalistic websocket client that does nothing except printing the messages to the console and at the same time run a minimalistic socket.io client in another console window and print the same type of messages and then compare how the messages that you have seen scrolling by in the websocket client will appear 10 or more seconds delayed in the socket.io client.

Please pull a recent version from github, I just made some changes an hour ago and fixed some bugs and also refactored some stuff (I'm still moving a lot of stuff around, thats why I called it "experimental" ;-).

The orderbook is updated automatically. The Gox() instance contains an OrderBook() instance, gox is generating signals for trade, depth, ticker, user_order, etc and orderbook will connect itself to all these signals. Look for signal_xxxx.connect() calls in the constructors to see what is connected to what and the slot_xxxx() functions to see how they all react to these signals. OrderBook will process the signals fulldepth, ticker, depth, trade and user_order and orderbook itself will then emit signal_changed for the UI to update.

Problems I have found:

* sometimes a signed call like for example "private/info" or "private/orders" will fail for no apparent reason. At the beginning after connection succeeded and I subscribed to all channels (depth, trade, ticker) I send 3 signed calls ("private/idkey", "private/orders" and "private/info"), most of the time this works perfectly but sometimes one or two of them will be answered with "invalid call". In an attempt to work around this I just send them again when this error occurs, as often a needed until it finally succeeds. I don't know if I am missing something here (the API is poorly documented), I suspect a bug on the server side. "invalid call" just is not the correct answer when the server is busy or whatever might be causing this.

* I have not found any way to request fulldepth through the websocket API, again there is documentation missing, is this possible at all?

* I have managed to send trading commands like order/add and order/cancel through the streaming API, most of the time it works but sometimes they just go missing, maybe similar to the other calls mentioned above. This shoud not happen, there should be a queue on the server and a valid order should always go through. The HTTP API seems more reliable for trading but it would be nice if I could use the streaming API for that also.

* It would be nice if there were a way to request OHLCV data of certain timeframes from the server. I can request the trade history and build them myself but this is not practical if I want for example a daily chart of the last 365 days, this wold be a mega-download, possibly hitting the rate limit and banning me. Currently I have no idea where to get OHLCV data of arbitrary timeframes from, please implement this, it will save you a lot of bandwidth.

* The connection is lost very often, sometimes its even impossible to reconnect for periods of many minutes, please fix this. As a first step to remove load from your servers I would suggest completely abandoning this totally unnecessary Socket.io monstrosity that serves no other purpose than demonstrating that some crazy programmer somewhere was able to build the Frankenstein-Monster equivalent of network-protocols. Please drop this nonsense and revert back to good old plain websockets.

* Please improve the documentation. There are a lot of things that can only be found out by experimenting, I would have edited the wiki myself and added lots of useful information that I collected through experimenting and reverse engineering other snippets of code but the Bitcoin-Wiki authorities don't give me write access and I am NOT willing to pay money for being allowed to work on the wiki, the admins seem to have totally lost the connection to reality.

Maybe a multi-million dollar company like MtGox should be able to publish an *official* API documentation on the *official* MtGox website and not (ab)use some 3rd party wiki for it. Also I would expect a multi-million dollar company like MtGox to be able to afford servers that won't crash or freeze every 10 Minutes.


***

For those who are looking for yet another example: Here is my python client implementation: https://github.com/prof7bit/goxtool  it implements both protocols: plain old websocket and the bizarre socket.io-monstrosity that is always lagging behind the websocket by at least 5 seconds (you can configure which one to use)

...written in python. Curses based UI, live orderbook, ascii-art chart of latest 24h, trading functions can be defined in separate module "strategy.py" which receives all events from the gox client and all keystrokes from the terminal. Strategy module can be edited and reloaded at runtime which is great for experimenting with bots. Works also without MtGox API-key to view only without trading.


(still experimantal, license: GPL3)
http://prof7bit.github.com/goxtool/
https://github.com/prof7bit/goxtool

screenshot


Usage:

• it needs python 2.7 (and maybe a few additional packages but nothing that would not be found in the standard ubuntu repositories). It will NOT work on Windows because there exists no ncurses (maybe it works with cygwin, not tested)
• Download and unzip (or better git clone the repo from github).
• ./goxtool.py

This should give you the orderbook on the left side and an M15 candlestick chart of the lat 24 hours (if your terminal is wide enough) on the right side and a log window at the bottom.

To use the trading features do the following:

./goxtool.py --add-secret

This will ask you for your MtGox API key and secret, you get them at the mtgox website, copy and paste key and secret, supply a passphrase which will be used to encrypt the secret. Then it will write the encrypted secret to goxtool.ini and exit. The next time you start ./goxtool.py it will ask for the passphrase to access the API secret and then all trading functions will be enabled, you will see your own orders in the orderbook and in the chart and your account balance at the top of the terminal.

To use it with other currencies, just edit the ini file. If it is one of these days when the socket.io just wont want to connect, edit the ini file and change use_plain_old_websockets to True. If you don't need history or full orderbook you can turn it off in the ini too.

press q to quit the program.
press F4 to buy
press F5 to sell
press F6 to view orders / cancel orders
press l (lowercase L) to reload the strategy module at runtime.
any other key will call the slot_keypress() in the Strategy class in strategy.py, see the examples. Here you can call methods like gox.buy() or .sell() or .cancel()  or peek around in the order book to decide what fancy stuff to do.

(this forum posting and the instructions might eventually come out of sync with the current version, see here for the official manual: http://prof7bit.github.com/goxtool/)

There are also methods that will be fired on signals from the gox object, you can use them to build fully automated trading bots (there exist even more signals to connect to, for example orderbook.signal_changed or gox.signal_wallet, etc. Look into the source of goxtool to find them all). You can also instantiate more Gox() objects from within your strategy for different currencies (you will also need separate GoxConfig() objects for each of them that use separate config files) to trade multiple currencies at once (useful for arbitrage strategies).

And finally you can rip out parts of this for your own programs, you can just import goxapi and use the Gox() class on its own in your own program, connect your slots to its signals and make your own UI for it (or no UI at all).

And if I send the money to this address, how do they know who it was who sent the money?

hello!

I am not a crypto-guru, so I might be wrong but this seems highly suspicious to me:


      password = password[0:32]
      aes = AES.new(password, AES.MODE_ECB)
      secret = str.zfill(secret, 128)
      secret = aes.encrypt(secret)


It turns out that before zero padding the length of secret is 88 bytes and after it is 128 bytes, so there is more than one complete block (key length = 32 bytes) of known plaintext and because of ECB mode all other 32 byte blocks will be encoded with the very same key! Isn't this danegrous? Shouldn't it be padded with random bytes instead and also the ECB mode be completely avoided?

I have had write access before, now I suddenly don't have it anymore. I did NOT create Spam, the only thing I ever did in the wiki was to propose a bitcoin protocol extension (that has now finally been implemented, so it wansn't so stupid after all). My user name is "Prof7bit". Now I want to contribute a code snippet example in Python for creating and sending a signed request over the MtGox Socket.IO streaming API. Even with the existing php example it took me a while to get it working, there are also some more little details missing. I would like to be able add a few words to the MtGox API page.

I would like to donate knowledge to the public domain.

I would NOT like to pay money first to be allowed to donate my knowledge!

This is totally ridiculous. If a user is spamming, just delete his account, problem solved. Other websites can do it too.

But why are the stratum servers not listed in the electrum servers list and also trying to manually add the only existing stratum server I could find only results in error messages? Or are we talking about a different stratum or a different electrum here?

There is this: https://bitcointalk.org/index.php?topic=55842.0
that somehow suggests that "electrum" and "stratum" are actually the same thing or "stratum" is the new name for "electrum"

Then there quite a lot of postings or answers along the lines of this (for example): https://bitcointalk.org/index.php?topic=91939.msg1013281#msg1013281
that come up when googling for "electrum protocol" or "electrum stratum" that claim that electrum is actually using the stratum protocol or that there is no need to reverse engineer the electrum protocol because there is the stratum protocol documentation.

There is this: http://stratum.bitcoin.cz/
not very informative and mentioning exactly one running stratum server (and nothing about electrum)

    california.stratum.bitcoin.cz (Ports 3333 TCP, 8000 HTTP, 8001 HTTPS, 8002 Websocket, 8003 Websocket SSL, California US, hosted by BitVPS.com).

and there is this: http://electrum-desktop.com/
mentioning nothing about the used protocol, the servers and especially no reference to stratum at all. The client when started present a short list of servers:

ecdsa.org
uncle-enzo.info
electrum.bytesized-hosting.com
electrum.novit.ro

and when trying to use the california.stratum.bitcoin.cz in electrum I get only error messages like [-3, u"Method 'subscribe' not found for service 'server.peers'", None] and a few more which suggest that the electrum and the stratum protocols are not the same thing.

Now here come the questions:
* how are stratum and electrum related?
* if not related then does there exist an electrum-like client for stratum?
* how many electrum servers are there?
* how many stratum servers are there?
* which *existing* protocol should be chosen when implementing an electrum-like client?
* if the answer to the last question is electrum then where is the protocol documentation (if such a thing exists at all)?

Maybe it would also be nice if both (the stratum and the electrum) websites clearly state that they are *not* related (or if they are related somehow then maybe explain in which way they are related or if there exist other "stratums" or "electrums" with the same names that are not related, etc).

Why does it do synchronized disk IO anywhere anyways? Its not used with removable media (its even almost impossible using it on external removable media when it is implemented this way anyways.

Has this bug been fixed in 0.5.1 which I downloaded today after 6 months not using bitcoin and which I used today for encrypting my old wallet (5 minutes *before* I read about this bug)?

Traders don't have to outperform chance because markets simply don't move by chance. Why is this so difficult to understand?

This does not make any sense. All miners together can not dump at any rate faster than 50 coins per 10 minutes, no matter if there are 100 or 10000 miners.

"There are too many miners" does not make any sense. Supply through mining is constant, no matter how many miners there are.

The drop that now happened was easily predictable from the obvious chart pattern that formed after the bubble, the target area around here (the minimum size of the inevitable second leg) was to be expected at or below $8. You will soon be able to observe the same kind of drop (only slower) from the same kind of post-bubble pattern in Silver when it will fall to $26/Oz and all the amateur traders will cry "manipulation!" like they do every time when they have manipulated themselves into buying an obvious bubble, totally unable to zoom out and view the complete picture.

$8 was the price I predicted a while ago when it still was around $16. All called me crazy and said I could not apply methods of technical chart analysis and chart patterns to something like Bitcoin because TA is generally hocus-pocus (then I must consequently be a magician) and Bitcoin prices behave different than anything previously known to mankind. Now it seems they were wrong and I was right. As expected (by me).
</toldyouso>
 

This is extremely valuable information! I will need it once I come to the point of verifying transactions myself. The OP_CHECKSIG mechanism is the single one thing about the entire protocol that raises the most and the biggest question marks when reading the protocol specification. Compared to that the rest of the protocol is a child's play.

Having this independently documented by different people (who all have their own style of visualizing and explaining the same thing) is a great help. I believe especially this topic (OP_CHECKSIG & friends) deserves more explanaition and this thread and the excellent diagrams are a very valuable contribution.

I hope more of those people wo have already completely understood it will attempt to document and pass on their knowledge and maybe also try to explain in their own words not only what the code does but also why certain steps are needed or done exactly the way they are done or find even better ways to visualize what is going on. I personally will certainly try to do this once I have a working implementation of OP_CHECKSIG (I'm still busy with boring implementtion of network protocol and persistance layer but at one point I will need to start working on transaction verification).