There is some issues with fetching all the history from MtGox api. I've prepared a script which joins trades history from bitcoincharts csv and mtgox recent trades to full set. Output format supported are csv and sqlite db, configurable. CSV separator and decimal mark configurable. Support other currencies. SSL support. Open source. environment: http://www.r-project.org/ ( http://www.rstudio.com/) script (v1.3): http://pastebin.com/DWhZfGTyhow to use: 1. open R 2. open script 3. if using first time after installation run commented "install.packages" function call, else skip this function call Actually it is a bit more complicated on some platforms
Better you should go to "package installer" in 'R' and ensure the following are loaded and updated. 4. adjust params if needed: mtgox currency, output types (csv,sqlite), csv config 5. run the full script 6. wait until it will download and dump to files 7. look for .csv and/or .db files in R working directory (default on windows /Documents) timing: - downloading mtgoxUSD history from bitcoincharts: ~10min - downloading mtgoxUSD recent trades from mtgox: ~5sec - transform and merge: ~1min - save to csv: ~1.5min (~296mb) - save to sqlite: ~1min (~225mb, not compressed) please report any bugs you will find |
|
|
|
or if the order has already been filled. this the the case which I would like to handle, is there any better way to catch that error other than suppress market api error? there should be, open orders can disappear in any time. this would be the whole new project which currently I don't have time to code. But if you think you have a different approach and want to do it, feel free to create your own script  I think I will try |
|
|
|
Hi, Anybody could recommend how to handle cancel order launched on inactive order? You can simply have an open order, fetch it's oid, but before you will launch cancel particular oid somebody can fill it. Currently the mtgox api returns: Error: Internal Server Error, I'm almost sure it is with result = 'error'. Would be nice direct "cancel all open orders on particular currency" method Another question is time threshold described in the most logic way to code "antispam guard", there are some methods which has different api call limits than others in the different time frames, would be good to setup the antispam guardian in the most fitted way. I remember there was an issue with full trades history download, I can code a script which can download the recent trades history and the csv full history from bitcoincharts and match them. It can be better way than some cloud solution. If anyone interested please write an output format: csv, sql script, sqlite db. Regards |
|
|
|
|
I like to initiative but I'm not sure if it is the right direction...
nitrous has made a workaround, you are going to create another workaround, probably a bit better.
Other way to handle the case would be host all the trades data to public via easy interface and ask users to donate 0.005 every time they are fetching whole history. I'm not sure how many people would donate, but the micro payments are encouraging the paying process.
|
|
|
|
Once the bar is closed, an algorithm handles it immediately. if you will have bars in 1min or 30s? it will not be as immediate as it is now. you cannot buy for average price of current bar because that period is just closed, you buy on the next bar avg price, your trade is being aggregated to this next bar. That's why you are counting the price as next bar. You can perform simulation based on real executed price of orders ~ estimated by both methods with lag/with no lag. When you have 30 minutes bar the engine will trigger when a bar closes, within a very short amount the engine will determine whether it needs to change the portfolio (and if to buy or sell to reflect this). This will all probably happen within 1 second after the bar closed, with the low liquidity in the BTC market I really don't think the effects are big. And if they are I don't see how the average price of the next bar is any better price indicator as a lot can happen after in the 29 minutes and 59 seconds after the decision (maybe the open of the next candle would be a little better but I really don't see it right now). About the lag: I don't know if this data is available at all, but it is not going to help you much: when there is a 10 second lag it means the trading engine is lagging 10 seconds behind. All orders from between 10 seconds ago and now are queued and they are probably not available, so they are unknown at the time you make your decision (not 100% sure, maybe there are in the order book already). If I got your question correctly: Trade price = Close price for the current bar + Trading fee Remember, this is only a simulation so the formula does not consider slippage and other real trading costs. I don't agree on your price calculation: While the trading fee obviously needs to be payed while ordering, the alpha (EMA/MACD indicator) is only responsible for detecting the trend, you are now manipulating the data so that trends happening do not get properly detected IMO (difference is pretty small, but it's there). This is a hard problem because the current alpha (a simple trend indicator) can't tell you anything about how long a trend will probably last (statistically) or how much the price will change. If you would have a model predicting this you can better determine if you should reposition your portfolio while taking fees into account. My bot only uses the fees to simulate the profit, it does not use them to determine what position to take. first. by lag I meant lag of executing signal after time period is closed and ready to calculate. second. I prefer to use next bar price from the very clear reason: your buy/sell action price will be aggregated to the next bar period, not to the previous on which signal was calculated. "Open" price of the next bar should be more correct in your case. Another thing you should keep in mind that signal calculations might be much more time consuming than just EMA crossing and would not be executed right after the period is closed. |
|
|
|
Once the bar is closed, an algorithm handles it immediately. if you will have bars in 1min or 30s? it will not be as immediate as it is now. you cannot buy for average price of current bar because that period is just closed, you buy on the next bar avg price, your trade is being aggregated to this next bar. That's why you are counting the price as next bar. You can perform simulation based on real executed price of orders ~ estimated by both methods with lag/with no lag. |
|
|
|
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
If I got your question correctly: Trade price = Close price for the current bar + Trading fee Remember, this is only a simulation so the formula does not consider slippage and other real trading costs. so I think you should alter this formula, when you got your buy/sell signal the current bar is already closed one (you cannot calculate signal for not closed period), so you get a signal while next bar is the "current bar", the more correct formula would be to use average price from the next bar, it is still not sure if you will be able to buy/sell all the BTC you are placing order during the time of the next bar, but it is the most correct estimation imo. |
|
|
|
|
what is the logical formula to estimate the price of executed buy/sell for particular buy/sell signals?
|
|
|
|
|
Goomboo - what periods do you use? daily, hourly?
I can prepare some small simulation of Rate of Change in time for your strategy, was is done before (somewhere in 42 pages in the topic)?
|
|
|
|
|
rMpCVVhcb6iEivZNwQinSEyY7mKb319rr8
|
|
|
|
|
Thank you dexX7 for pointing me streaming socket.
Didn't knew about that order book can be grabbed from there.
I haven't used streaming socket at all, so far only url api calls.
It is definitely the way to go in such case.
As of now I will not try it, have some other things to do now, and handling streaming sockets in R environment might take some time.
Thanks for the answer!
|
|
|
|
|
many miners prefer to keep cnc instead selling. easy mining soon will be finished and then price can go up very strong. market depth is very small and price will be jumping. soon it will be on other exchanges, market depth will be much bigger and price will be more stable, probably going up. imo it's buy time.
|
|
|
|
|
CJAd3JHZhnwXE3VBFhF1g6EzGsJKpS33DD
thx
|
|
|
|
|
they are back, price doesn't skyrocket. looking at mining diff, price should be going down, it's much more efficient to buy a cnc-miner paying in btc than buying cnc coin paying in btc. CNC looks like very overpriced coin but still I think it can rise, just because of the masses of chinesse
|
|
|
|
Is there a launch date? Is it being mined now?
I got ripped off on a feathercoin pool.
I would like to be ready this time.
Thanks,
+1 |
|
|
|
Another joke of a coin. Let me tell some of you how these work. Its a simple as renaming Litecoin to Mincoin: https://github.com/SandyCohen/mincoin/commit/ea3f1cf9fb92159e078d9d48f19ac0fc9dbf5015Changing the starting difficulty: -static CBigNum bnProofOfWorkLimit(~uint256(0) >> 20); // Litecoin: starting difficulty is 1 / 2^12
+static CBigNum bnProofOfWorkLimit(~uint256(0) >> 16); // mincoin: starting difficulty is 1 / 2^15 Adding a massive premine for the first three days: int64 static GetBlockValue(int nHeight, int64 nFees)
{
- int64 nSubsidy = 50 * COIN;
+ if(nHeight<1440) return 500*COIN; //720000 coins in first day
+ else if(nHeight<2880) return 100*COIN; //144000 coins in second day
+ else if(nHeight<4320) return 50*COIN; //72000 coins in third day
+ int64 nSubsidy = 2 * COIN; //2880 coins thereafter Its as much of a joke as the other copy and paste coin BTE. Here is my predicition, these coins are going to keep coming out each week. Don't waste your time on them. +1 |
|
|
|
|
Show Posts
