Price dip/rise Detector

[DeathfireD]

I posted this feature request in the forum a while back. Figured I'd add it here just so you wouldn't forget.

You could probably bake this into your current rule set so users can easily adjust the values to their liking. Here goes how I envision it, have the bot check the price, if it's 30+ points lower than the last market price then trigger a dip alert and buy however many coins the user wants (this would be customizable). Another option would be to sell if the price raises 30+ points (another value that the user can change) from the price you bought at. An option to limit how many times the dip alert can be triggered would be needed to prevent multiple buys if the value drops more after the first buy. To prevent confusion you'd have to save multiple "sell" points just in case the market takes a large dump. See example.

Example 1. Options that are set max number of dip buys = 2 (Number of buy ins when a dip is detected.) dip drop value = 30 (When a dip should be detected) dip raise value = 30 (When a raise should be detected) Amount to trade = 1 (this value will be used for all currencies BTC, LTC, NMC..etc)

1) Last market price was 1btc = $1080 2) Current price is 1btc = $1050 (went down 30 points triggers first dip buy alert) 3) Bot: buy 1btc at $1050 (Bot saves this value in local database as dip1=1050) 4) Current price is now 1btc = $1020 (went down another 30 based off of the previous buy price you made (ie. $1050), triggers second dip buy alert) 5) Bot: buy 1btc at $1020 (Bot saves this value in local database as dip2=1020) 6) Current Price is now 1btc = $990 (Went down a third time by 30 but because we have "max number of dip buys" set to 2, the bot will do nothing) 7) Current price is now 1btc = $1085 (Which is 30 points more than dip 1 ($1050) and dip 2 ($1020), this triggers a dip sell alert for both previous dip buys) 8) Bot: sells 2btc at $1085 ($65 profit, both dips where sold so we remove them from the local database and return to the first step of watching the last market price).

Example 2. Options that are set max number of dip buys = 2 (Number of buy ins when a dip is detected.) dip drop value = 30 (When a dip should be detected) dip raise value = 30 (When a raise should be detected) Amount to trade = 1 (this value will be used for all currencies BTC, LTC, NMC..etc)

1) Last price was 1btc = $1080 2) Current price is 1btc = $1050 (went down 30 points triggers first dip buy alert) 3) Bot: buy 1btc at $1050 (Bot saves this value in local database as dip1=1050) 4) Current price is now 1btc = $1020 (went down another 30 based off of the previous buy price you made (ie. $1050), triggers second dip buy alert) 5) Bot: buy 1btc at $1020 (Bot saves this value in local database as dip2=1020) 6) Current Price is now 1btc = $1050 (Went up by 30 for dip2, this triggers a dip sell alert) 7) Bot Sells 1btc at $1050 ($30 profit, bot removes dip2=1020 from the local database. Now only dip1=1050 is there.) 8 ) Current price is now $1000 (triggers a buy order since it's more than 30 points different from dip1's value of 1050). 9) Bot: buy 1btc at $1000 (saves to local database as dip2=1000) 10) Current price is now 1btc = $1085 (Which is 30 points more than dip 1 ($1050) and dip 2 ($1000), this triggers a dip sell alert for both previous dip buys) 11) Bot: sells 2btc at $1085 ($120 profit, both dips where sold so we remove them from the local database and return to the first step of watching the last market price).

[lookfirst]

@DeathfireD

Ok, I've implemented this I think. Using your numbers, I'm getting different profit totals though. I just want to make sure that your math is off and not mine. =)

Example 1:

info:    Current price: 1080  Last price: 1080   Dips:
info:    Current price: 1050  Last price: 1080   Dips:
info:    Delta: 30 >= DipDropValue: 30
info:    Bought 1 at 1050
info:    Current price: 1020  Last price: 1050   Dips: 1050
info:    Delta: 30 >= DipDropValue: 30
info:    Bought 1 at 1020
info:    Current price: 990  Last price: 1020   Dips: 1050,1020
info:    Delta: 30 >= DipDropValue: 30
info:    Current price: 1085  Last price: 1020   Dips: 1050,1020
info:    Delta: 35 >= DipRaiseValue: 30
info:    Sold 1 at 1085. Profit: 65  Total profit: 65
info:    Delta: 65 >= DipRaiseValue: 30
info:    Sold 1 at 1085. Profit: 35  Total profit: 100

Example 2:

info:    Current price: 1080  Last price: 1080   Dips:
info:    Current price: 1050  Last price: 1080   Dips:
info:    Delta: 30 >= DipDropValue: 30
info:    Bought 1 at 1050
info:    Current price: 1020  Last price: 1050   Dips: 1050
info:    Delta: 30 >= DipDropValue: 30
info:    Bought 1 at 1020
info:    Current price: 1050  Last price: 1020   Dips: 1050,1020
info:    Delta: 30 >= DipRaiseValue: 30
info:    Sold 1 at 1050. Profit: 30  Total profit: 30
info:    Current price: 1000  Last price: 1050   Dips: 1050
info:    Delta: 50 >= DipDropValue: 30
info:    Bought 1 at 1000
info:    Current price: 1085  Last price: 1000   Dips: 1050,1000
info:    Delta: 35 >= DipRaiseValue: 30
info:    Sold 1 at 1085. Profit: 85  Total profit: 115
info:    Delta: 85 >= DipRaiseValue: 30
info:    Sold 1 at 1085. Profit: 35  Total profit: 150

[DeathfireD]

haha @lookfirst yes, my math was off :/. Sorry about that. Are you programming this into the bot?

[DeathfireD]

Oh a few other things. I don't see any "dip buy limit" in your pseudocode. There definitely needs to be an option to limit how many times the bot should buy in when a dip is triggered. If there isn't and a dump like today happens, a lot of people are gonna have crazy amounts of buys.

Second thing you'll want to include if it's not already included in the bot's logic is to make sure your wallet actually has enough funds to make the trades.

Thanks!

[lookfirst]

Yea, I've got most of your algorithm implemented as a nodejs bot. It actually wasn't too hard thanks to your excellent description. Thanks for the confirmation on the math.

I also haven't tied it into actual trading yet. I'd like to let it run for a bit and see what happens. The pain right now is that btce is pretty stable right now... not much movement so I'm not seeing buy/sells even at drop/raise values of $2.

I'm going to have to get a source of historical data and run it against that and see what happens.

[lookfirst]

I have a 'numberDipBuys' variable. In the logging output above, it is configured for 2 in order to simulate your examples.

I haven't tied anything to wallets yet. I'm keeping that for the very last thing I do! =)

[DeathfireD]

@lookfirst try it on name coins and set it to 5 or 10. Name coins have been jumping around for the past hour. Also take fee into account.

[lookfirst]

@DeathfireD another good suggestion! =)

[lookfirst]

Oh, this was kind of neat... happened super fast. I suspect that the btce api wouldn't have even caught that order in time. I'm a bit worried about that actually... I'm going to have to also check that orders get 100% filled before doing buy/sells.

info:    Current price: 628  Last price: 628  Diff: 0    Dips:
info:    Current price: 628  Last price: 628  Diff: 0    Dips:
info:    Current price: 625  Last price: 628  Diff: -3    Dips:
info:    Delta: 3 >= DipDropValue: 2
info:    Bought 1 at 625
info:    Current price: 629.5  Last price: 625  Diff: 4.5    Dips: 625
info:    Delta: 4.5 >= DipRaiseValue: 2
info:    Sold 1 at 629.5. Profit: 4.5  Total profit: 4.5
info:    Current price: 629.5  Last price: 629.5  Diff: 0    Dips:
info:    Current price: 629.5  Last price: 629.5  Diff: 0    Dips:

[DeathfireD]

