Topic: Chrome Browser extension: MtGox trading bot - page 11. (Read 72509 times)

Is it possible or a good idea to prevent the bot from trading at a loss and just hold the BTC?

I found one ranging market indicator which worked well on forex: Damiani volatmeter. Heres a link to discussion and source codes (in MQ4) for that. As you can see from the picture filtering is crucial for systems like this.

http://www.tradingsystemforex.com/indicators/431-how-to-determine-if-a-market-ranging.html

I think it's a good idea. Maybe it would be great to do some tests on Mt.Gox historical data to check if this option improves the performance of the bot.

I have some very old history making metatrader forex expert advisors. I would suggest you could add a trigger based on average trading volumes. For example last 50 bar average compared to last 5 bar average. If volume is below certain level trigger bot will not trade.

Also using local storage is useful like some previous poster suggested to make all sorts on internal calculations more robust plus not unnecessary hammering mtgox & risking to get banned or if mtgox lag is heavy bot could perhaps survive better.

EDIT: I would also suggest to add a stoploss, sometimes slow dripdowns compared to ema trigger set too high can be very risky.

I lost a bit aswell so I disabled the bot during this low volume period.

Current situation is the worst. It needs higher volatility.
The idea is to profit on the long run by accepting some losses on the way.

by the way, has anyone been able to profit with the bot in the last couple of days? Not me.

Strong fluctuations like this morning (from 116 to 118.5 at 11:00 UTC) make the bot insta-buy  @118, than it sold btc after 5 hours of slow price decline (16:00 UTC) @116.4.

My conf is 10 min; 1 tick; 10/21 emas, thr 0.23buy -0.13sell

Anyone?

That's my point: since the responses are now larger, do they overlap the requests? If so, you're better off parsing the response rather than making a now obsolete request for some data you already received.
I probably should have been clearer

The API's the bot currently uses allow it to specify from which time we want the chunk, so the first trade in each reply is always "on time". But we can't specify how big the chunk should be (in our case we only need it to be 1 trade).

Good point. But if the bot expects each request to be roughly equivalent to one sample and uses only one price from each request (looks like it's using the opening price from each sample/response), then that seems like a pretty rigid and ineffective way to go.

So maybe instead of making n requests and pick the opening price from each, it would be more effective to use all those trades to build your own candles from it? Take a look at goxtool's slot_fullhistory() and OHLCV() functions here https://github.com/prof7bit/goxtool/blob/master/goxapi.py as this is pretty much the way it does it, building its own Open-High-Low-Close-Volume candles from all the fetched history. That could give you a relative independence from MtGox's response size since you'd be fetching for a total history duration rather than making a precise number of requests in which only one price is picked from each. Does that make sense?

But the problem with fetching historical trade data at given points in time with MtGox API is that the bot only wants ONE trade (the first one) from each chunk of trades. The rest of the data is usually not relevant since we need samples at the correct points in time (if the sample interval is very short, there COULD be more than one useful trade in the chunk, but in most cases there are probably more than 1000 trades between each sample time, so only the first trade is useful. So in most cases we have to make one call for each sample). If there was a way to specify how many trades to fetch with each call, I would set it to 1, but as far as I know that's not possible with any API version...

But caching data should cure some of the problem. Then you could at least restart the bot/browser without a new storm of calls to MtGox. But as you said, it's probably ok - while developing, I need to restart the bot all the time, causing 144 calls to be made, and I don't think I've been blocked...

hi guys

is this one giving good perf?

what can we expect on this?

I see. I completely agree that the history size should be at least 144 x the sample size, but what i meant is that since you're getting 10x as much data for each request when using the API v2, you probably don't need to fetch as many times as the original bot did when using the API v0. In that regard, obtaining 144 samples' worth of data does not necessarily mean having to make 144 requests to the API.

In my experience, the MtGox API is more defensive against the time between each request (hammering will get you banned for a while) than to the actual number of requests itself. In the case of the bot, i think the time it takes to parse the json and fetch the next request should be enough timeout. You could always add a small timeout in between requests if i'm wrong, but since it seems to work as-it-is now, i think you should be okay with an even smaller number of requests for the same amount of data.

Yes, 144 is from the original bot, and I have not dared to change or question it
However, I think the number of samples should be the same no matter what the sample interval is (the bot fetches 144 samples, not 144 hours of samples). The EMA-vaules are calculated from the samples - independent of the interval, so the accuracy should be exactly the same as the original bot for any sample interval.

Caching samples would probably be a good idea!
Because calling the MtGox API repeatedly in a short time could mabe get you blocked by their DDoS-protection...

I've taken a quick look at the code, and a few things come to mind. First, that 144 is pretty arbitrary: since EMA is a recursive calculation, its accuracy is very dependent on the number of samples. After a certain point it becomes less relevant since the further you go back, the less the weight given to the data, but 200 * whatever timeframe you're trading is a generally accepted sample size. I remember someone complaining that the initial sample size was not accurate enough so Piotr increased it to 144 which should be an ok compromise, but it won't hurt if you have more.

So you could either keep making these 144 requests of 1000 trades and then divide that by your trading sample size, which would give you about 10 times more candles to back your calculations on, or you can make that 144 dynamic by making requests with a timestamp equal to (number of samples required for accuracy x trading sample size) instead of this fixed 144. In other words, fetch only as much as you need according to your sample size instead of making an arbitrary number of requests. This fixed value made sense when the original bot only dealt with H1 trading and needed 144H of backdata, but not so much now that you allow users to define the trading candle size.

Also, this history and its subsequent updated candles should probably be cached into localstorage until next launch. Since for a 60m candle you're fetching about 5 days worth of history, chances are that some of that data will still be valid on next bot launch, and that would also prevent from refetching everything upon a simple change of parameters.

Yes, the bot uses the "since"-parameter, and it will make one fetch for each sample interval back in time to calculate EMA. Total 144 calls when starting the bot or changing sample interval (EMA-values need to be recalculated). This many calls may be a problem in itself since I think MtGox's (or Couldflare's) DDoS-protection might kick in and block your IP when making so many calls in a short time.

