Yes, this is the same option. I admit that the name of this option is slightly confusing, it was added before the command line options were added and at one time there even existed a 3rd protocol that was not selecable via ini file at all, eventually I will clean up this mess and make it more intuitive but that has low priority for now.

I have added a command line option --password that can be used when starting it from within a script (don't use it on the command line unless you understand the implications)

I have also added two new ini settings (they will be added to the .ini with default values after you start it the first time after update):

The dafault values will display the orderbook exactly like it was in earlier versions of goxtool all the time already, so if you leave them at defaults then nothing will change. orderbook_group will have the same effect as it is used on the clarkmoody website, if you set it for example to 0.1 it will bin the price levels into $0.10 intervals (it won't display empty bins). 0 means no grouping at all, display every price level separately. orderbook_sum_total = True would sum up the total amount of BTC that needs to be bought or sold to reach and break that level instead of printing only the amount at that particular level like it was in earlier versions.

Please git pull to update.

Doesn't work for me. I'm not a bash expert, so I'm not sure why it won't work (maybe the reason is how readline internally operates or the python getpass module). Also this would still leave the password in the .bash_history even if it worked.

You are running it with much too small account. It needs at least a few hundred USD in the acount, otherwise it would adjust the orders to the minimum allowed order size and if this adjustment is too severe (it wouldn't matter if it adjusted them from say 0.009 to 0.01 but larger adjustments will matter) then the next calculation of the correct center price will be totally off. It will be off by more than DISTANCE and instead of placing limit orders above and below it would place *both* orders below price (or both above price) and that would result in a market order and crazy behavior and BURNING OF MONEY!

As I have already initially stated in my disclaimer: If you don't understand what this bot is doing (if you need to ask what is correct behavior) then you have not read the code! And if you did not read the code you cannot run the bot!

You are not the first one to ask me and I am going to implement one of these two options (not sure which one, probably the second one):

(1) A command line option (with a huge warning) to pass the pasword on the command line. It is insecure because the password will end up in the ~/.bash_history if you do this.

(2) The other alternative would be to make a separate .ini setting for the unencrypted secet that is automatically used (and the password question bypassed) when this setting is found in the ini.

The balancer does not need to be re-initialized after you update/restart goxtool, it does not have any state, it can trade from the information about currently open orders and account balance alone, it will continue where it left automatically.

Are you using the newest version of the balancer that I posted on the separate thread that I started for the balancer? Questions about it should go to this thread.

Also please note (if you haven't seen it already) that since a few days (since a server upgrade at mtgox took place) the most reliable connection to mtgox is achieved with these command line options:
--protool=websocet --use-http
I'm mentioning this again because it is very important.

Tolle Antwort. Kannst Du nicht einfach *nichts* sagen anstatt hier Pauschalbeleidingungen an alle Threadteilnehmer auszuteilen?

Ich habs übrigens auch noch nicht geblickt. Der einzuige Unterschied den ich sehe ist daß mangels Blockchain und mangels Mining die Transaktionen schneller ablaufen und im Netzwerk keine nennenswerten Ressourcen verbrauchen. Ansonsten sehe ich keinen Unterschied, auch nicht was es mit den "Schulden" auf sich hat, oder kann man ein Ripple-Konto etwa überziehen?

Was ist eigentlich (nur mal interessehalber) wenn ich 24/7 nen Bot laufen habe der jeden Tag hunderte oder gar tausende von Trades macht, musss ich dann die kompletten Logfiles abliefern?

If the topic of the discussion is too complicated for you then you just spam it with random nonsense comments to tell everybody that you can't follow it anymore? Why don't you just go and read some books instead?

damn... I introduced a bug. Every goxtool revision between 12 hours ago and just now would break the balancer bot (it would place immense amounts of orders and not detect them as own orders).

Please git pull the latest goxtool, fixed it a minute ago.

Make sure the current working directory is the goxtool directory and the mybot.py is in the same directory too.

Update regarding streaming api reliability and new server:

Since the reliability of the servers and the different available protocols changes almost daily I need to update my recommendation for how to start goxtool to have the highest reliability, especially for a stop loss this is important. I'm also going to update it in post #1.

Since yesterday the new websocket server went online at mtgox which turns out to work great (much better than socketio) the most reliable way to run the stoploss bot (or any other strategy) without dangerous disconnects is now the following:
And also as usual keep goxtool up to date, git pull at least once a day.

This is from friday, you should git pull, I'm updating goxtool almost every day, fixing little bugs and problems.


This is ok. [Edit: I just noticed that the huge delay problem is still not solved, maybe you should continue combining the above with the --use-http option (contrary to what I have said earlier), the --use-http will not hurt anyways and trading commands become slightly more reliable then, seems we still need to keep using http for order/add/cancel for a while until all problems are fixed at mtgox]

the latest _balancer.py is the one linked in post #1 in the github gist https://gist.github.com/prof7bit/5395900.
you can also just clone the gist (its a git repository too, you can fork it or clone it):
git clone https://gist.github.com/5395900.git
and then symlink the _balancer.py from this repository into your goxtool directory (you might need to make local branches if you intend to edit the _balancer.py locally yourself)

I'm going to keep this gist updated when  I find a bug. What makes me wonder is why the two orders have so widely different volume in your log file, this makes me assume you are running an older version of the balancer that did not yet calculate the new center price from the account balances. The new version (linked in post#1) is more rubust (although still not yet 100% perfect).

This is expected. And you haven't actually lost them, you have just sold them on the way up ;-)

If it trends so strongly then the most profitable strategy would buy and hold. But if it would have gone back to the price where your test started then you should end up with slightly more coins. Generally if it is going up it will slowly sell coins on the way up and when it goes down it will buy them all back again (at a slightly cheaper price).Try to choose a test period that has the same start and end price.

How did the USD balance develop in comparison? Could you upload some plots of USD, BTC and price?

stopped reading after the word "zerohedge".

Zerohedge is not relevant for anything. Tyler Durden has proved often enough that 90% of the time he does not have the slightest clue of what he is talking about and all his followers are just as stupid and ignorant as him. They might all have pure and sincere intentions but unfortunately they are all so painfully clueless, they are all so incredibly clueless it almost causes physical pain when reading this nonsense blog and its comments. Thats why I stopped reading it.

This is true. The fees are low enough to be not significant for the calculation of the new acount balance, so I just ignore them and if you choose the distance >> 1.2% there is also enough room for profit for every consecutive buy-sell-sequence.

Yes, forget it.
Forget it because the market simply IS NOT efficient.

This means it missed the wallet update message or it came too late. In my tests so far the wallet message always was the first message, then the trade message and finally the message to remove the order. Thats the reason I trigger the trading when the number of open orders changes (assuming that the wallet has been updated at this time already).

Maybe I need some more code to detect whether the wallet has really been updated already. Unfortunately there will arrive 3 wallet mesages, one for the USD update, one for the BTC update and a 3rd one for the fees. Might make the code a bit more complicated but still possible.

***

BTW: Today MtGox installed a new websocket server that is much more reliable than the socketio server. My recommendation for running goxtool are now:

./goxtool --protocol=websocket --use-http --strategy=_balancer.py

And no more --use-http as it was needed with socketio because sending orders over websocket is fast and reliable now.[Edit: turns out http is still needed, added it back to the above command line] The new websocket server should also reduce the risk of missing messages due to disconnects, actually I did not have even one single disconnect anymore the entire day since I switched to websocket when I heared about the new server this morning!

BTW: There is also an update for goxtool on github (fixes some problems with the handling of some error messages from the server and also fixing a problem when using use_ssl=False in combiation with websocket), please
git pull
the latest version of goxtool.

That would certainly be a nice thing to have. I'm not yet sure if it should be part of goxtool or a separate application that just exposes the same interface and can load the same strategy files. I cannot promise anything yet (don't have unlimited time), maybe also someone else might want to write something that could be used for this purpose.

I experimented with this back in my old forex days and never found something that would work really reliable when I simulated it with new (not seen before) test data. All the myriads of MA-crossover strategies (or whatever-indicator-cross-this-or-that-strategies) that looked promising on the data they were developed on failed miserably when simulating them on new test data. All of them! Every time! Even the most sophisticated stuff with neural networks and other machine learning technologies trying to predict the trend that seemed to work well on the training set failed miserably and immediately every time when confronted with new data, so I won't even try to do that anymore.