haha ya that's probably a good idea. I have a feeling this is gonna flood your order history with buys and sells if you set low values :).

[JulyIghor]

Thank you for detailed instructions. I'll make script language to be able to program this. I'll test your algorithm and you will be able to do similar.

[lookfirst]

I just realized something. Instead of making the dip drop/raise values hard numbers, instead use a percentage diff between current and last. This way, if the raise is say 10% more than last price, do a sell. This makes it really easy to compute gains based on percentages instead of hard numbers, which is something I'd rather work with. Apologies that this issue has turned into more of a discussion than an issue.

[lookfirst]

By the way, with 30/30 settings, this idea has made $152 in the last 3 hours. Not bad.

Now I just have to finish up the actual trading code. ;-)

[DeathfireD]

@lookfirst I agree. Percent would probably be better for this. On the flip side, some people may still want to use a number and not a percent though. I think when this is implemented into @JulyIGHOR 's bot, users should be able to use either percent or number.

That's good to hear about the $152. I can't wait to test it :).

[DeathfireD]

@lookfirst how's it going? What's the stats been like or did you stop it?

[lookfirst]

@DeathfireD Here is an implementation question: How should I handle the orders?

For example, the bot creates an order for a buy at a specific price, but then the price immediately goes up, so the order remains un or partially filled.

