New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ideas for managing fees #5
Comments
Taking advantage of Maker/Taker fee structure will produce an edge. |
Also, a good way to track the open order and decide whether / how long to wait for it to be executed. |
FYI: BTCC doesn't charge trading fees. Supporting it can be interesting - and profitable. |
Is there any reason poloniex was chosen first? I was talking with one of my friends (a young investor) and we realized a 10% reduction in fees would’ve gotten statistically significant profits (would’ve ended with 1.2 BTC). Without fees it would’ve had a doubling rate of less than 1 month, in which case 1 year of trading would be an extrapolated 4,100 BTC ($1.7 Million). So I’d say supporting no-fee trader sounds like the best way to reach profitability. |
BTCC looks to support CNY and BTC (Litecoin too?) only – not ETH? Unless I'm missing something? Working from https://exchange.btcc.com/ – they also have a pro exchange but looks to only support CNY/BTC pair. They do support websockets stream of market data though which is a plus (https://www.btcc.com/apidocs/spot-exchange-market-data-websocket-api) Agree that fees are going to be a massive element to this, but I'm guessing that could be why Poloniex was chosen first – supports the chosen pairs. Maybe we need to put together a doc of all the trading platforms that have an API, support XYZ (atm ETH, BTC, USD?) and their fees? |
Not a very defensible one -- It's where I trade my BTC/ETH manually, and they had a python API client. I agree that fee management will be a major part of getting to profitability. Assuming that this repo can get to a point of competing for profits before folks with more computing power / quant knowledge enter the market. |
Was thinking about this on the bike ride home tonight @jeff-hykin. Something I need to make clear to you, in the spirit of transparency. (a) While building this repo, I went through a couple trading methods:
For much of the time this repo was live, I was holding a significant amount of ETH. (b) I built this repository during one of the most phenomenal price rises in cryptocurrency: TLDR -- I have not done an thorough analysis of whether I was lucky or good at trading during this time. When you project sums like $1.7 million, you are getting ahead of yourself. We should focus on proving repeatable results before we get dollar signs in our eyes. Is ETHs rise repeatable? Probably not. Is ML a viable tool for predicting crypto price trends? Probably. Is there work ahead of us to get there? Probably. |
Yes I agree despite 23,000 trades and 2 months, there’s still a large void of proof. And yes $1.7 million is unlikely to get even with a weekly doubling rate (from any source) due to inherent unsustainablility. None the less it would’ve been an impressive growth rate. Although in hindsight it seems somewhat obvious, I didn’t realize ETH was a major coin being held by PyTrader. That does change the meaning of the results a good bit. I was curious how the buying tactic worked, I would’ve assumed more of the 2nd tactic (buy and then sell shortly after). I do think an evaluation of actual profitability would be valuable. Although the “Managing Fees” section feels like wrong place to be posting this, I’ll at least mention it. A quick way would be create a theoretical control group: (if you bought 1 BTC/ETH and held it for the same two months) and compare the profits. A second much more rigorous method (what I would do before even investing 1 real BTC) would be to get a collection of data from different markets and simulate PyTrader at random segments on them. This would be a true experiment and give a good idea of the actual profitability of the algorithm in the general market. But, I imagine this would take quite a bit of computation power. Do you have a general estimate of how long it would take a $900 PC running 24/7 to simulate 2 months of trading? (assuming all the code is modified somehow for this to happen) There should probably be a well documented evaluation section before any specific profitability projections are discussed with any seriousness. |
I can see why you'd assume that -- The repo, when I open sourced it, exclusively does this (see trade.opposite_trade on the trade model). I added this logic sometime in late February / early March 2016.
Part of the reason I didnt do this is that one would have to simulate the exchange and the filling (or partial filling, or not filling at all) of orders. I am not quite sure exactly how to simulate the logic of whether an exchange fills an order, but am open to suggestions.
It depends on how frequently the trade is making trade decisions. If the analysis is every 5 minutes, we'd need 12x the compute power than if it's every 1 hour. If I had to put my finger in the air and make a guesstimate, I'd have to think we could simulate 2 months of trading for 1 hour granularity on the order of minutes, maybe hours, with the present codebase.
Agree. I've begun tracking a 'further analysis of initial results' issue @ #32 and an issue for evaluation of trading models @ #33 |
I will have PR ready after work today in which I begin attempting to manage the fees. I'll post it around 6pm MST if anyone on the thread would like to code review. |
The text was updated successfully, but these errors were encountered: