Topic: Do you use a bot for trading? - page 5. (Read 17845 times)

Actually, that aspect of implementation pissed me off at the very beginning. When I want to let's say cancel 10 orders, why I can't simply list them all in single request. And after send a second request, listing these orders and requesting their current statuses. If some of them are cancelled and few hasn't yet and remain active I will receive that data in a single reply. Or when I have 20 orders and I would like to check their statuses (whenever they are executed, active, of partially completed), why can't I simply send a list of OrderIDs in a single request like "CheckStatuses: Count=20; ID1= ... ID20= " and in response receive a same list, but mentioning the current status of each. That be so much simpler!

That's likely what I'm talking about

If I remember correctly, Bter and Cryptsy allowed such requests. I'm 100% sure about Bter and not so sure about Cryptsy since it was too long ago when I had been using these exchanges (I know that Cryptsy scammed). What I mean basically comes down to sending authenticated requests (e.g. adding or removing orders) without having to wait until you receive a reply from your previous authenticated request. If you try that with, say, Bitfinex, you will just receive an error for your last request. In this way, you have to sync your requests with exchange replies

have never thought of my head for trading using the bot. I just feel a loss, when you're one of bots on the coins that have been a scam, and you're busy. it's probably going to spend the money you have. I've seen my friends use when trading in facebook bot. but I do not know, whether it is profitable or not, because it's just an image.

As far as I understood from your discussion with Sampey, this asynchonous routine is currently implemented on a very few markets. That one you considered, I've never worked on it. Originally we had a very defined list of markets we traded on and where we wanted some automation. So for as it makes no practical sense.


However, honestly speaking I still haven't fully understood what kind of async you are talking about. I can think of multiple scenarios of how that might be implemented, but not sure which one of those is considered in this case. From your discussion I understood that some market allows sending multiple requests and receive responds that are not obligatory in the queue. I don't see a problem in that, it's only that the structure of the reply will be different (containing some identification of your original request). Not a big deal, only that parsing of response is different.


For me it is more about what kind of problem you are trying to solve, whenever it requires sync or async approach

I mean I had to choose which mode to stick to myself (where I had such an option, of course). If we talk about cryptocurrency exchanges I simply can't see how asynchronous requests can be more difficult to implement than synchronous ones. Either is pretty simple and can't even come close in complexity to proprietary interfaces to "real" exchanges where you have to set up (export) callback functions, which are then called from external dlls. Foe example, if you use something other than MSVC compiler (linker), you may have issues with just correctly exporting function names (say, setting or removing specific prefixes that your linker adds to function names)

But this has more to do with your developer skills rather than synchronous or asynchronous api's as such

I'm not sure I properly understood what you mean by saying that

Totally agree! I personally started coding before garbage collectors became a common tool. I know how to avoid memory leaks and how to write a safe and stable code. My team members are professionals in their fields and the code we produce is of a high quality!

IMO making a good trading bot requires 3 key people: trader (that one who knows the strategy), the programmer/architect (the one who can implement it in the form of optimized and stable algorithm) and a coder (the one who can implement an algorithm in the stable code for the desired platform).
From the programmers perspective I was working on the core that is capable of doing much more than we needed for trading. Simply speaking, if our bot will begin to make 100x more operations than it does now, it will remain stable (already stress-tested)

Anyway, we trade in sync because its all we need for our successful trading and because this approach is universal among various markets. If we find some strategy that is significantly more profitable, we'll implement it no matter what technology mix it will require.

I did not use a bot for trading. I manually used trading for an altcoins. I didn't want the bot, handle my money, I want me to handle it. I want to have a fair about trading and even there is no bot for trading, it also act like that.

In fact, I've been there too and know how it feels

