Tradehill orderbook

[nmat]

I am testing a basic trading bot and it just told me that someone was buying bitcoins at $11.65 at Tradehill around 23h24m UTC. This is way above market price.  According to bitcoincharts, these were the trades made around that time:

Aug 23, 2011, 23:36:51   10.86500   0.25   
Aug 23, 2011, 23:26:56   10.88000   0.90   
Aug 23, 2011, 23:26:56   10.87000   0.35   
Aug 23, 2011, 23:25:53   10.88000   0.20   
Aug 23, 2011, 23:12:37   10.86918   0.75   

Do I have a bug in my code, or is it possible that someone posted an order like this? I am using the Orderbook API call.

[BitSense Informatics]

I'm not recording market depth, but in the a UI component that I have set to automatically refresh market depth I have occasionally noticed a buy order show up that is higher than a lot of the asks, not sure if its an error on their side or what.

[epetroel]

I don't think you have a bug.  I've seen the same thing with both Tradehill and CampBX.

I believe this is what happens:

1.  Someone places an order to buy bitcoins at 11.65 (above the market price, since they know they will get the best available price anyways).
2.  Tradehill immediately shows that order to their order book.
3.  You place an order to sell at $11.65, thinking you can nab that order.
3.  Tradehill executes the 11.65 order against already existing orders, and it's filled before it even hits the ground.
4.  Your order languishes in no-mans land trying to sell at way above the market price.

Rather than publishing the order immediately into the order book, it should first be run against existing orders.  Then only published to the order book if it can't be filled with existing orders.

I believe MtGox already does this with their method of order queuing.  Queued orders are not shown in the order book.

The quick and dirty solution is to have your bot throw out any buy orders it sees that are equal to or above the lowest ask price.  This should solve the majority of your issues, but it'll still pop up from time to time.

[nmat]

I don't think you have a bug.  I've seen the same thing with both Tradehill and CampBX.

I believe this is what happens:

1.  Someone places an order to buy bitcoins at 11.65 (above the market price, since they know they will get the best available price anyways).
2.  Tradehill immediately shows that order to their order book.
3.  You place an order to sell at $11.65, thinking you can nab that order.
3.  Tradehill executes the 11.65 order against already existing orders, and it's filled before it even hits the ground.
4.  Your order languishes in no-mans land trying to sell at way above the market price.

Rather than publishing the order immediately into the order book, it should first be run against existing orders.  Then only published to the order book if it can't be filled with existing orders.

I believe MtGox already does this with their method of order queuing.  Queued orders are not shown in the order book.

The quick and dirty solution is to have your bot throw out any buy orders it sees that are equal to or above the lowest ask price.  This should solve the majority of your issues, but it'll still pop up from time to time.

Thank you. I guess I will add some ugly if's to my code and maybe send an email to Tradehill.

[BitSense Informatics]

I'm just starting the process of writing applications against the exchanges APIs so I've been curious what sort of gotcha's I'd start running into.  I've been using Interactive Brokers API years now and it never ceases to amaze me what sort of work-arounds I have to come up with sometimes to get things to work.

[Keyur @ Camp BX]

Nmat,
      We do what Eric mentioned: run an order against open orders first, and if it gets filled it will never show up in the Order Book. 

The remainder that does not get filled immediately gets added to the OB.  Now you will still see some order that you cannot fill though, because as soon as an order shows up in orderbook bots attacks it rather aggressively.  Some high-frequency bots written in C can fill the order before most of the regular algos in Perl/Python/Mathematica can react.


Hope this helps,
     Keyur

[epetroel]

Nmat,
      We do what Eric mentioned: run an order against open orders first, and if it gets filled it will never show up in the Order Book. 

The remainder that does not get filled immediately gets added to the OB.  Now you will still see some order that you cannot fill though, because as soon as an order shows up in orderbook bots attacks it rather aggressively.  Some high-frequency bots written in C can fill the order before most of the regular algos in Perl/Python/Mathematica can react.


Hope this helps,
     Keyur

Good to know!  And now that I look back at my logs, I am noticing that I never did see this exact issue for CampBX, just the one you mention about bots attacking orders and someone else "beating me to it".  Which of course is just going to happen on occasion.

[BitSense Informatics]

This is off topic, but we should set up a board/forum for Active/Automated BTC traders.  It would be interesting to hear what others are working on and some of the challenges they are facing.  I know that that developing trading software can be a somewhat secretive and developers and traders for obvious reasons do not want to divulge too much, but at the same time it would good to be in touch with others developing software.

I'll try contacting the forum moderator to see if maybe an "Exchange API development" child forum could be added under the Project Development Forum, unless there are other ideas.

Thanks,
-Rob

[toffoo]

This is off topic, but we should set up a board/forum for Active/Automated BTC traders.

Seconded!

[nmat]

Just added a few checks to the code and I noticed that this happens at TradeHill quite a lot.

Some high-frequency bots written in C can fill the order before most of the regular algos in Perl/Python/Mathematica can react.

I know that C is obviously faster and that it can probably cut down the decision time from, let's say, 100ms to 1ms. But given the current state of bitcoin exchanges, how relevant do you people think the language is? If all exchanges were using websockets I would understand, but right now you have to constantly poll TradeHill/CampBX/whatever to get new orders. The variance I get between HTTP requests makes those 99ms seem insignificant.

[Keyur @ Camp BX]

I know that C is obviously faster and that it can probably cut down the decision time from, let's say, 100ms to 1ms. But given the current state of bitcoin exchanges, how relevant do you people think the language is? If all exchanges were using websockets I would understand, but right now you have to constantly poll TradeHill/CampBX/whatever to get new orders. The variance I get between HTTP requests makes those 99ms seem insignificant.

Agree - the HFT code may not win every latency race due to high latency on the exchange side.  However on average / over long term, the HFT algos will have an edge.

[tvbcof]

I know that C is obviously faster and that it can probably cut down the decision time from, let's say, 100ms to 1ms. But given the current state of bitcoin exchanges, how relevant do you people think the language is? If all exchanges were using websockets I would understand, but right now you have to constantly poll TradeHill/CampBX/whatever to get new orders. The variance I get between HTTP requests makes those 99ms seem insignificant.

Agree - the HFT code may not win every latency race due to high latency on the exchange side.  However on average / over long term, the HFT algos will have an edge.

Sounds like the best bang for the buck is to co-locate in the same datacenter.