Bot couldn't sell because of insufficient fund #1371
Comments
|
i think the critical logs are in the buy section: this seems odd - could you please compare the contents of the database fort this trade with the binance UI to check what did change? The best thing is that you have the whole logs available - this will help a TON in investigating this issue. I wonder if it's got to do with the rounding / truncating applied (but that's just thinking out loud so i don't forget that train of thought) |
xmatthias
added
Bug
CCXT
|
@xmatthias while we are on it ... do we really need def price_to_precision(self, symbol, price):
return self.decimal_to_precision(price, ROUND, self.markets[symbol]['precision']['price'], self.precisionMode)
def amount_to_precision(self, symbol, amount):
return self.decimal_to_precision(amount, TRUNCATE, self.markets[symbol]['precision']['amount'], self.precisionMode) |
|
i was honestly never convince that we do, however the original PR had a solid explanation as to why ... but i don't remember that :( will try to find the PR for reference - hopefully that'll give us some insight pr with discussions was #1083 ccxt does not round the same way than freqtrade does
I'm not saying one is better than the other ... |
|
Unfortunately, I lost the full logs. I just checked my binance orders, the amount showing there is xxx.51969 and I remember the amount showing in the logs was something like xxx.5197xxxx I don't think it's because of rounding/truncating because I am sure it wasn't xxx.51970000 I have actually done some local changes and the bot has been running fine for days. But I still don't know how the bot got the wrong amount though. |
|
@xmatthias have tons of order failed because we don't use I read the PR, I am not convinced ... |
|
The precision filters are fine, I use them a lot.
I would suggest from the list of filters binance provide FT runs it's order
against the ones not being checked.
Min notional, Min and Max amount and price as example.
Precision will not help an order that's not passing those.
…On Fri, Dec 14, 2018, 6:48 PM Misagh ***@***.*** wrote:
@xmatthias <https://github.com/xmatthias> have tons of order failed
because we don't use self.price_to_precisionand self. amount_to_precision
of ccxt:
Message: binance order price is invalid, i.e. exceeds allowed price precision, exceeds min price or max price limits or is invalid float value in general, use self.price_to_precision(symbol, amount) {"code":-1013,"msg":"Filter failure: PRICE_FILTER"}
I read the PR, I am not convinced ...
If @creslinux <https://github.com/creslinux> does not react, then I think
we should remplace those functions with CCXT.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw89mv1B-pamU540U-OX3qzWZJ35hks5u49ZkgaJpZM4Y5Z2W>
.
|
|
Check order amounts/quantities.
The way edge is calculating risk not on full portfolio worth, it's position
sizes are going to be tiny sums which may do not meet minimum amounts
binance accepts.
Also check the info{} dict inside ccxt message. It will contain the actual
error message which filter is rejecting the order.
…On Fri, Dec 14, 2018, 7:17 PM Danny ***@***.*** wrote:
The precision filters are fine, I use them a lot.
I would suggest from the list of filters binance provide FT runs it's
order against the ones not being checked.
Min notional, Min and Max amount and price as example.
Precision will not help an order that's not passing those.
On Fri, Dec 14, 2018, 6:48 PM Misagh ***@***.*** wrote:
> @xmatthias <https://github.com/xmatthias> have tons of order failed
> because we don't use self.price_to_precisionand self. amount_to_precision
> of ccxt:
>
> Message: binance order price is invalid, i.e. exceeds allowed price precision, exceeds min price or max price limits or is invalid float value in general, use self.price_to_precision(symbol, amount) {"code":-1013,"msg":"Filter failure: PRICE_FILTER"}
>
> I read the PR, I am not convinced ...
> If @creslinux <https://github.com/creslinux> does not react, then I
> think we should remplace those functions with CCXT.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AhCkw89mv1B-pamU540U-OX3qzWZJ35hks5u49ZkgaJpZM4Y5Z2W>
> .
>
|
|
Here are the list of filters, in addition to precision a binance order must
pass:
Each pair has its own values for each filter, they'e embedded in
exchangeInfo()
Filters
Filters define trading rules on a symbol or an exchange. Filters come in
two forms: symbol filters and exchange filters.
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#symbol-filters>Symbol
filters
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#price_filter>
PRICE_FILTER
The PRICE_FILTER defines the price rules for a symbol. There are 3 parts:
- minPrice defines the minimum price/stopPrice allowed; disabled on
minPrice == 0.
- maxPrice defines the maximum price/stopPrice allowed; disabled on
maxPrice == 0.
- tickSize defines the intervals that a price/stopPrice can be
increased/decreased by; disabled on tickSize == 0.
Any of the above variables can be set to 0, which disables that rule
in the price
filter. In order to pass the price filter, the following must be true for
price/stopPrice of the enabled rules:
- price >= minPrice
- price <= maxPrice
- (price-minPrice) % tickSize == 0
/exchangeInfo format:
{
"filterType": "PRICE_FILTER",
"minPrice": "0.00000100",
"maxPrice": "100000.00000000",
"tickSize": "0.00000100"
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#percent_price>
PERCENT_PRICE
The PERCENT_PRICE filter defines valid range for a price based on the
average of the previous trades. avgPriceMins is the number of minutes the
average price is calculated over. 0 means the last price is used.
In order to pass the percent price, the following must be true for price:
- price <= weightedAveragePrice * multiplierUp
- price >= weightedAveragePrice * multiplierDown
/exchangeInfo format:
{
"filterType": "PERCENT_PRICE",
"multiplierUp": "1.3000",
"multiplierDown": "0.7000",
"avgPriceMins": 5
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#lot_size>
LOT_SIZE
The LOT_SIZE filter defines the quantity (aka "lots" in auction terms)
rules for a symbol. There are 3 parts:
- minQty defines the minimum quantity/icebergQty allowed.
- maxQty defines the maximum quantity/icebergQty allowed.
- stepSize defines the intervals that a quantity/icebergQty can be
increased/decreased by.
In order to pass the lot size, the following must be true for quantity/
icebergQty:
- quantity >= minQty
- quantity <= maxQty
- (quantity-minQty) % stepSize == 0
/exchangeInfo format:
{
"filterType": "LOT_SIZE",
"minQty": "0.00100000",
"maxQty": "100000.00000000",
"stepSize": "0.00100000"
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#min_notional>
MIN_NOTIONAL
The MIN_NOTIONAL filter defines the minimum notional value allowed for an
order on a symbol. An order's notional value is the price * quantity.
applyToMarket determines whether or not the MIN_NOTIONAL filter will also
be applied to MARKET orders. Since MARKET orders have no price, the average
price is used over the last avgPriceMins minutes.avgPriceMins is the number
of minutes the average price is calculated over. 0 means the last price is
used.
/exchangeInfo format:
{
"filterType": "MIN_NOTIONAL",
"minNotional": "0.00100000",
"applyToMarket": true,
"avgPriceMins": 5
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#iceberg_parts>
ICEBERG_PARTS
The ICEBERG_PARTS filter defines the maximum parts an iceberg order can
have. The number of ICEBERG_PARTS is defined as CEIL(qty / icebergQty).
/exchangeInfo format:
{
"filterType": "ICEBERG_PARTS",
"limit": 10
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#market_lot_size>
MARKET_LOT_SIZE
The MARKET_LOT_SIZE filter defines the quantity (aka "lots" in auction
terms) rules for MARKET orders on a symbol. There are 3 parts:
- minQty defines the minimum quantity allowed.
- maxQty defines the maximum quantity allowed.
- stepSize defines the intervals that a quantity can be
increased/decreased by.
In order to pass the market lot size, the following must be true for
quantity:
- quantity >= minQty
- quantity <= maxQty
- (quantity-minQty) % stepSize == 0
/exchangeInfo format:
{
"filterType": "MARKET_LOT_SIZE",
"minQty": "0.00100000",
"maxQty": "100000.00000000",
"stepSize": "0.00100000"
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#max_num_orders>
MAX_NUM_ORDERS
The MAX_NUM_ORDERS filter defines the maximum number of orders an account
is allowed to have open on a symbol. Note that both "algo" orders and
normal orders are counted for this filter.
/exchangeInfo format:
{
"filterType": "MAX_NUM_ORDERS",
"limit": 25
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#max_num_algo_orders>
MAX_NUM_ALGO_ORDERS
The MAX_NUM_ALGO_ORDERS filter defines the maximum number of "algo" orders
an account is allowed to have open on a symbol. "Algo" orders are STOP_LOSS
, STOP_LOSS_LIMIT, TAKE_PROFIT, and TAKE_PROFIT_LIMIT orders.
/exchangeInfo format:
{
"filterType": "MAX_ALGO_ORDERS",
"maxNumAlgoOrders": 5
}
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#max_num_iceberg_orders>
MAX_NUM_ICEBERG_ORDERS
The MAX_NUM_ICEBERG_ORDERS filter defines the maximum number of ICEBERG orders
an account is allowed to have open on a symbol. An ICEBERG order is any
order where the icebergQty is > 0.
/exchangeInfo format:
{
"filterType": "MAX_NUM_ICEBERG_ORDERS",
"maxNumIcebergOrders": 5
}
…On Fri, 14 Dec 2018 at 17:22, Danny ***@***.***> wrote:
Check order amounts/quantities.
The way edge is calculating risk not on full portfolio worth, it's
position sizes are going to be tiny sums which may do not meet minimum
amounts binance accepts.
Also check the info{} dict inside ccxt message. It will contain the actual
error message which filter is rejecting the order.
On Fri, Dec 14, 2018, 7:17 PM Danny ***@***.*** wrote:
> The precision filters are fine, I use them a lot.
>
> I would suggest from the list of filters binance provide FT runs it's
> order against the ones not being checked.
>
> Min notional, Min and Max amount and price as example.
>
> Precision will not help an order that's not passing those.
>
>
>
>
> On Fri, Dec 14, 2018, 6:48 PM Misagh ***@***.*** wrote:
>
>> @xmatthias <https://github.com/xmatthias> have tons of order failed
>> because we don't use self.price_to_precisionand self.
>> amount_to_precision of ccxt:
>>
>> Message: binance order price is invalid, i.e. exceeds allowed price precision, exceeds min price or max price limits or is invalid float value in general, use self.price_to_precision(symbol, amount) {"code":-1013,"msg":"Filter failure: PRICE_FILTER"}
>>
>> I read the PR, I am not convinced ...
>> If @creslinux <https://github.com/creslinux> does not react, then I
>> think we should remplace those functions with CCXT.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#1371 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AhCkw89mv1B-pamU540U-OX3qzWZJ35hks5u49ZkgaJpZM4Y5Z2W>
>> .
>>
>
|
|
@mishaker as mentioned before, i'm not tied to our logic to calculate precisions and would prefer to relie on ccxt handling that. and yes - also the other info (min-notational, ...) will absolutely need to be considered. ccxt does have that available easily and unified - in |
|
Guys, strongly suggest create a binance subclass and be done with it.
Youre going to end up with a hundred IF's to manage all the specific
binance stuff ccxt does not give you.
You need ALL the filters to not bounce trades frequently - drop it in the
subclass.
CCXT is the lowest common denominator - you cant trade on it without being
at such a disadvantage to other traders.
Or your money at such a disadvantage to be more accurate
AS example of some the things you're going to end up having to manage
explicitly for binance that are not common in ccxt.
if id == bianance:
-- this filter
-- that filter
-- another filter
if id == binance
order-type-a param timinginforce =
order-type-b param timinginforce =
if id == binance
stop_loss = stop_loss_limit
param stop_price ==
if id == binance
ulrlib = i need all the candle data
if id == binance
my fees == arethis... =
etc etc ect
…On Fri, 14 Dec 2018 at 18:55, Matthias ***@***.***> wrote:
@mishaker <https://github.com/mishaker> as mentioned before, i'm not tied
to our logic to calculate precisions and would prefer to relie on ccxt
handling that.
and yes - also the other info (min-notational, ...) will absolutely need
to be considered. ccxt does have that available easily and unified - in
fetch_markets() (i think)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw33lctKE5NQ8BB0YNr9XCfCrb8ovks5u4_QzgaJpZM4Y5Z2W>
.
|
|
For the record: recent bombardments of price filter error was due to a sudden change in Binance API which is now handled in the following: ccxt/ccxt@dc3bd40 |
|
That's not recent, it's Ccxt code being rubbish - I had those in my filters
class couple days into Dec.
Here is the part of the API i emailed FT start of the week, explicitly
saying to check the price and qty in the info{} message returned.
Binance tell the filter is failed on, CCXT hides it.
Symbol filters
<https://github.com/binance-exchange/binance-official-api-docs/blob/master/rest-api.md#price_filter>
PRICE_FILTER
The PRICE_FILTER defines the price rules for a symbol. There are 3 parts:
- minPrice defines the minimum price/stopPrice allowed; disabled on
minPrice == 0.
- maxPrice defines the maximum price/stopPrice allowed; disabled on
maxPrice == 0.
- tickSize defines the intervals that a price/stopPrice can be
increased/decreased by; disabled on tickSize == 0.
…On Mon, Dec 17, 2018, 9:53 PM Misagh ***@***.*** wrote:
For the record: recent bombardments of price filter error was due to a
sudden change in Binance API which is now handled in the following:
***@***.***
<ccxt/ccxt@dc3bd40>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw5oKf6NvCSscoBjj1ActHO_i-_z9ks5u5_YggaJpZM4Y5Z2W>
.
|
|
The same issue here It looks like a floating bug. Sometimes selling works fine, sometimes doesn't. Bad one: |
|
The bad thing here is not wrong rounding or whatever, but fact that freqtrade reports nothing to user about the issue. Missed stoploss is just silently ignoring, and user happily losing money without any notice through RPC. |
|
It's not a stop loss if it's not on the exchange, it's a sell order.
And best of hope code is working, price move is spotted in good time,
internet connection is up, exchange is not under ddos, there is some
liquidity remaining on the price step after all the exchange stop losses
are settled, the PC the bot is running on has not crashed
…On Fri, Dec 21, 2018, 3:37 PM asheetov ***@***.*** wrote:
The bad thing here is not wrong rounding or whatever, but fact that
freqtrade report nothing to user about the issue. Missed stoploss is just
silently ignoring, and user happily losing money without any notice through
RPC.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw-61fKEql_q6eV0kBIX42BYggRdfks5u7OQHgaJpZM4Y5Z2W>
.
|
|
@asheetov thanks for reporting. my take is that you are using trailing stoploss and when the bot tries to sell in bear market it is failing due to the slippage. My advice is turn the stoploss on exchange "True" and also put sell to "market". As for your comment on bot should inform user, I cannot agree more. stoploss and trailing stoploss will undergo following refactoring:
but I am afraid it won't be before new year. |
|
I don't think the issue is related to slippage, because according to the logs, bot tried to sell the same (wrong) amount of currency several times at different prices. So it's not price-related issue, but amount related. And, unfortunately, market order type doesn't help here #1428 |
|
@asheetov what is your ccxt version? |
|
1.17.363 |
|
@asheetov please update your CCXT version. as you are behind the filter correction version. |
|
I'm using BNB to pay the fees, not the base currency. |
|
market order is fixed now as per #1440 |
|
I believe I am having this same issue. I had to manually cancel an order(I'll open another issue as to why) On binance. Now it doesn't update my balance from binance and keeps spamming the error that I do not have enough funds. WARNING - Unable to sell trade: Insufficient funds to create limit sell order on market PHX/BTC.Tried to sell amount 8032.0 at rate 2.48e-06 (total 0.01991936).Message: binance {"code":-2010,"msg":"Account has insufficient balance for requested action."} |
|
if you manually cancelled the order on the exchange you need to let the bot know and close / remove the trade in the database. |
|
Got it I did that but figured since there isn't a built in function to do
so this want intended behavior.
Any ideas on why it would but and sell so many times in a row for a loss?
- Sent from my iPhone
…On Wed, Jan 30, 2019, 10:40 AM Matthias ***@***.*** wrote:
if you manually cancelled the order on the exchange you need to let the
bot know and close / remove the trade in the database.
The documentation has a cheatsheet here
<https://www.freqtrade.io/en/latest/sql_cheatsheet/> on how to do that.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFGT_5o-08QV3M6J0o23JY_5C7rU4JMmks5vIbzogaJpZM4Y5Z2W>
.
|
|
bolt assumption without proof: I had this happen a few times with HOT - (which is since then on my blacklist ...) |
|
I blacklisted the coin and turned on the experimental feature to only sell
for a profit.
Is there additional logging I can enable to possibly see why this occurred.
It was a pretty Stark difference in price but I suppose it could be a
rounding error.
- Sent from my iPhone
…On Wed, Jan 30, 2019, 1:23 PM Matthias ***@***.*** wrote:
bolt assumption without proof:
a) bad signals
b) rounding errors due to min-amount from the exchange (rounding up on buy
- and because this is a very cheap coin that is > stoploss% - so it buys at
that level and sells almost immediately (i assume in the next cycle)
I had this happen a few times with HOT - (which is since then on my
blacklist ...)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFGT_54jw8_b-JKGjs5ObOY9JiukL0q1ks5vIeMjgaJpZM4Y5Z2W>
.
|
|
I just don't want to wake up to thousands of trades and no money left.
- Sent from my iPhone
…On Wed, Jan 30, 2019, 1:34 PM mike wheat ***@***.*** wrote:
I blacklisted the coin and turned on the experimental feature to only sell
for a profit.
Is there additional logging I can enable to possibly see why this
occurred. It was a pretty Stark difference in price but I suppose it could
be a rounding error.
- Sent from my iPhone
On Wed, Jan 30, 2019, 1:23 PM Matthias ***@***.*** wrote:
> bolt assumption without proof:
> a) bad signals
> b) rounding errors due to min-amount from the exchange (rounding up on
> buy - and because this is a very cheap coin that is > stoploss% - so it
> buys at that level and sells almost immediately (i assume in the next cycle)
>
> I had this happen a few times with HOT - (which is since then on my
> blacklist ...)
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AFGT_54jw8_b-JKGjs5ObOY9JiukL0q1ks5vIeMjgaJpZM4Y5Z2W>
> .
>
|
|
This is how the exception is returned.
…On Sat, 30 Mar 2019 at 21:46, Danny ***@***.***> wrote:
These can be common:
- Insufficient balance when the sell would leave no funds for fees. Its
returned as an Exception, so loop on this and reset at amount * 0.997
- Cannot set, as would immediately be triggered. When there is a large
spread between ASK and BID, or price has fallen. Again us the same
exception to walk down price in 0.2% decrements until have a stop.
I tackled the same in the below structure, not had a stop miss since.
A Stop that cover 99.7% the position and/or a fraction % off the ideal is
far better than no stop
```
For ... prices / amounts :
log my_try price / amount ..
Try
_ret =.....order stuff
log got it
Break
Except e
log e - get the detail
Continue
Else:
log warning all prices amounts failed
Return None
my_order = _ret. # success do stuff
```
On Sat, 30 Mar 2019 at 18:37, Matthias ***@***.***> wrote:
> @konqueror1 <https://github.com/konqueror1>
> the logs indicate that it's not a sell-command, but a stoploss-order.
>
> This could be a problem in the first iteration (if the trade is not
> filled completely yet ...).
> Did the bot succeed to place the stoplooss-order a little later (a few
> iterations / seconds)?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AhCkwyV-FjvxZ5OZNzsUKIMWk1-ZP9XIks5vb68BgaJpZM4Y5Z2W>
> .
>
|
|
@xmatthias |
|
I didn’t follow this thread in details but I am wondering why we don’t just
update the amount in DB right after buy is executed?
…On Sat 30 Mar 2019 at 23:16, konqueror1 ***@***.***> wrote:
@xmatthias <https://github.com/xmatthias>
the bot succeeded when I corrected the amount in the DB. The available
amount in DB was wrong from the beginning.
I don't know the logic for getting info like amounts, fees etc but I
believe it does not cover all the cases. I will try to debug what
get_real_amount actually does.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5VLSr9MFS_e8enkDP3EUxTBjsTJenDks5vb-JagaJpZM4Y5Z2W>
.
|
|
Just a suggestion of different approach for selling algorithm, which works perfect for me in Zenbot (honestly I give up with freqtrade after losing money because of this issue). Don't make the bot to calculate "exactly right" amount of selling position considering fees, rounding and whatever else. Just sell "all of them". For flexibility you can add the new config option like "sell percent of open position" and place sell orders according that percent of funds in account. |
|
its fees, place the stop-limit order it in a loop that continues on
exception to handle this. 1
1st - try to sell 100% - if user has BNB and is fee paying with BNB this
will work.
2nd - try to sell 99.7%the position amount - if user has no BNB or is not
paying with BNB, the amount it their full balance, this will work.
This is true to stops and sells.
Next, in stops alone:
User will also hit stop would trigger immediately exception on large spot
spread or price is falling fast.
Use the same loop to lower the stop-trigger and limit price here too.
Its a mistake to think the bot can calculate this upfront always, the
market is dynamic and does not care.
The exceptions should be caught and handled appropriately - its easier to
ask for forgiveness in the code paradigm
Its important a position is protected with stop and a bad position exits
than leaving money with no stop at all.
Risk capital is 100% without a stop.
Any dust from selling just shy of full amount can be swept up later by
user.
…On Sun, 31 Mar 2019 at 06:29, asheetov ***@***.***> wrote:
Just a suggestion of different approach for selling algorithm, which works
perfect for me in Zenbot (honestly I give up with freqtrade after losing
money because of this issue).
Don't make the bot to calculate "exactly right" amount of selling position
considering fees, rounding and whatever else. Just sell "all of them". For
flexibility you can add the new config option like "sell percent of open
position" and place sell orders according that percent of funds in account.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw6wYD8oX-zuc3wsg5Z0gAusGUD6rks5vcFXZgaJpZM4Y5Z2W>
.
|
xmatthias
added a commit
that referenced
this issue
Mar 31, 2019
should fix bugs observed in #1371 connected to stoploss
|
it's not that we try to calculate the Amount, we have code in place which detects the real bought amount based on the buy order id (see my previous comment). However, due to a bug, that code was never executed for buys which filled immediately (see #1720 for details), which caused the relevant code to be never executed during a buy - so the trade-amount was never updated. I did multiple buys/sells with the above PR, all with BNB disabled (and the amount did update to the correct value). Side note: Retrying with lower amounts until it works is a brute-force method, without really caring/thinking about the root problem. |
|
The root of the problem is returned exceptions are not being handled, but
ignored. The impact of ignoring exceptions being sent is users real money
is left at risk for no reason.
The use case for triggering the scenario is.
I have 10LTC total and my stop is to sell 10LTC or my sell is to sell
10LTC. My fees are to be paid in LTC. I can't sell 10 as I need to pay the
fee too. Binance returns a insufficient funds error.
Lowering the amount by .3% covers the fee, when the exception is returned
protects the capital.
The dust remaining can be swept up after.
Really when the exception returned states insignificant funds, lowering the
amount is the correct and obvious solution. It's a million times better
than not protecting money. It's not brute Force either, because it'sa
targetted handling, which works.
…On Sun, Mar 31, 2019, 8:46 PM Matthias ***@***.***> wrote:
it's not that we try to calculate the Amount, we have code in place which
detects the real bought amount based on the buy order id (see my previous
comment).
However, due to a bug, that code was never executed for buys which filled
immediately (see #1720 <#1720>
for details), which caused the relevant code to be never executed during a
buy - so the trade-amount was never updated.
I did multiple buys/sells with the above PR, all with BNB disabled (and
the amount did update to the correct value).
Side note: Retrying with lower amounts until it works is a brute-force
method, without really caring about the root problem.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw1vpiOMLNMK8VgYZRzz1oCuemjgqks5vcPSIgaJpZM4Y5Z2W>
.
|
|
Another factor to be aware of is to never set a buy for less than
min_notional plus your stop.
If min notional is 5 and you buy 5 you can't place a stop where by if the
limit price is met it only returns 4.8 , as example. Stop liquidation price
must also meet min notional.
…On Sun, Mar 31, 2019, 9:02 PM Danny ***@***.***> wrote:
The root of the problem is returned exceptions are not being handled, but
ignored. The impact of ignoring exceptions being sent is users real money
is left at risk for no reason.
The use case for triggering the scenario is.
I have 10LTC total and my stop is to sell 10LTC or my sell is to sell
10LTC. My fees are to be paid in LTC. I can't sell 10 as I need to pay the
fee too. Binance returns a insufficient funds error.
Lowering the amount by .3% covers the fee, when the exception is returned
protects the capital.
The dust remaining can be swept up after.
Really when the exception returned states insignificant funds, lowering
the amount is the correct and obvious solution. It's a million times better
than not protecting money. It's not brute Force either, because it'sa
targetted handling, which works.
On Sun, Mar 31, 2019, 8:46 PM Matthias ***@***.***> wrote:
> it's not that we try to calculate the Amount, we have code in place which
> detects the real bought amount based on the buy order id (see my previous
> comment).
>
> However, due to a bug, that code was never executed for buys which filled
> immediately (see #1720 <#1720>
> for details), which caused the relevant code to be never executed during a
> buy - so the trade-amount was never updated.
>
> I did multiple buys/sells with the above PR, all with BNB disabled (and
> the amount did update to the correct value).
>
> Side note: Retrying with lower amounts until it works is a brute-force
> method, without really caring about the root problem.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AhCkw1vpiOMLNMK8VgYZRzz1oCuemjgqks5vcPSIgaJpZM4Y5Z2W>
> .
>
|
|
we're not ignoring the exception, but stupidly recreating the order with another amount IS NOT THE SOLUTION. Investigating the problem, finding out WHY the amounts don't match, that is the challange. side note: you can edit comments, no need to create multiple comments within minutes. |
|
I've explained exactly what the scenario is.
And at some point it may be hit. Regardless your opinion of school
girls??? the exchange is reality, and it it says no there are insufficient
funds in position not protected.
If you want to check all balances first, be totally certain nothing else
can possibly occur in parallel to upset that, make a targeted stop either
for 100% or 99.7% .. its a way.
It will be slower, take more calls, still leave the possibility of the
exception occuring. Needing to be handled.
…On Sun, Mar 31, 2019, 9:12 PM Matthias ***@***.***> wrote:
we're not ignoring the exception, but stupidly recreating the order with
another amount *IS NOT THE SOLUTION*.
Investigating the problem, finding out WHY the amounts don't match, that
is the challange.
Stupidly retrying until it works is something a schoolgirl can do, i don't
need a bot for that.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw2mD_vP-SonU6xbcC4LW3QIOOip-ks5vcPp9gaJpZM4Y5Z2W>
.
|
|
… On Sun, Mar 31, 2019, 9:18 PM Danny ***@***.***> wrote:
I've explained exactly what the scenario is.
And at some point it may be hit. Regardless your opinion of school
girls??? the exchange is reality, and it it says no there are insufficient
funds in position not protected.
If you want to check all balances first, be totally certain nothing else
can possibly occur in parallel to upset that, make a targeted stop either
for 100% or 99.7% .. its a way.
It will be slower, take more calls, still leave the possibility of the
exception occuring. Needing to be handled.
On Sun, Mar 31, 2019, 9:12 PM Matthias ***@***.***> wrote:
> we're not ignoring the exception, but stupidly recreating the order with
> another amount *IS NOT THE SOLUTION*.
>
> Investigating the problem, finding out WHY the amounts don't match, that
> is the challange.
> Stupidly retrying until it works is something a schoolgirl can do, i
> don't need a bot for that.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AhCkw2mD_vP-SonU6xbcC4LW3QIOOip-ks5vcPp9gaJpZM4Y5Z2W>
> .
>
|
|
Here is an example of the error being handled.
Reduced from 186.5 100% amount, as no money for fees, placed at 185.9
Time took was a ms, then the position was protected.
Any solution that leaves the position unprotected or unprotected for longer
isn't better
Its a solution, it's a benchmark - happy for it to be beaten.
…On Sun, 31 Mar 2019 at 18:22, Danny ***@***.***> wrote:
https://en.m.wikipedia.org/wiki/Ada_Lovelace
On Sun, Mar 31, 2019, 9:18 PM Danny ***@***.***> wrote:
> I've explained exactly what the scenario is.
>
> And at some point it may be hit. Regardless your opinion of school
> girls??? the exchange is reality, and it it says no there are insufficient
> funds in position not protected.
>
> If you want to check all balances first, be totally certain nothing else
> can possibly occur in parallel to upset that, make a targeted stop either
> for 100% or 99.7% .. its a way.
> It will be slower, take more calls, still leave the possibility of the
> exception occuring. Needing to be handled.
>
>
> On Sun, Mar 31, 2019, 9:12 PM Matthias ***@***.***> wrote:
>
>> we're not ignoring the exception, but stupidly recreating the order with
>> another amount *IS NOT THE SOLUTION*.
>>
>> Investigating the problem, finding out WHY the amounts don't match, that
>> is the challange.
>> Stupidly retrying until it works is something a schoolgirl can do, i
>> don't need a bot for that.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#1371 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AhCkw2mD_vP-SonU6xbcC4LW3QIOOip-ks5vcPp9gaJpZM4Y5Z2W>
>> .
>>
>
|
This is simply a misdiagnosis. {
"symbol": "BTCUSDT",
"orderId": 28,
"clientOrderId": "6gCrw2kRUAF9CvJDGP16IP",
"transactTime": 1507725176595,
"price": "1.00000000",
"origQty": "10.00000000",
"executedQty": "10.00000000",
"cummulativeQuoteQty": "10.00000000",
"status": "FILLED",
"timeInForce": "GTC",
"type": "MARKET",
"side": "SELL",
"fills": [
{
"price": "4000.00000000",
"qty": "1.00000000",
"commission": "4.00000000",
"commissionAsset": "USDT"
},
{
"price": "3999.00000000",
"qty": "5.00000000",
"commission": "19.99500000",
"commissionAsset": "USDT"
},
{
"price": "3998.00000000",
"qty": "2.00000000",
"commission": "7.99600000",
"commissionAsset": "USDT"
},
{
"price": "3997.00000000",
"qty": "1.00000000",
"commission": "3.99700000",
"commissionAsset": "USDT"
},
{
"price": "3995.00000000",
"qty": "1.00000000",
"commission": "3.99500000",
"commissionAsset": "USDT"
}
]
}Note the origQty, executedQty (10 BTC) and the sum of all trades (1 +5 +2 +1 +1). if trade.pair.startswith(order['fee']['currency']): # <-- checks if the fee currency is the base currency
new_amount = order_amount - order['fee']['cost']
logger.info("Applying fee on amount for %s (from %s to %s) from Order",
trade, order['amount'], new_amount)
return new_amountThis is what was skipped before @xmatthias found the bug today and corrected it.
Your comment is completely nonsense technically and condescending socially. start with the technical part: no exception is ignored or unhandled in this project, it is just a matter of reporting it and finding the right solution rather than coding a workaround which causes more problems. As for the social part: finally someone found the bug hanging since last November and corrected it. you didn't even take time to read it thoroughly before commenting "Me Myself and I ..." and unfortunately this is not the first time you show this attitude. |
|
@misagh
Take a moment to read the output you've posted.
And then what I posted and try again.
The condition is when it is the LAST 10, in your example.
if your account has ONLY 10 - in total not 1 cent more.
Try and set your sell or stop for all 10. And watch binance tell you in an
`exception` insufficient funds
which is no being handled - its not condescending - unlike the school girl
sexist comment .... to point out the exception is not being handled.
hopefully the school girl would have a stop on her funds and not handing
others money out to dry.
…On Sun, 31 Mar 2019 at 22:56, Misagh ***@***.***> wrote:
@creslinux <https://github.com/creslinux>
The use case for triggering the scenario is.
I have 10LTC total and my stop is to sell 10LTC or my sell is to sell
10LTC. My fees are to be paid in LTC. I can't sell 10 as I need to pay the
fee too. Binance returns a insufficient funds error.
This is simply a misdiagnosis.
Fees are not extracted beforehand from Binance. (i.e. the amount is not
rejected because it is more than the (amount - fees). from Binance docs, a
FULL response to a sell order:
{
"symbol": "BTCUSDT",
"orderId": 28,
"clientOrderId": "6gCrw2kRUAF9CvJDGP16IP",
"transactTime": 1507725176595,
"price": "1.00000000",
"origQty": "10.00000000",
"executedQty": "10.00000000",
"cummulativeQuoteQty": "10.00000000",
"status": "FILLED",
"timeInForce": "GTC",
"type": "MARKET",
"side": "SELL",
"fills": [
{
"price": "4000.00000000",
"qty": "1.00000000",
"commission": "4.00000000",
"commissionAsset": "USDT"
},
{
"price": "3999.00000000",
"qty": "5.00000000",
"commission": "19.99500000",
"commissionAsset": "USDT"
},
{
"price": "3998.00000000",
"qty": "2.00000000",
"commission": "7.99600000",
"commissionAsset": "USDT"
},
{
"price": "3997.00000000",
"qty": "1.00000000",
"commission": "3.99700000",
"commissionAsset": "USDT"
},
{
"price": "3995.00000000",
"qty": "1.00000000",
"commission": "3.99500000",
"commissionAsset": "USDT"
}
]
}
Note the origQty, executedQty (10 BTC) and the sum of all trades (1 +5 +2
+1 +1).
The safest and the most pertinent approach is to update the trade amount
immediately if the fee is paid by the base currency. coded here:
if trade.pair.startswith(order['fee']['currency']): # <-- checks if the fee currency is the base currency
new_amount = order_amount - order['fee']['cost']
logger.info("Applying fee on amount for %s (from %s to %s) from Order",
trade, order['amount'], new_amount)
return new_amount
This is what was skipped before @xmatthias <https://github.com/xmatthias>
found the bug today and corrected it.
The root of the problem is returned exceptions are not being handled, but
ignored. The impact of ignoring exceptions being sent is users real money
is left at risk for no reason.
Your comment is completely nonsense technically and condescending
socially. start with the technical part: no exception is ignored or
unhandled in this project, it is just a matter of reporting it and finding
the right solution rather than coding a workaround which causes more
problems. As for the social part: finally someone found the bug hanging
since last November and corrected it. you didn't even take time to read it
thoroughly before commenting "Me Myself and I ..." and unfortunately this
is not the first time you show this attitude.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw5KkFfkvCJU7flufQr9QyT-36dgXks5vcT0qgaJpZM4Y5Z2W>
.
|
|
The word you're missing from my statement is "total", can replace this with
"only" if it makes it clearer.
Use case in more detail. This should not be that hard to understand.
"account" in TOTAL (or ONLY) has $10 value
** you can have more but if its tied into other currencies/positions this
is the same, it cannot be spent on fees for this position.
Try and spend or set a stop for $10.
…On Sun, 31 Mar 2019 at 23:55, Danny ***@***.***> wrote:
@misagh
Take a moment to read the output you've posted.
And then what I posted and try again.
The condition is when it is the LAST 10, in your example.
if your account has ONLY 10 - in total not 1 cent more.
Try and set your sell or stop for all 10. And watch binance tell you in an
`exception` insufficient funds
which is no being handled - its not condescending - unlike the school
girl sexist comment .... to point out the exception is not being handled.
hopefully the school girl would have a stop on her funds and not handing
others money out to dry.
On Sun, 31 Mar 2019 at 22:56, Misagh ***@***.***> wrote:
> @creslinux <https://github.com/creslinux>
>
> The use case for triggering the scenario is.
> I have 10LTC total and my stop is to sell 10LTC or my sell is to sell
> 10LTC. My fees are to be paid in LTC. I can't sell 10 as I need to pay the
> fee too. Binance returns a insufficient funds error.
>
> This is simply a misdiagnosis.
> Fees are not extracted beforehand from Binance. (i.e. the amount is not
> rejected because it is more than the (amount - fees). from Binance docs, a
> FULL response to a sell order:
>
> {
> "symbol": "BTCUSDT",
> "orderId": 28,
> "clientOrderId": "6gCrw2kRUAF9CvJDGP16IP",
> "transactTime": 1507725176595,
> "price": "1.00000000",
> "origQty": "10.00000000",
> "executedQty": "10.00000000",
> "cummulativeQuoteQty": "10.00000000",
> "status": "FILLED",
> "timeInForce": "GTC",
> "type": "MARKET",
> "side": "SELL",
> "fills": [
> {
> "price": "4000.00000000",
> "qty": "1.00000000",
> "commission": "4.00000000",
> "commissionAsset": "USDT"
> },
> {
> "price": "3999.00000000",
> "qty": "5.00000000",
> "commission": "19.99500000",
> "commissionAsset": "USDT"
> },
> {
> "price": "3998.00000000",
> "qty": "2.00000000",
> "commission": "7.99600000",
> "commissionAsset": "USDT"
> },
> {
> "price": "3997.00000000",
> "qty": "1.00000000",
> "commission": "3.99700000",
> "commissionAsset": "USDT"
> },
> {
> "price": "3995.00000000",
> "qty": "1.00000000",
> "commission": "3.99500000",
> "commissionAsset": "USDT"
> }
> ]
> }
>
> Note the origQty, executedQty (10 BTC) and the sum of all trades (1 +5 +2
> +1 +1).
> The safest and the most pertinent approach is to update the trade amount
> immediately if the fee is paid by the base currency. coded here:
>
> if trade.pair.startswith(order['fee']['currency']): # <-- checks if the fee currency is the base currency
> new_amount = order_amount - order['fee']['cost']
> logger.info("Applying fee on amount for %s (from %s to %s) from Order",
> trade, order['amount'], new_amount)
> return new_amount
>
> This is what was skipped before @xmatthias <https://github.com/xmatthias>
> found the bug today and corrected it.
>
> The root of the problem is returned exceptions are not being handled, but
> ignored. The impact of ignoring exceptions being sent is users real money
> is left at risk for no reason.
>
> Your comment is completely nonsense technically and condescending
> socially. start with the technical part: no exception is ignored or
> unhandled in this project, it is just a matter of reporting it and finding
> the right solution rather than coding a workaround which causes more
> problems. As for the social part: finally someone found the bug hanging
> since last November and corrected it. you didn't even take time to read it
> thoroughly before commenting "Me Myself and I ..." and unfortunately this
> is not the first time you show this attitude.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1371 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AhCkw5KkFfkvCJU7flufQr9QyT-36dgXks5vcT0qgaJpZM4Y5Z2W>
> .
>
|
|
The solution being put forward by xmats is wrong btw - if what @misagh
posted inline was it?
Its moved the problem from handling error state bad to handling good state
poorly.
Use-case 1
If i have BNB or USDT free to pay the fees when I exit 10LTC/USDT(as
example) i want to exit all 10 LTC. Not exit 10LTC - fees.
This would leave me with LTC dust. Because the fees would be paid by the
USDT or BNB free in my account already.
Use-case 2
I have not BNB or USDT to pay the fees when i exit 10LTC/USDT(as example) i
want to exit all 10LTC.
Now the amount is reduced, if i read it correctly, minus fees. This is
probably good behaviour
The problem is by Always subtracting fees from sell amount, is when the
user HAS free to pay fees this is not desired, it leaves a fees worth of
base asset behind in every trade. Dust.
…On Mon, 1 Apr 2019 at 00:08, Danny ***@***.***> wrote:
The word you're missing from my statement is "total", can replace this
with "only" if it makes it clearer.
Use case in more detail. This should not be that hard to understand.
"account" in TOTAL (or ONLY) has $10 value
** you can have more but if its tied into other currencies/positions this
is the same, it cannot be spent on fees for this position.
Try and spend or set a stop for $10.
On Sun, 31 Mar 2019 at 23:55, Danny ***@***.***> wrote:
> @misagh
> Take a moment to read the output you've posted.
> And then what I posted and try again.
>
> The condition is when it is the LAST 10, in your example.
> if your account has ONLY 10 - in total not 1 cent more.
> Try and set your sell or stop for all 10. And watch binance tell you in
> an `exception` insufficient funds
>
> which is no being handled - its not condescending - unlike the school
> girl sexist comment .... to point out the exception is not being handled.
> hopefully the school girl would have a stop on her funds and not handing
> others money out to dry.
>
> On Sun, 31 Mar 2019 at 22:56, Misagh ***@***.***> wrote:
>
>> @creslinux <https://github.com/creslinux>
>>
>> The use case for triggering the scenario is.
>> I have 10LTC total and my stop is to sell 10LTC or my sell is to sell
>> 10LTC. My fees are to be paid in LTC. I can't sell 10 as I need to pay
>> the
>> fee too. Binance returns a insufficient funds error.
>>
>> This is simply a misdiagnosis.
>> Fees are not extracted beforehand from Binance. (i.e. the amount is not
>> rejected because it is more than the (amount - fees). from Binance docs, a
>> FULL response to a sell order:
>>
>> {
>> "symbol": "BTCUSDT",
>> "orderId": 28,
>> "clientOrderId": "6gCrw2kRUAF9CvJDGP16IP",
>> "transactTime": 1507725176595,
>> "price": "1.00000000",
>> "origQty": "10.00000000",
>> "executedQty": "10.00000000",
>> "cummulativeQuoteQty": "10.00000000",
>> "status": "FILLED",
>> "timeInForce": "GTC",
>> "type": "MARKET",
>> "side": "SELL",
>> "fills": [
>> {
>> "price": "4000.00000000",
>> "qty": "1.00000000",
>> "commission": "4.00000000",
>> "commissionAsset": "USDT"
>> },
>> {
>> "price": "3999.00000000",
>> "qty": "5.00000000",
>> "commission": "19.99500000",
>> "commissionAsset": "USDT"
>> },
>> {
>> "price": "3998.00000000",
>> "qty": "2.00000000",
>> "commission": "7.99600000",
>> "commissionAsset": "USDT"
>> },
>> {
>> "price": "3997.00000000",
>> "qty": "1.00000000",
>> "commission": "3.99700000",
>> "commissionAsset": "USDT"
>> },
>> {
>> "price": "3995.00000000",
>> "qty": "1.00000000",
>> "commission": "3.99500000",
>> "commissionAsset": "USDT"
>> }
>> ]
>> }
>>
>> Note the origQty, executedQty (10 BTC) and the sum of all trades (1 +5
>> +2 +1 +1).
>> The safest and the most pertinent approach is to update the trade amount
>> immediately if the fee is paid by the base currency. coded here:
>>
>> if trade.pair.startswith(order['fee']['currency']): # <-- checks if the fee currency is the base currency
>> new_amount = order_amount - order['fee']['cost']
>> logger.info("Applying fee on amount for %s (from %s to %s) from Order",
>> trade, order['amount'], new_amount)
>> return new_amount
>>
>> This is what was skipped before @xmatthias
>> <https://github.com/xmatthias> found the bug today and corrected it.
>>
>> The root of the problem is returned exceptions are not being handled, but
>> ignored. The impact of ignoring exceptions being sent is users real money
>> is left at risk for no reason.
>>
>> Your comment is completely nonsense technically and condescending
>> socially. start with the technical part: no exception is ignored or
>> unhandled in this project, it is just a matter of reporting it and finding
>> the right solution rather than coding a workaround which causes more
>> problems. As for the social part: finally someone found the bug hanging
>> since last November and corrected it. you didn't even take time to read it
>> thoroughly before commenting "Me Myself and I ..." and unfortunately this
>> is not the first time you show this attitude.
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#1371 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AhCkw5KkFfkvCJU7flufQr9QyT-36dgXks5vcT0qgaJpZM4Y5Z2W>
>> .
>>
>
|
You are right @creslinux, edited that comment now to say "schoolgirl/schoolboy". Wasn't intendet to be sexist, sorry. @creslinux again, please edit your comments instead of posting 3 comments in quick succession if you need to make corrections or additions right after posting. This creates 3 alerts for everyone subscribed to this issue, where on ewould be enough.
Please take the time to understand the solution before you post misleading comments. The message/ return value from @mishaker is not what is used for this calculation. The result of the "fetch_my_trades" is something like the following: Dict in case of BNB fees[{'info': {'symbol': 'MTLETH',
'id': 1234,
'orderId': 1234,
'price': '0.00527100',
'qty': '18.96000000',
'quoteQty': '0.09993816',
'commission': '0.00060196',
'commissionAsset': 'BNB',
'time': 1554032217497,
'isBuyer': True,
'isMaker': False,
'isBestMatch': True},
'timestamp': 1554032217497,
'datetime': '2019-03-31T11:36:57.497Z',
'symbol': 'MTL/ETH',
'id': '1234',
'order': '1234',
'type': None,
'takerOrMaker': 'taker',
'side': 'buy',
'price': 0.005271,
'amount': 18.96,
'cost': 0.09993816,
'fee': {'cost': 0.00060196, 'currency': 'BNB'}}]dict in case of non-BNB fees:[{'info': {'symbol': 'MTLETH',
'id': 5543,
'orderId': 5555,
'price': '0.00428600',
'qty': '23.33000000',
'quoteQty': '0.09999238',
'commission': '0.02333000',
'commissionAsset': 'MTL',
'time': 1554053985003,
'isBuyer': True,
'isMaker': False,
'isBestMatch': True},
'timestamp': 1554053985003,
'datetime': '2019-03-31T17:39:45.003Z',
'symbol': 'MTL/ETH',
'id': '5543',
'order': '5555',
'type': None,
'takerOrMaker': 'taker',
'side': 'buy',
'price': 0.004286,
'amount': 23.33,
'cost': 0.09999237999999999,
'fee': {'cost': 0.02333, 'currency': 'MTL'}},
]Note: There can be more than one trade per side, in which case the amount is aggregated - but there have not been in this case and for simplicity of .
The solution as explained above does not do that. |
|
This isn't going to fix the problem then.
Looking at fees for when bought into a position is not going help when
trying to sell 100% of a position when there is no other funds available to
pay the fee.
For absolute simplicity, if the account has only 1 balance. All other
wallets are zero.
10 abc/ETH
The fees are to be paid in abc's
Trying to set a stop for 10abc will fail with insufficient balance.
The error is not as simple as trying to sell more than is in the free
balance.
It is trying to sell all that is in the free balance and leave none to pay
the fees.
…On Mon, Apr 1, 2019, 8:01 AM Matthias ***@***.***> wrote:
unlike the school girl sexist comment
You are right @creslinux <https://github.com/creslinux>, edited that
comment now to say "schoolgirl/schoolboy". Wasn't intendet to be sexist,
sorry.
@creslinux <https://github.com/creslinux> again, *please edit your
comments instead of posting 3 comments in quick succession* if you need
to make corrections or additions right after posting. This creates 3 alerts
for everyone subscribed to this issue, where on ewould be enough.
It's fine to recomment on your own answer if that was more than a day ago.
he solution being put forward by xmats is wrong btw
Please take the time to understand the solution before you post misleading
comments.
My solution is not new, but was there and working before we added
different time_in_force methods, which introduced the bug causing this.
The solution gathers the trades connected to the buy-order, analyzes if
the fees have been payed in stake-currency or not (payed in BNB/USDT) - and
then adjusts the amount eventually.
The message/ return value from @mishaker <https://github.com/mishaker> is
not what is used for this calculation.
We use the "fees" element of order if it's there (hint: it's not for
binance) or get the trades for this order, and use the "fee" element in
this return value.
The result of the "fetch_my_trades" is something like the following:
It includes the "fees" dict, and if the currency is MTL - we subtract the
amount.
Dict in case of BNB fees
[{'info': {'symbol': 'MTLETH',
'id': 1234,
'orderId': 1234,
'price': '0.00527100',
'qty': '18.96000000',
'quoteQty': '0.09993816',
'commission': '0.00060196',
'commissionAsset': 'BNB',
'time': 1554032217497,
'isBuyer': True,
'isMaker': False,
'isBestMatch': True},
'timestamp': 1554032217497,
'datetime': '2019-03-31T11:36:57.497Z',
'symbol': 'MTL/ETH',
'id': '1234',
'order': '1234',
'type': None,
'takerOrMaker': 'taker',
'side': 'buy',
'price': 0.005271,
'amount': 18.96,
'cost': 0.09993816,
'fee': {'cost': 0.00060196, 'currency': 'BNB'}}]
dict in case of non-BNB fees:
[{'info': {'symbol': 'MTLETH',
'id': 5543,
'orderId': 5555,
'price': '0.00428600',
'qty': '23.33000000',
'quoteQty': '0.09999238',
'commission': '0.02333000',
'commissionAsset': 'MTL',
'time': 1554053985003,
'isBuyer': True,
'isMaker': False,
'isBestMatch': True},
'timestamp': 1554053985003,
'datetime': '2019-03-31T17:39:45.003Z',
'symbol': 'MTL/ETH',
'id': '5543',
'order': '5555',
'type': None,
'takerOrMaker': 'taker',
'side': 'buy',
'price': 0.004286,
'amount': 23.33,
'cost': 0.09999237999999999,
'fee': {'cost': 0.02333, 'currency': 'MTL'}},
]
Note: There can be more than one trade per side, in which case the amount
is aggregated - but there have not been in this case and for simplicity of .
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw5Qcm66M9k6KweIPGTPTzNOQP0Vlks5vcZKegaJpZM4Y5Z2W>
.
|
|
From your answer it's not 100% clear, but i assume you only have 10abc in your account. Your sell-order for 10abc will succeed, since you are paying fees in the amount you receive - which is ETH in your example. So you'll not get 10abs's worth of ETH - but 10-abc's worth of ETH. For binance, fees are paid in the currency you're about to receive (or BNB). another calculation sample, hopefully clearerLet's assume i have BNB disabled for this post, and for simplicity, the rate between XRP and ETH is 1. If i buy 100 XRP, then i will receive 99.75 XRP, and have paid 0.25 XRP in feeds. When trying to sell - or creating a stoploss order - I will place my order with 99.75 XRP. I do not have to do this calculation myself and place the sell-order with 99.49, which is what you're suggesting, but the exchange subtracts this from the currency i am about to receive (both ways, when buying or selling). Note: this is a fictional example, XRP ETH rate is not 1 - but it simplifies the calculation. |
|
Everything you're saying makes sense.
The challenge I have with this is the code im using does not track, tot up,
balances, ergo it cant be wrong.
We receive the balances from Binance, after each trade, a full balance is
received this overwrites total/free/used it full - no adding / subtracting
is involved.
As an aside the update always includes all other asset balances too,
binance send the full set of wallets in 1 payload.
Selling or Stop on 100% `free` of an asset works almost every time, 29
trades in 30 as example - apart from when there is no other funds for
fees, if it's the last of account balance being committed, then i get the
error. Is it True that fees are Always taken from received asset?
…On Mon, Apr 1, 2019, 11:05 AM Matthias ***@***.***> wrote:
From your answer it's not 100% clear, but i assume you only have 10abc in
your account.
Your sell-order for 10abc will succeed, since you are paying fees in the
amount you receive - which is ETH in your example. So you'll not get
10abs's worth of ETH - but 10-abc's worth of ETH.
For binance, fees are paid in the currency you're about to receive (or
BNB).
another calculation sample, hopefully clearer
Let's assume i have BNB disabled for this post, and for simplicity, the
rate between XRP and ETH is 1.
If i buy 100 XRP, then i will receive 99.75 XRP, and have paid 0.25 XRP in
feeds.
The bot detects this - and sets the amount of XRP i have to 99.75.
When trying to sell - or creating a stoploss order - I will place my order
with 99.75 XRP.
I will however not receive 99.75 ETH, but 99.49 ETH, since fees are
subtracted by from this.
I do not have to do this calculation myself and place the sell-order with
99.49, which is what you're suggesting, but the exchange subtracts this
from the currency i am about to receive (both ways, when buying or selling).
Note: this is a fictional example, XRP ETH rate is not 1 - but it
simplifies the calculation.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkw-qnj86wSYxQYI60zxU6oAFD4pQNks5vcb3egaJpZM4Y5Z2W>
.
|
|
yep, that is what we are trying to explain here :) fees are always taken from received amount. your mistake was you thought you have to calculate the fee beforehand cause binance it reduces from your base amount on market price of base/BNB. as you can never be sure of this rate then you came to conclusion that a loop should be baked. your hypothesis was wrong. sell amount is always fixed, fees are reduced from received asset. |
|
Misagh
Thats missing a point - the error IS received and ONLY when its the last of
balance in a position.
I cannot be trying to sell more than my free - as binance tells me what it
is - i dont calculate /hold it as FT is.
I can posts literally a hundred examples as its all logged where there is
free other balance and 100% position stops work, are set
I can also post the same where the error is received when is the last of
balance.
…On Mon, 1 Apr 2019 at 09:32, Misagh ***@***.***> wrote:
yep, that is what we are trying to explain here :) fees are always taken
from received amount. your mistake was you thought you have to calculate
the fee beforehand cause binance it reduces from your base amount on market
price of base/BNB. as you can never be sure of this rate then you came to
conclusion that a loop should be baked. your hypothesis was wrong. sell
amount is always fixed, fees are reduced from received asset.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1371 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AhCkwwZPwjp8LXi58Ayf9OMN9oTvRNKJks5vcdI2gaJpZM4Y5Z2W>
.
|
|
I am going to close this issue as I am sure it is solved by #1720 |
|
Mmm, I'm not sure, I did not set FOK for time_in_force.. |
|
It's not an issue with FOK - but that this applied for every trade which was immediately closed, no matter if it's IOC, FOK, or GTC (the default). |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I was synced to HEAD yesterday (but I had the same issue some time ago).
I had an order that the bot couldn't sell because of insufficient fund. I think it's because either the bot did wrong calculation of the amount or the exchange is doing some funny stuff.
Logs when the order was fulfilled:
Logs when the bot was trying to sell:
The code that is throwing the error, any reason that instead of using the latest amount getting from exchange, we still choose to use the one saved when buying?
freqtrade/freqtrade/freqtradebot.py
Line 603 in 200484a
The text was updated successfully, but these errors were encountered: