I gave my bot code to a few developers, but none of them contributed back, so I'm not sure if anyone uses it. I also don't know if anyone downloaded the lib sources and uses it in some app. At least noone told me so, so I guess I'M the only user for now.
This code was a donation to the openbitcointrader project, but I'm not sure, if there's any code written for it at the moment.
I guess if your reference currency is bitcoin and you went from 1 to 1.1 btc, you made 10% profit, even if btc dropped from 200 to 100$.
That's why it might be better to use a fiat currency as the scale.
Topic: Programming a trading bot – Some thoughts (Read 1023 times)
It looks like you have been working on yours for awhile also. Are you the only one using it, or are others using it also?
One of the other fun questions I have been trying to figure out is how to determine if a bot is 'successful', or that it 'works'. My strategy is to accumulate bitcoins, so as long as I have more than I started with, then I call that a success. I can't pin success on a dollar amount because I could have more Bitcoins than when I started, and have less overall value than when I started. In that case, how much of an increase in BTC over what period of time is considered a success? Again, that depends on the market and whether or not it swings enough to trigger any transactions.
It feels disingenuous (to me) to claim that any bot will make 'x' amount of profit, or to claim that one will see an 'x' percent increase in holdings.
One of the other fun questions I have been trying to figure out is how to determine if a bot is 'successful', or that it 'works'. My strategy is to accumulate bitcoins, so as long as I have more than I started with, then I call that a success. I can't pin success on a dollar amount because I could have more Bitcoins than when I started, and have less overall value than when I started. In that case, how much of an increase in BTC over what period of time is considered a success? Again, that depends on the market and whether or not it swings enough to trigger any transactions.
It feels disingenuous (to me) to claim that any bot will make 'x' amount of profit, or to claim that one will see an 'x' percent increase in holdings.
I'm working on similar stuff for quite a while:
https://i.imgur.com/OoP0aNo.jpg
https://i.imgur.com/xpqoqnk.png
https://i.imgur.com/OoP0aNo.jpg
https://i.imgur.com/xpqoqnk.png
I didn't mention, but I have an active demo running on a test web page at http://www.minzie.com/Lazy/ that is actively trading on a live test account. The source code for a stand alone version can also be downloaded. I have not done anything with the stand-alone version as far as creating an installer or anything like that, but I will be willing to help set it up if anyone is interested.
Yeah, coding a tradebot is a great learning experience!
1 request / second is an extreme frequency in my eyes. I usually do like 1 request every 15 seconds, or so.
1 request / second is an extreme frequency in my eyes. I usually do like 1 request every 15 seconds, or so.
I have been working on a trading bot for about three months now, and I thought I would share some of my experiences thus far.
***********************************************************************************************
Developing a trading bot with a limited function set is a fun exercise, and not what I would describe as overly complex. Implementing an algorithm to buy low and sell high should be well within the grasp of most first year computer science students. Adding a few additional parameters is not all that complex either, but the possible interactions between parameters does get complex quickly.
Transaction fees are not assessed how I initially thought they were. Everybody knows that exchanges charge a nominal fee. What I did not realize was that a single transaction on my side can trigger multiple transactions on the exchange side. For example, let us say that I wish to buy three BitCoins for $100 each. At that exact time, there are two sellers holding three BitCoins collectively that they are willing to sell for $100 each. The exchange makes two purchases on my behalf, and I get charged for two transactions. While this is not a huge deal, it makes it difficult to predict overhead.
I also realized rather quickly that the GUI is a separate application from the actual trading bot. While the idea of separating the view from the model is a basic tenet of software engineering, the temptation to be lazy and write code that binds both applications to each other is tremendous. Equally tempting is to create duplicate code for both applications. I find this aspect very interesting because I do not often get to work on anything other than portions of the overall code, and I never get to work on the back end.
While I mentioned that creating a trading bot is not overly complex, there are some interesting challenges. Limit orders are one of those challenges. Typically when one makes a purchase, they would like to see their balances updated immediately. With a limit order, the problem becomes harder. One is not sure when the order will go through, so the GUI will not know when it needs to update to reflect the current balance in the account. I could continually ping the exchange until I get the information that I need. This is not necessarily practical, as discussed in the next section.
Due to ongoing and persistent attacks, exchanges have been forced to employ extreme measures to keep themselves in business, such as only allowing so many connection attempts per timeslice. From a development standpoint, I have to account for those limitations. The BitStamp API states that one connects to their site no more than once per second, and I can vouch that if you exceed that limit, your IP will be banned.
My objective is to have several bots operating at the same time on the same machine, so I have to consider timing issues versus the limitations on requests from the exchange. For my single instance test, I am just using some hard coded delays to stay well within limits. I am considering just using a simple queue to coordinate bot instances.
These restrictions have also forced me to consider the longest acceptable period of time before updating the GUI. I have it set to 30 seconds, although the bots themselves only update once a minute. The trick is to find a nice balance between an acceptable staleness of data, and frequency of updates. My particular strategy means that sometimes the market data is out of synch with what the GUI is displaying. If one considers that data is stale the moment they see it, then it just becomes a discussion of degrees of staleness.
The user interface is hard. Some of the interfaces I have seen for other trading bots are incomprehensible to me. I don’t mean that as a criticism to anyone; everyone has their own concept, and I am certainly no expert on what data should be available, or how it should be displayed. I just find some of the interfaces daunting. The user needs a certain amount of data in order to make an informed decision, and if one looks at the bots available, one can see that they all display the same data, more or less. The challenge for me is to give my bot a visual ‘personality’, and still provide the same information.
Basic math is hard. Not because it really is hard, but for some reason I think it beneath me to test it. It’s basic math, who needs to test? (Answer: This guy).
Day to day, I do not really have the opportunity to delve into the theoretical parts of computer science as part of the regular decision making process. With this project though, I am looking a queues, scheduling, distributed systems, cryptography, database encryption, and a host of other issues that actually utilize my education.
EDIT: Forgot link: http://www.minzie.com/Lazy/
***********************************************************************************************
Developing a trading bot with a limited function set is a fun exercise, and not what I would describe as overly complex. Implementing an algorithm to buy low and sell high should be well within the grasp of most first year computer science students. Adding a few additional parameters is not all that complex either, but the possible interactions between parameters does get complex quickly.
Transaction fees are not assessed how I initially thought they were. Everybody knows that exchanges charge a nominal fee. What I did not realize was that a single transaction on my side can trigger multiple transactions on the exchange side. For example, let us say that I wish to buy three BitCoins for $100 each. At that exact time, there are two sellers holding three BitCoins collectively that they are willing to sell for $100 each. The exchange makes two purchases on my behalf, and I get charged for two transactions. While this is not a huge deal, it makes it difficult to predict overhead.
I also realized rather quickly that the GUI is a separate application from the actual trading bot. While the idea of separating the view from the model is a basic tenet of software engineering, the temptation to be lazy and write code that binds both applications to each other is tremendous. Equally tempting is to create duplicate code for both applications. I find this aspect very interesting because I do not often get to work on anything other than portions of the overall code, and I never get to work on the back end.
While I mentioned that creating a trading bot is not overly complex, there are some interesting challenges. Limit orders are one of those challenges. Typically when one makes a purchase, they would like to see their balances updated immediately. With a limit order, the problem becomes harder. One is not sure when the order will go through, so the GUI will not know when it needs to update to reflect the current balance in the account. I could continually ping the exchange until I get the information that I need. This is not necessarily practical, as discussed in the next section.
Due to ongoing and persistent attacks, exchanges have been forced to employ extreme measures to keep themselves in business, such as only allowing so many connection attempts per timeslice. From a development standpoint, I have to account for those limitations. The BitStamp API states that one connects to their site no more than once per second, and I can vouch that if you exceed that limit, your IP will be banned.
My objective is to have several bots operating at the same time on the same machine, so I have to consider timing issues versus the limitations on requests from the exchange. For my single instance test, I am just using some hard coded delays to stay well within limits. I am considering just using a simple queue to coordinate bot instances.
These restrictions have also forced me to consider the longest acceptable period of time before updating the GUI. I have it set to 30 seconds, although the bots themselves only update once a minute. The trick is to find a nice balance between an acceptable staleness of data, and frequency of updates. My particular strategy means that sometimes the market data is out of synch with what the GUI is displaying. If one considers that data is stale the moment they see it, then it just becomes a discussion of degrees of staleness.
The user interface is hard. Some of the interfaces I have seen for other trading bots are incomprehensible to me. I don’t mean that as a criticism to anyone; everyone has their own concept, and I am certainly no expert on what data should be available, or how it should be displayed. I just find some of the interfaces daunting. The user needs a certain amount of data in order to make an informed decision, and if one looks at the bots available, one can see that they all display the same data, more or less. The challenge for me is to give my bot a visual ‘personality’, and still provide the same information.
Basic math is hard. Not because it really is hard, but for some reason I think it beneath me to test it. It’s basic math, who needs to test? (Answer: This guy).
Day to day, I do not really have the opportunity to delve into the theoretical parts of computer science as part of the regular decision making process. With this project though, I am looking a queues, scheduling, distributed systems, cryptography, database encryption, and a host of other issues that actually utilize my education.
EDIT: Forgot link: http://www.minzie.com/Lazy/
Jump to: