Topic: goxtool bot: portfolio rebalancing - page 7. (Read 26586 times)

It looks to me like the bot doesn't consider the trading fee when calculating the new two distance orders points and the two new order volumes.

The bot paced two new orders which were exactly the same like the first placement which were done hours ago.

got this running on my raspberry pi now for testing purposes with small amount of funds, and it's working as intended so far.
But I got a little problem: how can I run the bot in background, I can't fork the process to background using "&" because I won't be prompted for the decryption password, and if I close the SSH session the process gets killed.

I have some philosophical questions:

Is it good for us if it's good for market ?
or is it good for us when it's bad for market ?

Should we help to improve usage of BTC as currency (by stabilizing price
instead of taking advantage of the price change) ?

It will do so by placing limit orders above and below current price that will restore the 50/50 ratio once price moves there and fills the order. As soon as one order is filled it will cancel the other and then calculate and place 2 new orders above and below that new price.

Nice, never heard of screen. thanks for the info, it's working now, even if I close the ssh client.

$ cat botwindow.sh
#!/bin/sh
screen -D -R -A -S bot

$ cat ./startbot.sh
#!/bin/zsh
if [[ -z $STY ]] then
	echo "Not in screen! Run ~/botwindow.sh"
else
	cd ~/goxtool
	./bot_balancer.sh
fi

I'm trying to understand wat might have happened to cause these symptoms, i don't have any idea yet. It should not trade if there are != 1 open orders, it should not trade if there are != 0 submitted but not yet acked orders.

How did you start goxtool, did you use --use-http or did you send the orders via the streming API? I cannot imagine any scenario where sending an order would *not* increment gox.count_submitted *or* the number of own orders in orderbook.owns. Either the sent order doesn't get acked then count_submitted will be != 0 or there comes the ack with order id for each order then count_submitted = 0 but orderbook.owns has a new element added. In both cases it shoudl stop sending more orders. The only way I could vaguely imagine was if you did not --use-http and submitted via socketio, never received the ack and order ID, a reconnect would reset the count_submitted counter [Edit: actually only a *successful* download of own orders will reset count_submitted, not a simple reconnect] and because of ddos and 502 error you would never get the full own order list download but for some reason all the submitted orders (submitted through socketio and never acked) would later go through all at once [because they were hanging around somewhere on the server in some kind of separate (undocumented?) queue all the time]. Thats why I recommend --use-http because that way you *WILL* get an ack for every order under all circumstances because the http call will either succeed (ack) or fail.

Are you running the latest version of goxtool.py and the latet version of the bot (3rd revision) from the github gist in post #1 of this thread or are you still using one of the older versions from the other thread?

If this happens again please save the log file (*before* you restart goxtool because restarting will truncate the old log)

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

got this running on my raspberry pi now for testing purposes with small amount of funds, and it's working as intended so far.
But I got a little problem: how can I run the bot in background, I can't fork the process to background using "&" because I won't be prompted for the decryption password, and if I close the SSH session the process gets killed.

I'm aware of the problem. And there is also the logfile that will be written by each running gox instance. I'm already thinking about possible solutions. Currently the simplest workaround is to either copy the entire folder or start it from within different cwd. This will improve eventually but at the moment I'm still finding new bugs in the client code (handling some erroneous conditions, missed messages, previously unknown error replies from mtgox API that result from various kinds of mtgox outage and other strange mtgox behavior that could happen) these kinds of bugfixes have highest priority.

I don't like the idea of this .ini file

because you can't have 2 goxtool instance running in 2 differents GNU screen
 (one for BTC/USD and an other one for BTC/EUR)