If you write shitty code (I don't mean you personally, of course), than even a garbage collector won't help you. But if you take care of memory issues, you don't need a garbage collector altogether. Running a trade system in a synchronous mode could potentially save you some headache, but just that alone won't make your code less shitty overall. In other words, the seeming complexity of an asynchronous mode is not an excuse for crappy code (if that was your point). Otherwise, there is no particular difference between synchronous or asynchronous modes of operation (in this regard)

Hi,
it's important to understand the concept of "without experience".
If you are able at least to choose 1 market with a lot of MAX/MIN values and set some limit like "Don't Buy Over X" and "Don't SELL Under Y", probably you will be able to make your gain even without know a lot about trading.
The funny things is that CAT have a "default" algorithm, that is the classic algorithm for people who doesn't wants to change anything.
Some person was able to gain without know how cat works 

But i'm not the right person to talk about my bot, because is mine 

Then only thing i can show you are my feedbacks : https://bitcointalk.org/index.php?action=trust;u=130152
Just press the "UNTRUSTED FEEDBACKS" to read all of them.
It seems users are satisfied 

Have you noticed that I mentioned our bot is made of two major parts?

Our strategy is not the high frequency one. Trading is very careful and targeted. Part 1 of the bot. We may check market like once every minute or even less often (depending on parameters).

Data-gathering is a 2nd part, it doesn't use private API and that one may work as a machine gun making lots of requests. However, that behavior is not always necessary (depends on a number of pairs, on market itself, on additional strategy adjustments). At the present moment we are working well within allowed limits.

Excuse me but that doesn't make much sense

At first you say that you go all out to get the smallest chunks of data possible querying an exchange a few (hundred) times a second using whatever tools are available (e.g. multiple servers and VPNs to overcome imposed limits), and then you continue to say that trading cycles take minutes to weeks and your bots are not the high frequency ones anyway



It is like saying that you opt for a sniper rifle while actually taking a machine gun belt as ammo

ha this thread happened to be very informative (unexpectedly)
thanks go to both deisik and campey and of course others who contributed to the discussion
a question to sampey,is it possible for a person without any experience in trading to earn anything with your bot?

No only cryptoworld 
I haven't much time to look into other things, real life is full 

Sure, we already have it this way But it takes time to come up with universal approach to cover all the little differences. For example, one exchange returns the list of executed orders from any desired day, another one returns only one month-back and for the lengthy strategies you have to sync your history. Little differences with various limits: minimum order sizes, minimum-maximum prices like on btc-e, number of digits after the comma, commission (absolute value versus percent), handling of partially executed orders... Anyway, we have resolved most of these issues and we made something really stable and universal.

But 24APIs - you are a Maaaaan! Honestly, I praise your patience!
Have you ever looked outside the crypto-trading? Like commodities, options?



It's all about implemented trading strategy! In our case speed is not of the great importance.
Depending on settings (mainly risk and greed), trading cycles on some pairs may take minutes, while others may last for weeks.
We have a gentleman-bot who walks less because he plans better You know, its like comparing a machine gun against a sniper rifle.

Just think that it may not have been worth doing at all

And this is real life. I spent literally months on doing some very intricate stuff at the max of my mental capacities (and sometimes beyond that) which I have never used afterwards. I would certainly change these months of non-stop coding and thinking for just one day of reading sense which would have prevented me from basically wasting my time



"Give me six hours to chop down a tree and I will spend the first four sharpening the axe"

The sync api call will be performed in the parallel data stream.
Sync doesnt means that your sistem must wait another API Call to be completed. Sync means that when the http protocol is invoked your program must wait for the response.

I have customers who heavily trade at the same time on over 100 markets.
Don't you really think that only 1 call is performed by my bot using a FIFO queue.

Solutions is simple : 1 Open Market = 1 GUI + 1 (or more) algorithm and 1 Algorithm = 1 or more dedicated thread. All call are sync at http level.

You example is true, but has nothing to do with sync/async call 

I could easily mention a few cases when this approach can lead to losses

Or less profits, for that matter. Imagine a situation where your bot is placing a new order, and at the same time it analyzes in parallel data streams (which you yourself mention). Then it sees that the market quickly changes, but it has to wait until this order gets placed (or does something else which requires waiting), and thus not being able to do anything with other orders (at the same exchange) may cost dear. For example, it sees that it is profitable to buy or sell some other coin at the exchange due to an arbitrage opportunity springing up that lasts only a few moments (just enough to place another order). These orders may not even be related to each other. If the bot were running asynchronously (and the exchange accepted asynchronous requests), it could send a new order immediately and grab the opportunity. You see, 1 second may be an eternity within which fortunes can be made as well as lost

Thank you so much man 

Real Api Number is 24 

18 In current Version
2 (Bitex/Liqui) in the coming version
3 Dismissed due to Exchange Close (Cryptsy/Cryptomic/RawX)
1 Never Go Live due to Exchange Scam (Mintpal)

 

Don't forget that the trick to interface so many exchanges is that you must create a layer

MAIN PROGRAM <-> API LAYER -> External Api Sistem

When

MAIN PROGRAM doesn't know anything about the API LAYER. Nothing in specific. Only the Interface the API Layer must respect.
Then you will be able to write the API LAYER For any exchange without many difficulties.

I don't consider to use bot in trading. Personally i don't use bot i manage my tradings all by my self in my own time . I handle it and manage it will all my best. And in fact many site don't allow us to use bot cause it's like cheating. Aside for that it's much better to work to earn . And if you have goals it much better if you are the who will pursue not just the bot you will use. Don't be lazy ! Work hard to earn

Wow, what a discussion

Our bots are generally made of two parts:
1. The trading part - the one that is responsible for placing orders and check their statuses is purely synchronous. We are sending request and waiting for the response, we analyze this response to make sure there is no error and everything run smoothly. Yes this approach is slower, but anyway our bots are not the high frequency ones. At the same time we are not generating a load of requests and we never exceed any limits, even when we trade multiple pairs.

2. The data-gathering part  - this one collects data to be used for analysis, it runs on the public API, so we are free to do what we like, multiple simultaneous threads collecting info about exchange rates of different pairs, collect data about order book, etc.

Regarding the 1st part - I honestly wouldn't feel safe by making it in asynchronous way. You can call me (and my team members) the lame programmers for that, we are not going to change our approach. It could be all about our skills, we are sure we can make it safe in totally synced manner, analyzing responses seems crucially important to us. On top of that, this seems to be working on all markets we working with and we see no practical reasons for making it differently.

Regarding the 2nd part - Oh yes, here we can be really nasty Paralleling requests, using multiple servers (and VPNs) to overcome imposed limits. Anyway we normally have 1-2 instances of the data-gathering for each market, while sometimes we have more than 200 separate instances of the trading part (different strategies / parameters / trading pairs / accounts).

My respect to Sampey, he managed to cover 18 (20 soon) different markets, we are not that advanced, we currently have only 5 and various little differences between them is already a significant headache.