Can I ask a few questions about your trailing stop-loss (which is a very nice feature indeed!)
Is your bot constantly monitoring ALL trades (to adjust the stop-loss trigger price) in real time (to be able to sell if the price suddenly drops between sample points)? Or is the stop-loss function simply monitoring the first trade of every interval? I.e. will your bot react and trigger a sale immediately if the price drops at some time between two samples? (a proper trailing stop-loss should react immediately as it's a safety feature to prevent loss when the price is dropping quickly).

And as your stop-loss logic may often collide with your EMA-bot strategy, how does your bot combine the stop-loss logic with the EMA-bot strategy?  I.e. if he stop-loss triggers a sale, but the EMA-strategy still detects an up-trend, what will happen? Will the EMA-logic be disabled? Because your bot can't start buying again, the minute after after a stop-loss sale, right?

And one final question about the charts you are using.
You DO have permission from bitcoincharts.com and pay a licensing fee to them for embedding/hotlinking their charts in your commercial product, right?

MtGox has been very unstable the last days... Probably new DDoS-attacks against them :/

It's probably just a temporary MtGox access problem - unfortunately it happens from time to time - MtGox API isn't very stable :/   (you cannot get data from the URL https://data.mtgox.com/api/2/BTCUSD/money/info by loading it directly in the browser, as your API key has to be included in the header)

Right now, MtGox access works for me - have you tried restarting the extension? (or the whole browser)

Yes, MtGox is quite frustrating :/
I just took a quick look at the btc-e API (https://btc-e.com/api/documentation), and the main functions are there. But I can spot one problem right away: You don't seem to be able to place trades at "market price" using their API. So the bot would have to specify a price, which means that there's big risk that orders will not go through...

Anyone know how to deal with that?
What would happen if the bot would place an order with an extreme price?
E.g. when selling, it could try to sell with the price $1 and btc-e will sell at the highest bid?
And when buying, if the bot specifies $10,000, it will start buying at the lowest price asked?
Can we trust that and not end up buying/selling at crazy rates?

Maybe in the future. I don't know what APIs they offer...
But at the moment I don't have very much time to develop (my wife and I are having our second child any day now, so expect me to "disappear" from here for a while any day

Yes, the graph currently always shows all fetched 144 samples... The "show last" only affects the list at the moment... I'll make the graph follow this setting as well...

I think that's is a very wise advice!
Many seem to use way too aggressive settings, and loses.
You simply can't make good trades every day - if there IS no trend, the bot can't find one!

I just released a new version (v0.2.1.6) of the bot that uses MtGox API v2 by default.
(MtGox still seems to have problems today delivering user data with the old API v0)

It also includes a lot of improvements on caching trade data, so loading and changing sample intervals will be as fast and efficient as possible with the current MtGox API (every sample that can be useful from every call is cached in local storage).

Download here: https://github.com/TobbeLino/GoxTradingBotTobli

Pleas report any problems with trading, etc with the new API!
It is not as extensively tested as API v0...

If the constant "useAPIv2" is set to "true", the bot is using the equivalent API v2 for all calls, so it's fully supported already.
But I haven't looked into it more - maybe there are some new API v2 calls that could make the bot better/more effective.
But the API v2 is quite poorly documented, and for the features currently implemented in he bot, I have not seen any major improvements in API v2 (other than it seems to be a bit more reliable when MtGox is under DDoS-attacks or having other problems).

I'm currently working on improved caching and faster and more effective loading of trade data, without having to be hammering MtGox with calls.

When buying, the bot tries to buy 1000 BTC (regardless of currency).
This will result in buying "as much as possible" and spending all funds.
...unless you have more than the equivalent of ~$118,000 with today's price on your account of course, but I don't think anyone with that much funds would let a bot play with it

Yes API v0 seems unstable at the moment. Maybe it's time to switch to API v2 by default.
Have your bots done any trading etc with API v2 and everything looks correct?
I haven't tested with API v2 very much myself (although it "should work")

I think you misunderstand a bit how a bot works. A bot will never "buy at the bottom and sell at the top". It will always wait and see if the trends seems solid. That's just how it's supposed to work, and that's why it is often (but not always) more successful than myself trading manually  If you try to buy at the very bottom of a swing, and sell at the very top, you will have to take way to high risks all the time, and you will very often find yourself out of synch with the trends (because you bought or sold to early, thinking you where at the bottom/top), and you start losing...

Are you confusing volatility with volume?
That's two very different things...
And the function of a stop-loss can't be replaced by volatility- or volume checks

I think the philosofy with bots is that they "win some and lose some", but if tuned, they should win more than they lose and make a steady profit in the long run. But the last days have been hard for the bots or any swing trader - the market is too clam, low volumes and no swing to trade on...

I think (my opinion of course) that it would be very risky to "forbid" a bot to sell at a loss. Becuase then you have already decided that the market eventually "must" go up above what you paid. But this may never happen, or may take a very long time, and the bot can't trade while you wait for the market to recover (if you had a bot like that running when the market dove from $250 last month, it would not have sold if it made any trades near the peak, and it would now be sitting here, waiting, waiting for the market to reach ~$250 again).  The only thing that matters is: where will the price go from now? If up: buy/keep! If down: sell/stay out - no matter what you paid or how you traded "yesterday". Even if it sells at a loss, it's no point in follow the trend down, losing even more. Better to sell and buy later and follow the trend up again.

Thanks! I'll have to think about this before adding it to my bot...
My spontaneous reaction is that this seems to a over-simplistic way to get a volatility indicator (but I'm no expert in this), so it will not be very reliable. Each sample is only ONE single trade on ONE point in time, so you are only looking at three trades (out of all hundreds or thousands that take place during an interval).  Maybe for very short intervals you could get some useful data if you're lucky, but with trading intervals of 30 minutes or more (or even 15 minutes) I'm think that your volatility indicatior will not reflect the true volatility.

Personally, I'm also a bit sceptical about using volatility as an indicator at all (at least in this way).
I'd much rather use a volume indicator. But to implement that, the bot needs to fetch a whole different kind of data (total volume between sample intervals for instance).

I see mostly "Jr. Members" (including me) commenting and suggesting features for the bot - are there anyone who actually know the theories here? Unfortunately I think that MtGox APIs (which are not very good in my opinion) will probably limit how complex indicators this bot can calculate.

In general, I think that there seems to be some misconceptions of what to expect from a trading bot.
A bot is not a "magic money making machine"
Any bot (or human) will make bad trades sometimes - no matter how "smart" it is.
But the goal is that it should be able to make more good trades than bad trades, and that it will make money, slowly, steadily in the long run.  And I don't think it's possible to just "speed up" the process and make more money in shorter time, simply by setting a shorter sample interval - the trading fees will probably take all your profit away.

But as I've said before: I'm better at programming and software development that at trading - thats why I need a bot!
So if there are any true experts here with real experience with designing trading bot strategies, please feel free to comment!

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).

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...

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...

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.

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?