But the problem with API v1 and v2 is that it seems that the size of the chunks has been increased from 100 to 1000.

For instance: https://data.mtgox.com/api/2/BTCUSD/money/trades/fetch?since=1354250571691361 will return 1000 trades
And: https://data.mtgox.com/api/0/data/getTrades.php?Currency=USD&since=1354250571691361 will return 100.

The reason it's replying with a lot of trades is that in API v2, it will return the last 24h history by default if you don't specify anything and just fetch /money/trades

You can add a ?since= parameter at the end of the url to have it return only trades since that order id. Also, if you do that it'll then reply in chunks of 100 trades like you want.

To quote this post https://bitcointalksearch.org/topic/m.1690500

since is in time units*1000000
to start x hours ago you can calculate
   since = int(time() - x*60*60)*1000000
   url = "http://data.mtgox.com/api/1/BTCUSD/trades?since=" + str(since)

You will get batches of 100 trades, so you need to keep calling
with since set to highest tid in previous batch

Hope this helps.

Hmmm - I just got API v2 working here BUT there's a bit of a problem fetching trades with API v1 and API v2 - MtGox will return 1000 trades instead of 100 (with API 0), so the data traffic will increase 10-fold (and it will update a lot slower!) :/
Unfortunately there doesn't seem to be any parameter to specify how many trades we want to fetch (we only need ONE sample for each interval!) The docs for API v2 is quite limited however - anyone know if there's a way to fetch single historical trades using API v2?

I can attest that these changes do make the bot work better. Before, when I clicked on "chart" it wouldn't show anything, just a blank screen. Now it actually works and things seem to be running more smoothly. Thanks for delving into this matter.

EDIT - One thing I noticed in the console, almost every line says "TypeError". What does this mean? The bot works fine but in the console I just see this a lot.

Well, I know the feeling about wanting to improve the strategy But my experience is that it often results in less profit in the long run... There are some very smart people who have developed these strategies, and at least I am not good enough to improve them yet. I often think my bot is stupid, and sometimes it DOES make wrong decisions of course. But more often it's right in the end, and it turns out that it made a BETTER decision than I would have. The thing is that you would like to buy at the exact bottom, and sell at the exact top of every swing, but no bot (or human) can ever predict that (and if you try to achieve that, you would have to take too high risk and end up losing in the long run).

The problem with your argument that "it would be better to stay on BTC than selling too low" is that if you (or your bot) truly believes that the price will drop even lower in a moment, it's always smarter to sell now and buy again after some time. Your decision should always be based on "where the price is going" rather than "what the price is". And I think you're always better off trying to "forget" what you actually paid for your BTC when you bought it. The only thing that could make a diferece is the actual trading fees

But of course, there can be better strategies out there to discover and develop, so go for it!