• Do I leave that order open?
• For how long?
• What happens if it is partially filled? (btc-e doesn't support all or none / fill or kill)

Unfortunately, with btc-e, it also seems there is no easy way to tell if an order has been fully filled or not, unless it fills immediately, which is something we can't count on. You can see the filled % on their website, but there is nothing in the API for this. I've filed a support request to get this added to the response from the ActiveOrders API call, but who knows if anyone is listening to the support queue.

I've coded things up to not bid when there is already max number of dip buys and open buy orders >= max number of dip buys. The other side of this is figuring out how to do the sells. What happens if those remain open too? I can see this problem quickly locking up the bid engine with orders that'll never fill.

I'm working on figuring out the partially filled amount for an order from the TradeHistory, but I can already tell this is going to be problematic as I have a case where I did a sell of 1 btc and it went through with 3 separate order number id's that their system created (is_your_order == 0)! In other words, I can open an order to buy/sell, but there is no way associate that with the tradehistory so I can't tell if any active orders are filled or not.

Any insightful thoughts?

[DeathfireD]

If I understand you correctly you're having an issue where the bot is placing an order for the current price however the current buy/sell price is different so your order just sits their waiting for someone to fill it?

You'll probably need to introduce a new option or options "spread" (low spread/high spread). Place the order using the current market buy/sell price as long as it's within your spread. So, for example, if your spread was set to 5 and current price is 625 but the current market buy price is 620, it's still within your 5 point spread so you'd place a buy order for 620 which should happen instantly. A buy order happens if the Market Buy Price is 1-5 points higher or lower than 625. If the price suddenly shot up or down past your spread than no order would be placed at all and the bot would continue monitoring. Does this make sense?

Another quick example using low and high spread.

current market price: 625 current market buy price: 615 low buy spread: 13 high buy spread: 5

Current Market Buy Price is 10 less than 625 and out low buy spread is 13 so we place an order for the current market buy price of 620.

current market price: 625 current market buy price: 631

Current Market Buy Price is 6 more than 625 and our high buy spread is 5 so we don't place any order.

[lookfirst]

This is certainly one way to deal with it, but complicates things greatly if there is overlap with the dip drop/raise values. You are assuming the values are greater than the spread.

It also doesn't answer the question of what happens if an order remains un or partially filled. Because you make an order lower than the current buy price, it still doesn't mean that it will get filled.

I've seen great jumps and dips within 5 seconds of each other that could cause an order to not get filled. Some of these jumps have been buy / sell targets for my bot.

There must be an easier way.

[lookfirst]

Ok, after spending the whole day on this, I'm totally stumped now. I have no idea how people are writing bots against btce and I've looked at the source code to one of them and I can't imagine running it with real money.

I was thinking, maybe I'll just go the super simple route and force only one buy or sell order at a time. But, the problem is that with the btce api, there is no way to reliably tell if a single order is started, finished or in progress. Thus, I can't tell if my single order is done or not.

I can open an order for some insane amount that'll never get filled (sell .01 for $2k USD), then wait a few seconds, hit /getInfo and see that there is still 0 open orders because the API is lagging behind reality. Even still, I have no way to know if that value is 0 because the order executed or because the API is lagging. I could also check /tradeHistory for the order id, but because btce might split up my order into multiple smaller orders and execute them, the id's get generated and don't match up to the original order id (is_your_order == 0).

I can look in /activeOrders, but that also has the same problem as /getInfo because the order is either just not appearing yet or has already executed. It's order id also might not line up if the order is split into multiple orders.

If /trade remains == 0, that is the only way I can tell the order executed, but that only returns when I start a trade and the chances of it executing immediately are unknown.

This is quite possibly the most worthless and poorly designed API I've ever seen. I can only imagine what the rest of that site's code looks like. Sigh. I'm not sure this bot can be used at all as it really requires a human to sit and visually look at the state of multiple different sources for data to prove the API has actually done what you hope it has done.

[Squeaker]

I think a lot of them (myself included, when I get done coding my method up) are auto-trading using market orders instead of limit orders.

That way, they allow the market to move more without putting up walls to slow things down, and when they place the order, it executes right away.

Any orders left behind if the market moved too fast, would get cancelled in less than a minute.

(my guesses... I don't have direct knowledge of how the API itself works, but if you keep track of order numbers, and just keep cancelling ones that are old, should have no problem. If the order executed, it'll fail. No big deal.)

[DeathfireD]

Well I suppose a simpler solution would be to ignore my spread idea and just place your order based on the current market sell/buy price (the price people are trying to buy/sell it for in the order books). It's obviously not going to be the same as the last price 90% of the time but at least the orders are being made as fast as possible. It's ok to buy in at a lower (or higher) price than the last price...the draw back to this is that if the market sell price is much lower than the last price and it ends up being less than our original dip value...then we're potentially losing money. See below for some pseudo code.

So "ActiveOrders" doesn't return your current orders fast enough? If that's the case then your bot must be trying to make trades crazy fast. Have you tried forcing it to pause for a second after an order is placed?

I think you could do something like this but you may have to do more checking than this for the dip alert. //after initial dip detection //buy order trigger if(market_buy_price > last_price) { //do nothing. We want to buy low. }else{ //buy in because market buy price is lower or equal to last price and we like buying in at low prices. }

//after initial rise detection if (market_sell_price < last_price || market_sell_price < your_buy_in_price) { //do nothing because we don't want to sell for less than the last price or sell for less than our buy in price. }else{ //sell }

[lookfirst]

@Squeaker thanks for the input, but take a look at the API for btce, I think you'll be in for some nice surprises. ;-)

@DeathfireD Thank you for continuing to try to help, but your logic doesn't take into account what is going on on the exchange with regards to your orders.

Let me rewrite your if statement above to what the potential problems would look like:

1. buy order trigger
2. buy order sits there open or partially filled
3. if/else kicks in to make a second buy order.
4. buy order sits there open or partially filled

time goes by. rise is detected.

1. open buy orders is still 2, but we actually have no way of knowing that for absolute sure.
2. logic (hopefully) kicks in to prevent sell because open buy orders exist and there is potentially nothing to sell because the initial buy orders didn't execute

There is NO reliable way to know if an order has executed at all. Waiting doesn't help because what if btce is unavailable, the net goes down or the bot quits? How can I pause after a second order is placed if I don't know if the first has executed or not?

I can look at a list of ActiveOrders, but they are meaningless to me because I can't map them to the order that I made because they may have been auto generated by their system when they decided to partially fill my order (I've linked to a SE article where I answered this question with a good example of what I'm talking about). I still can't tell if my order that I did place has executed or not, so I can't tell if it has shown up in ActiveOrders yet (maybe I waited for 10 seconds, 30 second, how long?) or if it has executed and isn't there because of that.

Even still, what happens if I place an order an it isn't executed and it remains in the ActiveOrders list? Do I leave it there for a few minutes? Do I somehow remove it?

Maybe I need this shitty complicated logic:

1. Place an order.
2. Hit ActiveOrders for X minutes to see if anything shows up.
3. Hit TradeHistory for X minutes and see if there is 1+ more trades (A)
4. If ActiveOrders has a buy order for > X minutes and TradeHistory hasn't increased. Cancel the order. (B)
5. If ActiveOrders has a buy order for > X minutes and TradeHistory has increased. (C)
6. If ActiveOrders has a sell order for > X minutes and TradeHistory hasn't increased. Cancel the order. Try again on the next raise.
7. If ActiveOrders has a sell order for > X minutes and TradeHistory has increased. (C)
8. Don't execute any buys or sells until ActiveOrders is empty and TradeHistory has 1+ more trades.
9. Don't execute any buys or sells while orders are being cancelled.

(A) Also means I need to track and store the tradehistory locally to do the comparison. (B) Need to track locally when an order was made. Sigh. (C) Not sure what to do here. This is a partial order that hasn't completed. Do I cancel the rest? How do I know how much to sell in the future? Do I now track my balances and try to sell the increase in balance on a raise?

I'm really going to have to complicate my whole data model to keep track of all of this state. Everything is going to have to be stored as a Trade object and then try to follow the state of that trade as well as only act based on the state of all trades. With your original idea, it was super simple, all I had to do was keep track of an array of numbers. ;-)

Bleh. I guess if this was so easy, everyone would be doing it. ;-)

[akijuh]

If you know your BTC balance, and sell order is kicked in, BTC balance goes down and USD balance up, and with buy order vice versa.

This way you can be sure that your order is executed, and if you track BTC/USD amounts, you know if order is executed fully or not.

[Squeaker]

@lookfirst: will check out the API's later, after I finish my current project. (was thinking of taking a stab at coding up Vircurex's API)

@DeathfireD: mine doesn't actually fire off very fast, unless I'm trying to test something. I'm using a conservative algorithm, that reacts to the market instead of trying to anticipate it. I don't make as much as I could be, but I'm also taking less risk at the same time, so I'm content.

In a nutshell, it is a ratio-based system, making only market buys and sells, with the ratios calculated by the best buy and sell orders on the book. If my ratio (commodity value :: total value) goes over 55%(0.55), it starts selling gradually with small orders over time until my ratio drops below 55%. If my ratio drops below 45%(0.45), it starts buying in the same manner. (experimenting with different base ratios, but the 50%+/-5% is what I'm testing with)

Right now I'm doing 0.01 BTC orders. Soon as I work out a few bugs I'm hunting down, I'll add in dynamic amounts too, so I can set any percentage of my currency/commodity on hand for the order (probably go with 1% or minimum, whichever is greater)

I'm not testing with this, but I can include additional orders with a wider ratio, say to sell at 60%, if a big upswing happens, or to buy at 40% for a big downswing, and buy/sell in larger chunks as those don't last that long usually.

As of right now, I have ratio-based rules halfway working.

: ^ . . ^ : >\ V /< : 'squeak'

[lookfirst]

@akijuh hmmm.... let me think about that one for a bit.

This is also new... http://www.reddit.com/r/BitcoinMarkets/comments/1t9vkz/stopconditional_orders_for_most_major_exchanges/

The funny thing is this quote:

"When creating stop orders, remember that the trigger price should probably be slightly higher or lower than the price you want to sell or buy at because if the market is moving fast your new order might not actually get fulfilled at that price."

Oh yea, I know that pain! =)

[lookfirst]

Found some decently intelligent logic for dealing with btce.

https://github.com/nomorecoin/tAPIbot/blob/master/tapi/trader.py

[DeathfireD]

@lookfirst nice, have you made any progress.

[lookfirst]

I've taken a few steps back and started to rewrite things with the express intentions of being a more solid product... instead of the hacky first version I was working on. This is necessary to build something that I can work with against btce. It'll be a while longer before I get to finish it. I'll update here as I get closer.

[ghost]

Hello guys!

I like this feature very much BUT, I would like to suggest an "hybrid", or a "intermediary" solution, which is more or like this:

1- Not fully automated;

2- "Price remember", described in item "3" (Bot sabes this value in local db);

3- Works more as "co-pilot", instead of fully automated;

4- Profit Alert (dip 1 - red , dip 2 - yellow, dip 3 - gree).

This way, for example, if I sell 5 BTC @ 875 and 10 @ 885, the QtTrader will register it and then, when the price drops to, lets say, 870, 860, the QtTrader will alert me "Profit in hands! Buy now?", of course, it must have alerts "per volume / price", which means that, X BTC sold @ 875, will start to profit after the spread (@ 865), and so on...

What about that?!

I prefer this (the bot as a "co-pilot") instead of it fully automated, because I think it is safer... I'm used to follow Ichimoku Cloud and RSI a lot... So, I prefer to make the decisions by myself.

Happy New Year!

Cheers! Thiago

On 17 December 2013 00:16, DeathfireD notifications@github.com wrote:

I posted this feature request in the forum a while back. Figured I'd add it here just so you wouldn't forget.

You could probably bake this into your current rule set so users can easily adjust the values to their liking. Here goes how I envision it, have the bot check the price, if it's 30+ points lower than the last market price then trigger a dip alert and buy however many coins the user wants (this would be customizable). Another option would be to sell if the price raises 30+ points (another value that the user can change) from the price you bought at. An option to limit how many times the dip alert can be triggered would be needed to prevent multiple buys if the value drops more after the first buy. To prevent confusion you'd have to save multiple "sell" points just in case the market takes a large dump. See example.

Example 1. Options that are set max number of dip buys = 2 (Number of buy ins when a dip is detected.) dip drop value = 30 (When a dip should be detected) dip raise value = 30 (When a raise should be detected) Amount to trade = 1 (this value will be used for all currencies BTC, LTC, NMC..etc)

1) Last market price was 1btc = $1080 2) Current price is 1btc = $1050 (went down 30 points triggers first dip buy alert) 3) Bot: buy 1btc at $1050 (Bot saves this value in local database as dip1=1050) 4) Current price is now 1btc = $1020 (went down another 30 based off of the previous buy price you made (ie. $1050), triggers second dip buy alert) 5) Bot: buy 1btc at $1020 (Bot saves this value in local database as dip2=1020) 6) Current Price is now 1btc = $990 (Went down a third time by 30 but because we have "max number of dip buys" set to 2, the bot will do nothing) 7) Current price is now 1btc = $1085 (Which is 30 points more than dip 1 ($1050) and dip 2 ($1020), this triggers a dip sell alert for both previous dip buys) 8) Bot: sells 2btc at $1085 ($65 profit, both dips where sold so we remove them from the local database and return to the first step of watching the last market price).

Example 2. Options that are set max number of dip buys = 2 (Number of buy ins when a dip is detected.) dip drop value = 30 (When a dip should be detected) dip raise value = 30 (When a raise should be detected) Amount to trade = 1 (this value will be used for all currencies BTC, LTC, NMC..etc)

1) Last price was 1btc = $1080 2) Current price is 1btc = $1050 (went down 30 points triggers first dip buy alert) 3) Bot: buy 1btc at $1050 (Bot saves this value in local database as dip1=1050) 4) Current price is now 1btc = $1020 (went down another 30 based off of the previous buy price you made (ie. $1050), triggers second dip buy alert) 5) Bot: buy 1btc at $1020 (Bot saves this value in local database as dip2=1020) 6) Current Price is now 1btc = $1050 (Went up by 30 for dip2, this triggers a dip sell alert) 7) Bot Sells 1btc at $1050 ($30 profit, bot removes dip2=1020 from the local database. Now only dip1=1050 is there.) 8 ) Current price is now $1000 (triggers a buy order since it's more than 30 points different from dip1's value of 1050). 9) Bot: buy 1btc at $1000 (saves to local database as dip2=1000) 10) Current price is now 1btc = $1085 (Which is 30 points more than dip 1 ($1050) and dip 2 ($1000), this triggers a dip sell alert for both previous dip buys) 11) Bot: sells 2btc at $1085 ($120 profit, both dips where sold so we remove them from the local database and return to the first step of watching the last market price).

— Reply to this email directly or view it on GitHubhttps://github.com/JulyIGHOR/QtBitcoinTrader/issues/101 .

[lookfirst]

@tmartinx Lol, you must never sleep. =)

[ghost]

lololol... I hate sleep! =P

Anyway, it is not like that, for example, my "rise detector" is (almost) only when RSI crosses over 70~80, then I sell. It happens about 3~5 times within 5~10 days, so, I can take a nap eventually... ehehe

Like this week: http://bitcoincharts.com/charts/mtgoxUSD#rg5zig30-minztgSzbgBza1gEMAzm1g10za2gEMAzm2g21zxzi1gRSIzi2gMACDzi3gStochRSIzi4gMomentumzvzps

I sold @ ~885, to rebuy @ ~850 few hours later (yesterday)... Today I did some trades too, sold @ 884, to rebuy @ 867... A few bitcents every day... =)

And I also hate to the math by myself, I mean, I need to keep tracking about how much BTC I sold (amount), and in which price... To buy later without feeding only the Exchange (amount/price per amount/price)... So, this "memory price" of QtTrader will be really helpful!

I really think that QtTrader can do this tracking plus some alerts when the BTC profit arrives... (my profit is only measured in BTC).

Cheers! Thiago

On 3 January 2014 23:16, Jon Stevens notifications@github.com wrote:

@tmartinx https://github.com/tmartinx Lol, you must never sleep. =)

— Reply to this email directly or view it on GitHubhttps://github.com/JulyIGHOR/QtBitcoinTrader/issues/101#issuecomment-31567315 .

[DeathfireD]

@lookfirst any news on this yet?

[lookfirst]

Interesting, I just looked at my bitfinex account and it seems that they lowered their rates? I thought they were higher... it's 0.15% now, which is lower than btc-e. They also have a sane API, fill or kill, and a decent amount of volume, not as much as btc-e, but at least I can tell if an order has executed or not. I'll be moving over to them as I progress on this bot in my spare time.

[ralyodio]

i have their fee at 0.12.

[lookfirst]

5000 or more traded in the last 30 days (for the traded pair) == .12

[ralyodio]

gotcha

[DeathfireD]

Do you have a working bot we can test yet?

[DeathfireD]

I've been digging into a bunch of different open source bots. There seems to be a bunch of methods people have used to get around this issue. The most popular seems to be the method I mentioned above. Buy/sell either at the current going rate or buy/sell at a a value that's a little more or less than the going rate.

For example if the highest sell in the order book is .1 BTC then the bot would buy at .11 BTC to ensure the sale would happen fast. If the highest buy is .1 then sell at .99. These small changes in value would have to be factored into the code as to not lose profits.

Another method that I've seen in "roller" bots is to place 5 or so orders and then after x amount of seconds if any orders are still around the bot kills them.

@lookfirst have you come up with a way to make this work?