portfolioManager / refresh-balance / Request for comments (post-LocalDB merge)

[kuzetsa]

https://github.com/askmike/gekko/blame/72ab99fabf2df42a4cc2c711ec2bd96f3902338a/portfolioManager.js#L57-L75

... I'm trying to figure out if the following code already does the same thing as my earlier patch:

https://github.com/askmike/gekko/blame/master/core/portfolioManager.js#L65-L69

Is the logic to update the portfolio balance prior to displaying simply moved elsewhere?

I'd appreciate any guidance you might be able to give over the next month or so as I reimplement feature & bug compatibility with similar to the older pre-LocalDB code in https://github.com/kuzetsa/gekko/tree/refresh-balance as per pull #67

[askmike]

(I just noticed some bugs, so please check the version I just comitted)

I don't exactly remember the behaviour pre-localDB but I'll tell explain the current behaviour:

• The trading methods (you can use either PPO, MACD or DEMA - last one is the old EMA) advice either to go long (in uptrend) or to go short (in downtrend). See the this discussion, I'm open for new behaviour as long as it does not break all other plugins that only rely single advice changes.
• If the advice is long (so from the point we detect an uptrend until we detect a downtrend) and the exchange is cex.io Gekko will recheck every 5 minutes if there are new payouts to reinvest. If there are Gekko will do this. If the advice is short Gekko will recheck every 5 minutes, but not reinvest anything.

Not quite sure what else you want to know? The whole core / infrastructure is completely rewritten.

(I'm closing this as it's not an issue concerning the master branch, but please just keep on commenting)

[kuzetsa]

one of your comments on #171 links to a broken link. Here's the particular quote I'm curious about:

Though it needs to be thought out, put in the spec and implemented.

I'm not sure what you mean to put it in "the spec" is, or what you meant, and since it comes up 404 I just thought I'd better ask.

As a followup / my main concern about behaviour which I'm wanting to replicate (reproduce how I had things working in the pre-LocalDB branch)

The criteria I have for "successfully replicating previous behavior" are as follows:

1. Portfolio on cex.io must be kept current for GHS and BTC balance
2. gekko needs to be able to check every few minutes to see if currently in an uptrend
3. if an uptrend is detected (regardless of if it was already in an uptrend or not) reinvest to buy more GHS

It's a simple "buy and hold" strategy which predicts the current price is lower than it will be at a later time (minutes, hours, etc... it's on an uptrend after all) so the logic just assumes that GHS will produce income in addition to the increase in GHS price.

For my own purposes, I just tweaked the EMA sell threshold to a VERY low value (-201) in order to guarantee that there would never be a panic sell if price drops.

During the price drop, the logic is "stop buying during the downtrend since there will be a better price soon"

I mainly just wanted to figure out if the current version of gekko could:

1. Maintain an accurate account of GHS and BTC portfolio balance
2. core functionality still works (realtime watching for trends)
3. Ability to CONTINUOUSLY reinvest during an uptrend.

As for point 3, that is to say:

I previously had the ability to edit a couple lines of code to disable any checks which would prevent trades in rapid succession in an attempt to save fees. NOT RELEVANT on cex.io since no fees

git blame / example:

https://github.com/kuzetsa/gekko/blame/916aab03d4ca3c8ece15c47fb2499e5c4d1af2af/methods/exponential-moving-averages.js#L162-L167

Note: The numbered 3 bullet point thinger matches on both, I just worded it slightly different on each

[kuzetsa]

I know the above post was a TLDR, sorry about that.

There happened to be a discussion on the "quick hack" commit I had on my own Pre-LocalDB branch:

kuzetsa@916aab0

(commit / discussion is the above linked "git blame" / "example" but no line numbers marked)

Edited to add:

Just thought I'd like to point out real quick before I go AFK for a few hours...

That "quick hack" worked without issue for over a month, and it only finally stopped working around the time cex.io changed their APIs and resulted in the start of a period when NOBODY had a working version of gekko with live trades on cex.io

[askmike]

The short version of answering your points:

• Maintain an accurate account of GHS and BTC portfolio balance

Yes, when you are using CEX.io Gekko will recheck this always every 5 minutes.

• core functionality still works (realtime watching for trends)

Should be fully working, I consider it stable.

• Ability to CONTINUOUSLY reinvest during an uptrend.

Yes, every 5 minutes Gekko will check and if you are in a long position (uptrend) Gekko will reinvest right away (assuming the payout was bigger than the minimal order size of 0.000001 BTC).

---

The whole discussion in #171 was about what to do with trends that go flat. The idea in your fork as well as the pre localDB was that the trading method (EMA) could trigger a downtrend, an uptrend and a flat trend. This way we can reinvest only in uptrends, not in downtrends or flat trends.

Since the localDB version Gekko relies on a more decoupled infrastructure: the advice event (long or short) will be consumed by many moving parts (like plugins). All those parts don't care about a flat line since in 99% of the cases you only want to move into a new position (and when you detect a flat line you don't move your position normally).

So all moving parts broke when Gekko propagated all those states (for example in a up - flat - up scenario all parts would get up twice in a row since they'd ignore flat). Therefor the design is now simplified so that only long (up) / short (down) is propagated. According to this spec:

https://github.com/askmike/gekko/blob/master/docs/internals/plugins.md#implementing-a-new-plugin

(the link broke because it is still pointing to the localdb branch which got merged into master)

So in your scenario Gekko is reinvesting any time the last advice was an uptrend, and never when the last advice was a downtrend. In your specific scenario this does not work because you never hit a downtrend.

So there are two possible solutions:

• You fork this new version again with the hope that this Gekko does not have major flaws that will be addressed in the future (you'd have to keep the fork up to date) or that the cexio API changes again.
• You come up with a new solution that satisfies both clients who want to act on every new advice (like: the mailer) but only when an advice is new (so the trader shouldn't try to rebuy after up - flat - up), the spec needs to reflect this new design.

EDIT:

third possible solution: use a down treshold that reflect a flat trend for you (so that in a flat trend Gekko would advice 'go short') and manually disable the sell function so that if Gekko says short you are not selling anything ever.

[kuzetsa]

Yes, every 5 minutes Gekko will check and if you are in a long position (uptrend) Gekko will reinvest right away (assuming the payout was bigger than the minimal order size of 0.000001 BTC).

Based on that statement, it sounds like you're saying post-merge (LocalDB) gekko now defaults to continual reinvesting on cex.io?

If so, I probably won't have any issue and will just need to manually disable selling.

[askmike]

it sounds like you're saying post-merge (LocalDB) gekko now defaults to continual reinvesting on cex.io?

Yes, every 5 minutes (as long as the last advice was to go long).