Topic: 【BOT】 🌟 C.A.T. Cryptocurrency Automatic Trader 🌟 (New Price List 04/2021) - page 77. (Read 531503 times)

Hello Sampey :-)

there are a lot of "retrys" on the api calls for yobit. 
even if yobit itself say 200ms per api call. seems the .net address too busy. to handle this timings.

overall process c.a.t. the most calls with the 200ms setting
but i have tried a bit and have to say that with 1 call per second are np retry`s
and they steady increase with reduced time between the calls.
it is far away from 5 Calls per second. 


maybe it is too "simple "  but...   yobit has aditional the .io ending as backup. and so far as i can see
these server isnt affected by the heavy user load.    whenever i use the yobit.io address in the past
while yobit was lagging / slow.   it works for me fine.

could you try on your side if there is any better performance when you use yobit.io instead of yobit.net ? :-)

very interesting, ill give i'd a try !

50% mean 0.1 BTC right ? It's still a good amount for a small trader.

thank you Sampey :-)

https://pastebin.com/raw/VAMkWSiS

Bot warns the start of dumps? (in bitrex)

Possible dumps...

Hi, probably i won't be able to reply to pm/msg until Friday 1 September.
So don't worry if you don't receive any response from me 

Is trial version available?

Hi C.A.T. users (and potential new users).
I'll be away from 29/08 to 01/08  so if you need to buy something (a core license or an api) pls pm me today.

50% Discount is still available 

Hi guys

CAT sold my ETH @ 279 EUR this morning, so I missed the top (285 EUR).
Tried to hop an the train @ 281 EUR again but this went nowhere so far.

How do you handle such situations using CAT (if at all)?

I've already asked Sampey for a trailing stop feature, which they are thinking about.


Thanks.

@leetrung74 thank you so much.
i've checked what you post and i think that CAT won't be affected......
but for sure, the day they will switch something i'll be available to perform instant fix over the bitfinex api

Email form Bitfinex:
Bitfinex is growing faster than ever, and we are pleased that our platform, trading engine, and APIs have remained reliable and performant during these exciting days.
However, in order to continue to be able to accommodate current demand and future scaling, the Bitfinex REST and WebSocket APIs will be upgraded on Thursday, August 31st.
You are receiving this email because it appears you might be a Bitfinex API user and we wish to alert our API users about these changes in particular, as the changes may affect automated trading applications using the APIs.

In order to continue to be able to handle spikes in platform load, we need to make adjustments to how we return historical snapshot messages when authenticating to the WebSocket APIs. Currently, the snapshots hos, hts, hfts, hfos, hfls, and hfcs are returned in the WebSocket feed after authenticating. As of August 31st, these snapshots will no longer be returned via the WebSocket feed (both V1 and V2) after August 31 and equivalent REST endpoints are available as replacements. All update messages will remain unchanged.

If your API application relies on these historical snapshots, these changes may affect your application. Please take the time to review the following and make sure to properly update your code if needed.

CHANGES EFFECTIVE IMMEDIATELY

These changes are preparations for the changes that will be made on August 31.

New restV1: /v1/orders/hist (limited to last 3 days and last 1000 results)
restV1 Authenticated historical orders query (can be called only once per minute)
https://docs.bitfinex.com/v1/reference#rest-auth-orders-history
New restV1: /v1/offers/hist  (limited to last 3 days and last 1000 results)
restV1 Authenticated historical margin funding offers  (can be called only once per minute)
https://docs.bitfinex.com/v1/reference#rest-auth-offers-hist
New restV1: /v1/mytrades_funding
restV1 Authenticated historical margin funding trades
https://docs.bitfinex.com/v1/reference#rest-auth-mytrades-funding
New restV2: /v2/platform/status
Status of the platform

• Maintenance mode: trading engine pause / resync (after event 20060 is triggered)
[1] Active: normal operations (after event 20061 is triggered)

https://docs.bitfinex.com/v2/reference#rest-public-platform-status
RestV2 ERR_MAINT will be returned by all API endpoints during the maintenance period.
https://docs.bitfinex.com/v2/docs/rest-general#section-maintenance
New restV2: /v2/auth/r/funding/credits
Active funding credits (funds used in positions)
https://docs.bitfinex.com/v2/reference#rest-auth-funding-credits
new restV2: /v2/auth/r/funding/credits/hist
Inactive funding credits (funds used in positions)
https://docs.bitfinex.com/v2/reference#rest-auth-funding-credits-hist
New restV2: /v2/auth/r/funding/loans
Active funding loans
https://docs.bitfinex.com/v2/reference#rest-auth-funding-loans
new restV2: /v2/auth/r/funding/loans/hist
Inactive funding loans
https://docs.bitfinex.com/v2/reference#rest-auth-funding-loans-hist
New restV2: /v2/auth/r/funding/offers
Active funding offers
https://docs.bitfinex.com/v2/reference#rest-auth-funding-offers
new restV2: /v2/auth/r/funding/offers/hist (limited to 3 days)
Historical funding offers
https://docs.bitfinex.com/v2/reference#rest-auth-funding-offers-hist
new restV2: /v2/auth/r/funding/offers/SYMBOL/hist (limited to last 3 days)
Historical funding offers by symbol
https://docs.bitfinex.com/v2/reference#rest-auth-funding-offers-hist
New restV2: /v2/auth/r/funding/trades/hist (limited to last 15 days)
Historical funding trades
https://docs.bitfinex.com/v2/reference#rest-auth-funding-trades
New restV2: /v2/auth/r/funding/trades/SYMBOL/hist (limited to last 15 days)
Historical funding trades by symbol
https://docs.bitfinex.com/v2/reference#rest-auth-funding-trades
New restV2: /v2/auth/r/orders
Active orders
https://docs.bitfinex.com/v2/reference#rest-auth-orders
New restV2: /v2/auth/r/orders/hist (limited to 3 days)
Historical orders
https://docs.bitfinex.com/v2/reference#rest-auth-orders-hist
New restV2: /v2/auth/r/orders/SYMBOL/hist (limited to last 3 days)
Historical orders by symbol
https://docs.bitfinex.com/v2/reference#rest-auth-orders-hist
New restV2: /v2/auth/r/trades/hist (limited to 7 days)
Historical trades
https://docs.bitfinex.com/v2/reference#rest-auth-trades-hist
New restV2: /v2/auth/r/trades/SYMBOL/hist (limited to last 7 days)
Historical trades by symbol
https://docs.bitfinex.com/v2/reference#rest-auth-trades-hist
New restV2: /v2/auth/r/movements/hist (limited to last 90 days)
Historical movements (deposits/withdrawals) history
https://docs.bitfinex.com/v2/reference#rest-auth-info-funding
New restV2: /v2/auth/r/movements/CURRENCY/hist (limited to  90 days)
Historical movements (deposits/withdrawals) history by currency
https://docs.bitfinex.com/v2/reference#rest-auth-info-funding
WebSocket event code 20060 now means: Maintenance start
Pause trading is suggested until receiving 20061
Note that there is no change in the behaviour, this is just a more meaningful description
WebSocket event code 20061 now means: Maintenance end

CHANGES DEPLOYED on 2017-08-31

Some of these change can result in backward compatibility issues. Please make sure you will adjust your code to prevent unexpected behavior of your application.

Websocket books (v1 and v2): drop support for F2, F3 frequencies
Endpoint restV2: /v2/auth/r/offers renamed to: /v2/auth/r/funding/offers
Endpoint restV2: /v2/auth/r/funding renamed to: /v2/auth/r/info/funding
Endpoint restV2: /v2/auth/r/trading renamed to: /v2/auth/r/info/trading
Endpoint restV1 /v1/book “timestamp” field will now contain the timestamp at the moment of calculation of the book
The “timestamp” field is deprecated and will be removed in a future update
Endpoint restV1 /v1/lendbook “timestamp” field will now contain the timestamp at the moment of calculation of the book
The “timestamp” field is deprecated and will be removed in a future update
WebSocket v1 and v2 authenticated: historical snapshots  hos, hts removed:
https://docs.bitfinex.com/v2/reference#ws-auth-historical-orders
Only snapshot hos will be removed, while updates on, ou, oc  will flow as usual. Historic Order Snapshot can be retrieved via REST calls:
WS V1 users: use  /v1/orders/hist
WS V2 users: use  /v2/auth/r/orders/hist
or /v2/auth/r/orders/SYMBOL/hist (to filter on specific pair)
https://docs.bitfinex.com/v2/reference#ws-auth-trades
Only snapshot  hts will be removed, while updates  te, tu will flow as usual. Historic Trades Snapshot can be retrieved via REST calls:
WS V1 users: use restV1  /v1/mytrades
WS V2 users: use restV2  /v2/auth/r/trades//hist
or /v2/auth/r/trades/SYMBOL/hist (to filter on specific pair)
WebSocket v2 authenticated: historical snapshots  hfts, hfos, hfls, hfcs removed:
https://docs.bitfinex.com/v2/reference#ws-auth-historical-offers
Only snapshot  htos will be removed, while updates fon, fou, foc will flow as usual. Historic Funding Offers Snapshot can be retrieved via REST calls:
RestV2: /v2/auth/r/funding/offers/SYMBOL/hist
or /v2/auth/r/funding/offers/SYMBOL/hist (to filter on specific currency)
https://docs.bitfinex.com/v2/reference#ws-auth-historical-credits
Only snapshot hfcs will be removed, while updates fcn, fcu, fcc will flow as usual. Historic Credits Snapshot can be retrieved via REST calls:
RestV2: /v2/auth/r/funding/credits/hist
or /v2/auth/r/funding/credits/SYMBOL/hist  (to filter on specific currency)
https://docs.bitfinex.com/v2/reference#ws-auth-historical-loans
Only snapshot hfls will be removed, while updates fln, flu, flc will flow as usual. Historic Loans Snapshot can be retrieved via REST calls:
RestV2: /v2/auth/r/funding/hist
or /v2/auth/r/funding/loans/SYMBOL/hist  (to filter on specific currency)
https://docs.bitfinex.com/v2/reference#ws-auth-funding-trades
Only snapshot  hfts will be removed, while updates  fte, ftu will flow as usual. Historic Trades Snapshot can be retrieved via REST calls:
RestV2: /v2/auth/r/funding/trades/hist
or /v2/auth/r/funding/trades/SYMBOL/hist  (to filter on specific currency)
These changes will work to ensure optimal API performance, with minimal latency, to the benefit of our users.

If you have any questions or comments regarding this update, please contact support using the ticket form available in the help (?) menu on the website.

With Kind Regards,
bitfinex.com
[email protected]

Any Order have an OrderID
And Any Trade have a TradeId + OrderID

So i have the relationship between any order and his trades.

But let's say all orders first fill (the 1000). And you manage to sell only 600. How do you know which is sold?

when TradeHistory API is available, things are simple.
In that case you will have 3 trades

250 at 0.1220
300 at 0.1224
150 at 0.1229
300 at 0.1231

So from 1 PING you will have 4 PONG with 4 Different reference price.

Before buying I got a question regarding the profit calculation. It seems to me that most of the bots calculate this wrong. Lets say you want to buy 1000 xrp, the highest buy order is 0.1219, you set the buy order at 0.1220 and manage to buy 250 xrp then the price rises and you buy another 300 at 0.1224 it then rises again and you buy another 150 at 0.1229 and another 300 at 0.1231.

Now the weighted average is 0.122585 ((250×0.1220+300×0.1224+150×0.1229+300×0.1231) / (250+300+150+300) = 0.122585) of the buy orders. However I assume that CAT will sell once it sees that it bought something. Lets say the first 2 orders ( the 250 and 300) get sold at 0.1314 and the other 2 (150 and 300) get sold at 0.1311.

Can you tell me what CAT does to calculate these profits? I assume it will use the history api for this to check if it bought and sold?

you must check your SELL PONG last price. Not only sell.
It seems that your LAST PONG SELL -2,5% is 273.92859 but i need to take a look at the log. If you wants you can send me via pvt message.

My last sell price was 277.92316
So, the limit price (last sell - 2.5%) should be 270.975081.

my three last sell prices-> minus 2.5%
277.92316 -> 270.975081
277.8582  -> 270.911745
275.930   -> 269.032062


Where do I find the 270.975 from my last sell - 2.5%?
It does not match the calculated price and it does not match the comparing value.
Why is the calculated price changing?

2017-08-24 10:13:50| BSP : BUY Pool Lookup
2017-08-24 10:13:50| PPC(NO-BUY-PI) : Check Limit Rule PING LIMIT (Adequate:false) - Never BUY OVER Your Last PONG SELL Price - 2.5% VS Calculated Price 274.39895 Dynamic Comparing Value Is : 273.92859 Limit Applied! No price Adequation
2017-08-24 10:13:50| BSP : BUY Pool Must Wait, No Condition For New Ping Order Creation.


2017-08-24 10:17:18| BSP : BUY Pool Lookup
2017-08-24 10:17:18| PPC(NO-BUY-PI) : Check Limit Rule PING LIMIT (Adequate:false) - Never BUY OVER Your Last PONG SELL Price - 2.5% VS Calculated Price 274.18002 Dynamic Comparing Value Is : 273.92859 Limit Applied! No price Adequation
2017-08-24 10:17:18| BSP : BUY Pool Must Wait, No Condition For New Ping Order Creation.


2017-08-24 10:20:48| BSP : BUY Pool Lookup
2017-08-24 10:20:48| PPC(NO-BUY-PI) : Check Limit Rule PING LIMIT (Adequate:false) - Never BUY OVER Your Last PONG SELL Price - 2.5% VS Calculated Price 274.40001 Dynamic Comparing Value Is : 273.92859 Limit Applied! No price Adequation
2017-08-24 10:20:48| BSP : BUY Pool Must Wait, No Condition For New Ping Order Creation.



Thanks!

BSP = Buy sell Pool

PPC = Ping Pong Calculator

(NO-BUY-PI)   NEW ORDER BUY PING

Then there's a Check on Ping OVer Limit [Never BUY OVER Your Last PONG SELL Price - 1.5%] VS Calculated Price 270.67002

Your LAST PONG SELL PRICE - 1.5% IS the Dynamic Comparing Value : 274.58451
Calculated Price 270.67002 is the price calculated by the Ping Pong Calculator

So NEVER BUY OVER is OK, because 270 is < 274

So LIMIT IS OK (otherwise you will get LIMIT APPLIED!)




If you have a ping buy (and a trade occurs over that ping) you will have a ping sell of price that will make you have (when a trade will occur over that pong) a gain of X% (where X is you GAIN Parameter)

Each pong is related to a trader over the ping.

The price you're talking about is the REFERENCE PRICE (The ping trade price)

Somewhat confused - the pong is created from the ping. The pong as an associated reference price (the ping price) in which the buy/sell instruction was initiated.

Hi

Quick question re log messages.

2017-08-23 18:16:40| BSP : BUY Pool Lookup
2017-08-23 18:16:40| PPC(NO-BUY-PI) : Check Limit Rule PING LIMIT (Adequate:false) - Never BUY OVER Your Last PONG SELL Price - 1.5% VS Calculated Price 270.67002 Dynamic Comparing Value Is : 274.58451 Limit Is Ok.

How do I interpret this message?
[Never BUY OVER Your Last PONG SELL Price - 1.5%] VS Calculated Price 270.67002
Dynamic Comparing Value Is : 274.58451
Limit Is Ok <= what does that mean?

Is it current price is 274.58451 and buy price is 270.6002?

2017-08-23 18:49:54| BSP : BUY Pool Lookup
2017-08-23 18:49:54| PPC(NO-BUY-PI) : % Check Failed Reference Price : 272.00000 VS 272.00001 % Spread is -0.001 Must Be >= 0.000
2017-08-23 18:49:54| BSP : BUY Pool Must Wait, No Condition For New Ping Order Creation.

What does that mean?


1)
If you have a ping buy, from what pong sell is it created?
From what I understood, each ping is related to its own pong.
I would be nice to have an ID in above log message, which shows against which pong sell price the ping buy price is matched.


Thanks
bts

Suggestion:
This one is pretty simple and useful actually, I hope you will consider it

In the calculator,
-If the user enters only the Start Price and End Price, the Gain automatically fills itself too. Might be useful for making sells for a loss, to see how much user might lose. Or to make sure a static order is okay to go with.

-Two quantity fields: start + end. And if the quantity is also filled for start, it automatically fills end too. So it shows actual gain or loss also.

edit: this also might require buy+sell fee of course to see the actual loss and gain possibility.