Skip to content
This repository has been archived by the owner on Feb 16, 2020. It is now read-only.

Need a better algorithm for CEX trading. #86

Closed
streetlogics opened this issue Dec 19, 2013 · 14 comments
Closed

Need a better algorithm for CEX trading. #86

streetlogics opened this issue Dec 19, 2013 · 14 comments

Comments

@streetlogics
Copy link
Contributor

the default 10/21 algorithm doesn't work well with CEX. Have heard talks of trying to get support around this and wanted to put in an official "ticket" for this specifically.

@paraghardas
Copy link

Here is a basic idea which I would like to implement ...

  • Let us asume GHS/BTC is on 0.0750 on cex.io
  • Let us asume we have 10 GHS and 1 BTC in our account
  • To start with ... while on 0.0750 ... our script will put a small (0.1 ghs) buy order on 0.0740 and a small (0.1 ghs) sell order 0.0760
    (I have asumed a difference of 0.0010 which can be any variable)
  • Now let us asume the price rises and reaches 0.0760 . At this point the sell order will get executed and our script will place one more small (0.1 ghs) buy order on 0.0750 and a small (0.1 ghs) sell order on 0.0770 (the idea is ... what we sold on 0.0760 must be bought on 0.0750 giving us a profit.)
  • Asume the price rises more and reaches 0.0770 . At this point our previous sell order of 0.0770 will get executed and our script will place one more small (0.1 ghs) buy order on 0.0760 and a small (0.1 ghs) sell order 0.0780
  • Now our profit will start showing when the price falls and reaches 0.0760 . At this time our buy order will get executed and we will have a profit ratio of (0.0770-0.0760) that is of 0.0010 ... as we have traded 0.1ghs our actual profit will be 0.0001 ghs.
  • At this point again we will place an sell order at 0.0770
  • when the price reaches down more ... then at 0.0750 our buy order will get executed and we will again have a profit of 0.0001 ghs.
  • Here again place a sell order of 0.0760
  • So at every price movement of 0.0010 we will have either a buy or sell order depending upon weather the price is going up or down. And at every rise and fall of 0.0010 we will profit 0.0001 ghs.

This is the basic idea ... more fine tuning for money management can be done once we are able to achieve the grid orders. There is no question of loss ... because at any point we will either have more GHS or More BTC and we have never closed any order in loss.

I will also try to make a rough / raw logic flow chart if you think the project will be interesting.
Also I am open to have a conversation with anyone on skype.

Parag

@streetlogics
Copy link
Contributor Author

There's now a #gekkobot IRC chat on freenode if anyone is interested in chatting it up there. @askmike - we should think about adding the irc channel to the read me.

@paraghardas
Copy link

Tried to draw a flow chat ... In my example below there is no need to fetch historical data and also there is no need to make any database entries ... what we need to fetch from cex.io is just the current value of GHS/BTC and details of all open orders ... see if this can help ...

cex_io_grid

@paraghardas
Copy link

Hello,
Any progress on this one???

@askmike
Copy link
Owner

askmike commented Dec 30, 2013

@paraghardas sorry for not responding earlier, this looks very interesting thanks!

It looks great but before I can go into it really Gekko needs some updates before it is able to store CEX.io since there latest API update. Read more about that here.

So before we can even think about trading methods on CEX.io we need to have Gekko working on CEX.io, which is a lot of work due to their API restrictions.

@paraghardas
Copy link

I can understand ... but this method does not require to fetch historical data (which seems to be the problem right now) ... as its a simple buy and sell the CEX.IO bot can be up and running in few days ... besides I am successful in trading this method manually even in this recent blood bath on CEX ... only problem is that we have to sit all the time on terminal which is very inconvenient hence a bot.
I am not stressing to take this up ... but some profitability will start to show immediately while we keep working on other issues.
Regards and wish everyone a very happy new year.

@nicobrion
Copy link

@paraghardas can you please share more details on this method, and possibly the code? I would like to do some backtesting and validation.

Thanks, and happy new year for you as well.

@djmuk
Copy link
Contributor

djmuk commented Dec 31, 2013

I am working on a MACD algo - I need to validate the logic and buy/sell decision making.

@askmike
Copy link
Owner

askmike commented Dec 31, 2013

@djmuk if you want to incorporate the new method into Gekko (I was planning on writing MACD as well, just haven't started yet), please make sure you are basing it on the latest version of localDB:

The raw EMA calculation is now an indicator. The EMAC (the current method, a crossover of 2 EMA values) leverages this indicator. MACD is basically a basically a bunch of raw EMAs calculated on top of eachother, to implement this you can use the indicator straight away. Also for the method is expected to communicate differently now, take a look at the rewrite.


At everyone else:

I don't really understand why we are looking at trends for CEX.io, as the value of 1 GHS depends not only on the value for which you can sell it, but also on how much BTC it will mine for you. I propose a new method that doesn't look at trends but uses an online mining profit calculator to determine how much BTC 1 GHS is going to bring you, if the price is < profit, buy all the GHS and if the profit is < price sell all the GHS.

I will write this when my todo list is a bit smaller, so I'm putting a bounty out if someone can do it before me: If someone can implement it (in the localDB branch) I will pay that person 0.01 BTC (Remember I am poor because I opensourced Gekko)!

Expectations:

  • Same coding style as the EMAC / core.
  • Uses an online mining calculator to figure out how much profit 1 GHS will bring you. The settings need to be configurable in config.js (settings are stuff like block halving time / diff increase time / diff increase %).
  • If it will profit more than the current price, emit long advice. If it will profit less than current price, emit short advice.
  • Needs to be plugged into the tradeAdvisor just like the EMAC is.

EDIT: lowered the price to around 10 bucks, was confused by price. This edit was in < 1 min after post.
EDIT2: I'm obv. only paying out the bounty once, and to the first pull request that satisfies all expectations.

@djmuk
Copy link
Contributor

djmuk commented Dec 31, 2013

Mike - am running current localdb branch. Method is entirely self contained and needs no changes to other files. It is basically a hack of the EMA file as of last night ('Glued cm to EMA method').
Have just looked at the commit list - will revert my local changes and resync then put them back!
Just a comment - I want to use the VAWP rather than the closing price as being more representative (rather than a random sample of the trading at that point) but the indicator is hard wired to the candle.c price. is it possible to pass the price rather than the candle into the ema calculator? so the call in the method would be this.ema[type].update(candle.c); rather than this.ema[type].update(candle); ?

@djmuk
Copy link
Contributor

djmuk commented Dec 31, 2013

Now rewritten to match new structure. If I do a commit will that put it into the codebase or do you have to then accept the commit?

@askmike
Copy link
Owner

askmike commented Jan 1, 2014

@djmuk yes, you probably forked or cloned it. You probably need to do a commit & push to djmuk/gekko and than create a pull request for your updated branch into askmike/gekko's localDB branch.

I want to use the VAWP rather than the closing price as being more representative (rather than a random sample of the trading at that point) but the indicator is hard wired to the candle.c price. is it possible to pass the price rather than the candle into the ema calculator? so the call in the method would be this.ema[type].update(candle.c); rather than this.ema[type].update(candle); ?

Yes you can rewrite it so it passes a value to the raw EMA method instead of a whole candle, just make sure it uses the close for my existing method instead of the vwp.

@yin
Copy link
Contributor

yin commented Jan 1, 2014

Read up https://help.github.com/articles/using-pull-requests

Might be useful to have a short walk trough the process... First make sure
you forked Mike's repository. If you just cloned, fork now and add your
forked repo url as a new remote. After you created a commit on a local
branch, push the branch to your github an open up your project page and
here'll be a suggestion to create the pull request. That's the moment Mike
is supposed to look into it, merge manually, test and push back. You can
get Mikes updates back, if you have/add his repo as remote and pull from it.

regards
-- Matej

On Tue, Dec 31, 2013 at 11:19 PM, djmuk notifications@github.com wrote:

Now rewritten to match new structure. If I do a commit will that put it
into the codebase or do you have to then accept the commit?


Reply to this email directly or view it on GitHubhttps://github.com//issues/86#issuecomment-31413458
.

@djmuk
Copy link
Contributor

djmuk commented Jan 1, 2014

@yin thanks just what I needed!
Forked & pull request sent.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants