Not lending BTC due to low rate - Misguided?

[utdrmac]

This started happening yesterday it seems. I have mindailyrate = 0.009 in default.cfg and are keeping 90 days worth of BTC market data. The bot is giving me the notice above yet when I go in to PX and manually create a loan for 1BTC @ 0.023%, it is picked up immediately.

I'm not sure what else to report here other than the behavior I'm experiencing. I'm on master branch @ f6fec7a3172bfb42d0131ba97fc0dac6cbab51e8

[NeuralMiner]

It probably has to do with you having market analysis turned on. Turn it off and see if it starts lending again. If it does, it's because MA is setting a higher min rate. I had the same issue: https://github.com/Mikadily/poloniexlendingbot/issues/212

[utdrmac]

Done. Working again. Thanks.

This is still a bug though right? I thought the purpose behind market analysis was to calculate competitive rates based on historical rates. If that calculated rate fell below mindailyrate, only in that case, halt lending.

[rnevet]

not a bug, right now the Analysis rate is using the same mechanism as mindailyrate- i.e. either halt lending or place loan at that rate depending on hideCoins. Currently Analysis is a percentile calculation, lendingStyle defines the percentile - 50 will be the median, meaning 50% of the min rates the bot saw were under this rate. I would argue that 75 is quite aggressive.

[Evanito]

The analysis was meant to create an automatic and dynamic mindailyrate for each coin. Itis tailored to never go below what is considered "bad" for that coin's market, based on your settings. It does this using a percentile of the markets previous rates, allowing you to pick a percentage (called lending_style by the bot) to lend at. This percentage n will be the percentage where n% of offers in the analysed history are below the rate that is chosen to be the new mindailyrate.

Quick example:

BTC Historical rates (fake):    | Sorts to:
0.01                            | 0.0001             (This is index 0)
0.003                           | 0.003
0.1                             | 0.01
0.0001                          | 0.1
1.0                             | 1

Lending style: 75 New rate's index: 5 (number of items in list) * .75 (lending style) = 3.75 Since 3.75 isn't a perfect index, we handle it two ways:

• If numpy is installed, linearly calculate the difference between the 4th and 5th sorted option. Would end up being (.25)(0.1)+(.75)(1) = 0.775
• If numpy is not installed, simply floor() the index to 3. Comes out to 0.1

The calculated value, 0.775 or 0.1, would then become a temporary mindailyrate for that coin. (Unless the real mindailyrate is higher, then it will still use that.)

Side note: that accuracy is why we want users to use numpy. Side side note: Users would not need to use numpy if I just included those raw calculations in the code. ✌️

[utdrmac]

I'm not understanding the reason on why the minimum lending rate needs to be dynamic? If I set the mindailyrate to 0.005, then any rate higher than that should be accepted. Why does a new mindailyrate need to be calculated? What benefit is there to having this?

The 'current rate' needs to be calculated based off the last X% lends to provide a competitive lending rate; which works. No issues here. But again, why does the minimum need to fluctuate?

This feels like two different functions of code competing against each other. 'Current rate code' says "based off the last X historical lends, I've calculated the best lending rate to be Y% so we should lend Z coins at Y% to be competitive."

But then, 'min daily rate code' says "well, I too have been analyzing the last X lends and even though the user set our min rate to be A%, I've calculated a new minimum rate of B%. Even though B% is greater than A%, since Y% is less than B%, I refuse to let you lend those coins."

[Evanito]

Would you like to suggest an alternate method? I made the MarketAnalysis module capable of running several different algorithms based on the available data, but only implemented one that adjusts the mindailyrate. If you have a suggestion for another algo, it is possible we could implement it and add an option to toggle them on/off.

[utdrmac]

As my previous comment stated, I'm not understanding why this is needed. Could you explain it? Why is there a need to have a changing/calculated mindailyrate? Could you give me an example situation where (offered-calculated-rate > mindailyrate-as-configured && offered-calculated-rate < mindailyrate-as-calculated) = don't offer lends

[rnevet]

@utdrmac I basically agree - I will submit a change seperating the minLendingRate from the Analysis result which should be taken into consideration for spreading offers.

[utdrmac]

Is a changing/calculated mindailyrate intended to protect me in some way? If so, how?

[rnevet]

No, it's just a simplification of the implementation as the Analysis will suggest the "rate to place offers" it has a very similar functionality as mindailyrate which prevents lending below it.

[rnevet]

Currently the logic is:

1. Don't lend below minDailyRate
2. if analysis rate is above minDailyRate don't lend below analysis rate - in my opinion, this should be changed to spread orders above analysis rate.

[Evanito]

@rnevet I do like that idea @utdrmac It was meant to stop lending when a market dips below what is expected of it, then resume lending once it is where the market usually is. Basically, it was meant to avoid getting caught in dips in rates.

Edit: In the future I did want to take into account the standard deviation of a market as a "volatility rating" and account for risk that way, by holding out for a better rate in volatile markets.

[utdrmac]

@Evanito Ok. I can sortta understand that. However, if you're already calculating an offerable-rate based on current market analysis, as long as you're above min-rate-configured, shouldn't that be OK? Otherwise, you're not making anything. Thanks for the discussion!

[ghost]

@Evanto Perhaps the algorithm could factor in the time of day? I analyzed a month's worth of data for BTC and ETH and was surprised to find that there were times of the day that had significantly higher rates than other times. The algorithm could detect a historical dip and then calculate whether waiting a few hours for the historical rise is likely to pay off. If not, it could then lend based on the minDailyRate.

I didn't analyze weekends vs. weekdays but that could be worth considering also.