Always use lowest/highest price for buy/sell loss protection

[defkev]

On consecutive buys/sells the bot would always use the last price for loss protection, which could lead to a potential (sic) loss if the last price is below/above (depending on the order type) any previous price of the same order type.

To overcome this we will lookup all previous orders (of the same type) and adjust last price to the highest/lowest within the previous orders.

Will this isn't a true FIFO (as we don't account for any amount bought/sold) it goes in the same direction by always "aiming" for a profit.

This completely removes held_pct, which i presume was supposed to accomplish the same but seems to be causing a bug preventing the bot from doing consequtive buys.

Also some linter fixes will i am already at it.

Tester welcome!

Closes #1389 & #1463

[stinkyjames]

Is it possible to log buy_price and coin_amount for each buy action? Then when the sell side is executed it references the buy_price with the associated coin_amount and will only sell above the buy_price with the same coin_amount? So we can have a few buys and when the sell side happens, it will sell each coin_amount at a higher value of the same coin_amount.

For example:

a buy, buy, sell, sell happens

buy = a.b_p @ $100 for 0.001 BTC
buy = b.b_p @ $200 for 0.0025 BTC

sell = a.s_p @ $210 for 0.0025 BTC
sell = b.s_p @ $125 for 0.001 BTC

I want the sell side to only sell the exact amount of coins purchased at the specified markup in the conf.js file. This would correctly address our FILO needs.

[defkev]

As i wrote, this indeed isn't a true FIFO as we don't account for any amount bought/sold.

The PR doesn't alter the bots trading behavior, it will simply prevent the bot from potential loss by always buying/selling with a profit by aiming for the highest/lowest price within all previous opposite orders up to the last identical signal.

e.g. on a [email protected] - [email protected] - [email protected] (instead of last) - [email protected] - [email protected] (instead of last) the bot will use the highest buy price of the first two buys during the first sell and the lowest sell price during the third buy.

Doing a proper FIFO/LIFO is definitely doable, as we keep a list of executed orders it would simply be a matter of using the completed order size closest to the current market price will creating the order on a signal to use for buy|sell_pct

But as a change like this would alter the bots default trading behavior it would need to be implemented as a opt-in feature, something like a accounting = 'FIFO' // or LIFO

[stinkyjames]

How much work would be required to do a FILO for the sell side to reference the buy side? I think with this option, we would be able to make money with all our trades, even when the price of the coins drop, the bot can still make purchases as it goes down, increasing its opportunities to make money as the coins value return at a later time, instead of waiting for the coin's value to return to its pike price of the first buy in when the coin value started to drop.

I've also tested the engine.js modification from above and I wasn't able to get it to work. The buy and sell shows complete as soon as it is placed but it appears the bids are just cancelled.

[defkev]

Now this sounds more like a strategy you are talking about.

The buy and sell shows complete as soon as it is placed but it appears the bids are just cancelled

Thats not possible to be related to this commit, it simply alters the last_price which only affect loss protection.
I am running this on four different bots for ~1 day and haven't seen anything odd yet after multiple trades.

[stinkyjames]

Let me look at my strategy.js. I’m using trend_ema and corrected the “buy” and “sell” trigger.

In the meantime, do you plan to do a true FILO option? Also, thank you for being so responsive.

[defkev]

I am always interested in stuff increasing possible profit 😁

But as i am not an Accountant i would need to do some research first to make sure i don't mess it up in the progress.

[stinkyjames]

We will always make money if we treat every buy seperate from one another. As value of the coin dips and bot continues to pick up coins, there will be more opportunities for it to sell the coins back and make profit as it increases instead of getting stuck at the top of the dip, it will pick up more coins on the way down and sell those coins as the value recovers to above the purchase price of each buy. If you draw a graph or put it in a spreadsheet you will see we can make more on the dips than if the coin only raises in value. If the coin is bullish, it’s better to hold, but when the coin is bearish it’s good to make purchases on the way down. Lock the price at the highest price limits how much and how often we can sell. If we have it sell above each of the buy, we can gain profit on each buy and its respective amount.

[defkev]

In normal "Trade" mode the bot only trades if he receives a signal from the strategy used, such a signal can only get emitted on a period (the length of a period is defined by --period|period_length)

The size of an order can be defined by --buy|sell_pct

Assuming you set both to 10% (without defining --buy_max_amt) the bot would sell 10% chunks of your asset on each period and buy using 10% chunks of your balance, again on each period, depending on the strategy.

Usually you would want to sell on a down trend/bearish and buy on up trend/bullish to maximize your profit.

[stinkyjames]

You're correct about buying on trends. In a buy buy sell sell scenario, what I'm trying to prevent is the second sell from selling lower than the first buy. One solution is with FILO, or have it remember the purchase price and amount of the coin, and only sell that amount for higher than the purchase price for every buy. It will work for buy buy buy sell sell sell scenarios since it will treat every buy independent of the other buys. So if one buy was purchased at a high price, it will hold it until the price returns to above that level while still being able to buy more coins and selling those coins at the lower prices. Basically the bot can still make trades without worrying about it selling the one that was purchased at the high price or wait for the price to return to the high price while buying and selling at the new lower price. If the bot references only the purchases at the highest price, and the price doesn't return to that level, the bot won't make any sell, but if the bot is able to reference each buy price, and only need to beat the last buy price, it will make money for the last purchase, and then move on to the next buy price. If we can truly get a FiLO of the buy prices, it will be so amazing!

[defkev]

what I'm trying to prevent is the second sell from selling lower than the first buy

So do i.

I refactored the whole thing using lodash (should've done this initially 🙈) to also account for previous buys on a second (+ consecutive) sell and vice versa.
Furthermore it will now include previous trades in the calculation, if available.

This still doesn't cover the amount bought/sold, as this goes in the direction of buy|sell_pct rather than max_buy|sell_loss_pct, which this PR is about.

I'll test drive it for a bit and see how it goes.

Unfortunately my primary exchange (with my test wallet) is currently down for maintenance, so its going to take a while.

[stinkyjames]

Awesome! I’m a patient person. As long as you can figure out the first in last out for the sell side to reference the buy side’s first in last out, we will be golden.

[stinkyjames]

Every time it cancels, it logs the cancel as a trade. You can see the cancels in the output html in the stat folder. There's something incorrect in the trade.js file. Everything else looks promising. Thank you for the amazing work.

[defkev]

Every time it cancels, it logs the cancel as a trade.

Sounds like #1482

[stinkyjames]

Followed #1482 and the issue was resolved. Thank you for the link!

[DeviaVir]

@defkev these changes LGTM and don't introduce any issues afaict, ready to merge?

[defkev]

Go ahead