Topic: ncurses based MtGox live monitor and trading-bot-framework (Read 33859 times)

They claim it was a one off glitch
https://bitcointalksearch.org/topic/m.5523544
but point taken.

Nonetheless it would be a shame to let goxtool sit unused.

There will be no goxtool for bitstamp (and no single satoshi from me into their accounts) until they hire some competent programmers and get rid of that crap of a dysfunctional matching engine:

Bitstamp has introduced a websocket API.

https://www.bitstamp.net/websocket/

Aside: sorry for any people who lost any money on gox.

BTCounty for the first person to port goxtool to btc-e with support for all currency pairs.

Just because Gox is dead, doesn't mean goxtool has to die.  Goxtool was always my favorite thing in the world, even compared to some of the complex bots or trading platforms

Can I get a collection of strategies? Something that just uses some form of EMA and only needs BTC in the wallet to start?

Initially (early versions of goxtool) only used the streaming API to send orders, so it all happened asynchronously, the function call (buy, sell, cancel) did immediately return without any feedback. When I later implemented the http api I made it behave the same way, so all existing bots did not experience any different behavior when goxtool was switched to http api, the call still immediately returns while a separate thread is trying to do the http requests. As soon as the http response is received it will put the order into the owns list and fire a bunch of signals while the order is graduating from acked to pending to open.

Its all centered around the idea that nothing you do within your bot should ever block (so you should never wait for a http request to return) because that would block the entire client because only exactly one thread is allowed to be inside a signal call at any given time, any other thread in goxtool that attempts to emit a signal too will have to wait until all slots of the previous signal have returned. Signals can be emitted by the stream receive thread, the http thread and the main thread (keypress signals) and none of them can ever be processed simultaneously, they will all run into the global signal lock and wait until your strategy (or any other component of goxtool/goxapi) returns from the slot it is currently processing.

Sou you should not attempt to program your strategy in an imperative sequential manner, you should instead move the stuff that needs to happen after the order has been placed into the owns_changed slot or other slots that are appropriate. I admit that this might make some things more complicated but I don't see any easy way around this. If you absolutely cannot avoid it to do things in a sequential manner then you might try to start a new separate thread that does it and which calls the protected (prefixed wth "_") blocking http request methods directly.

@prof7bit I noticed that Goxtool goes to great lengths identifying self orders but according to: https://bitbucket.org/nitrous/mtgox-api#markdown-header-moneyinfo MONEY/ORDER/ADD should return "success" (or error) along with the the OID (order identifier). I still didn't try sending orders, but I am wondering if it is possible to identify the Bot's orders when you are sending them.

To add to prof7bit's awesome opensource, posted the bot I'm using: https://bitcointalk.org/index.php?topic=376352.new#new

Based on the balancer bot but different logic - trading inside a predefined price range buying below current price selling higher; since it sets orders on many levels across the range, is pretty resilient to gox lag spikes and API delays. Does not need balancing, uses all fiat in equal increments and the same with BTC, amounts automatically balance out after several spikes.

It can go full-BTC or full-FIAT, so this bot definitely requires supervision - you set it's trading ranges, you can select how aggressive it will be. Setting a range of 0-10000 would be really conservative, and using something like 450-900 as I do now would yield the most.

Testing it with significant deposit for several weeks, does not lose orders, is stable (mainly due to goxtool's architecture and stability, of course), worked really well during that crash.

Seems to be working fine.

I'm impressed prof7bit. Very quick turnaround, thanks.

please

git pull

and then run with

--protocol=pubnub

because websocket is currently down. Implemented this in a hurry, might still be buggy but seems to work for me. Will fix bugs later as they become known.

No trading fees on Gox till Monday (Tokyo time). If you're running balancer.py this could be a good opportunity to set your distance as small as possible. You don't want it placing orders smaller than .01 or Gox will just round them off.

frankenmint, I'm not familiar with running Goxtool in Cygwin. It may not be finding the path, even though it looks like you are in the goxtool directory.
Try specifying ./goxtool.py as part of your command (preface goxtool.py with dot slash)?

Wish I did this 6 months ago...so I'm trying to run it using cygwin and I have everything setup, but when I try to use it, its is like the bash window doesnt move forward after entering in:

  python goxtool.py --protocol=socketio --use-http


It just goes to a new line.  Dont know what else I could be missing  

Not sure how I missed that 

Thanks!!

in goxtool.py around line 48 there are the sizes defined

Note that after changing your local copies of the files you might need a local git branch or git stash to be able to continue pulling and merging future updates of goxtool (sounds more complicated than it actually is)

Sad this has died down but still working...

Can anyone advise how to increase the number of rows visible at the bottom.  It looks like 8 is the default - would like to increase to 12 or so.

I have peaked into the files and cannot find it.

TIA!

prof7bit, thank you for your work. goxtool + balancer.py has been good to me. I am not a good manual day-trader, but balancer.py has been. Donation sent.

Hi,

it is unfortunate that this project does not advance much. Maybe a decoupling of features is required. Have you considered using an Advanced Message Queuing Protocol http://fr.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol (AMQP like RabbitMQ http://www.rabbitmq.com/) ?

Kind regards

Thanks! AidoATP rocks too by the way.  

Nice, I think the _panic.py is what I need.

Here's my 'all in' version of prof7bit's original _stoploss.py:

https://gist.github.com/aido/5623833

I have a few other ones at https://gist.github.com/aido/public

Is there a way to do market orders or "all in" orders? I can't do it easily with the current goxtool as I have to type in USD price and quantity of BTC.

Is there a way for goxtool to:

• Calculate how many BTC given a certain amount of USD using the market price?
  
• Calculate how much USD given a certain amount of BTC using the market price?

Once I have this number I can offset accordingly.