This is great! Would you be able to provide a X day moving average based on closing price? If you want to get fancy, a moving average on open, close, high and low would be nice!

Thanks.

What you're asking about would require that I take the full trading data feeds from MtGox and Bitomat, which I'm not doing. Seems like you're thinking of a trading application for the data, whereas the need that motivated me to create this is to have a source of conversion data for doing automated re-pricing on Bitcoin-accepting merchant websites.

You could grab weighted pricing from bitcoinmarket.com's API. I think they offer 3 different intervals.

The repricing is what I had in mind as well. While the market is making 10-15% moves in a day, I think an average of some kind is more valuable.

Gotcha. I'll have to think about it. Thus far, I'd envisioned shopping cart implementers polling the service on their own schedule and doing whatever they liked with the data. That could certainly involve building up a moving average and pricing off it. Hmm.

Actually, this is the reverse case of my use case, now that I remember correctly. What I wanted for an e-shop is the ability to price in Bitcoins, but have a convenience option of displaying secondary prices to customers in their local currencies. For that case, you'd actually tend to want up-to-the-minute data.

Question: How do you envision merchants would use this? I'm thinking out loud here....

Seems like as a merchant, you'd want to offer your goods and services in various currencies, and "lock in" the prices for the duration of the users' session, so that the price in Bitcoins is constant during the period that a user fills out the order form.

Say the merchant's page says "Now available for 6.20 BTC (which is approximately $44.99 at the current exchange rate)." And then the user fills out the order form. Meanwhile, the exchange rate has fluctuated. But, as a merchant, I want to make it easy for my buyer, and if they agree to pay me 6.20 BTC, I don't want to stop the transaction and say "oh wait, the currency value fluctuated, and now you owe me 6.25 BTC". (unless, perhaps, the exchange rate has fluctuated wildly during the time that the user filled out the form).

Most merchants will think in their native currency, so they'll want to make sure that the offers in BTC are approximately equivalent to their offer in the native currency.

My concern is that if the price conversion is determined by Javascript at the client, then it's potentially subject to attack by the user. So the merchant would need to validate the sanity of the BTC pricing at the server once the order is submitted. And the range of acceptable prices could be pretty wide.

An example of this concern would be that I, as a user with Firebug installed, could easily alter the 6.20 BTC price, make it 2.20 BTC, and order the product. The server would then need to be able to detect that I was cheating. How would this work? Does the server need to keep track of all recent exchange fluctuations? (because a 6.20 vs 6.25 difference may be acceptable due to the time it takes to fill out the form. But a 2.20 vs 6.25 difference was probably the result of a cheater). Or would the server just check to see if the submitted price is within, say, 3% of the current exchange rate? (In which case, if I were a cheater, I'd always give myself a 3% discount)

I'm sure this issue can be resolved, and probably has been resolved for non-BTC multi-currency sites.

Maybe there needs to be a way for the server to hit BTCrate and ask "when was the last time $44.99 converted to 2.20 BTC?" and check to see that the time interval is within an acceptable range. If the answer is greater than 20 minutes, then throw the user to a "Sorry, you timed out" page.