Bitcoin Forum
December 11, 2016, 02:29:23 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Tradehill orderbook  (Read 1138 times)
nmat
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2011, 12:16:44 AM
 #1

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:
Quote
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.

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481423363
Hero Member
*
Offline Offline

Posts: 1481423363

View Profile Personal Message (Offline)

Ignore
1481423363
Reply with quote  #2

1481423363
Report to moderator
BitSense Informatics
Member
**
Offline Offline

Activity: 77


View Profile WWW
August 24, 2011, 12:27:27 AM
 #2

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
Sr. Member
****
Offline Offline

Activity: 428


View Profile
August 24, 2011, 12:32:57 AM
 #3

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
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2011, 12:40:52 AM
 #4

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
Member
**
Offline Offline

Activity: 77


View Profile WWW
August 24, 2011, 12:50:08 AM
 #5

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
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
August 24, 2011, 01:34:18 AM
 #6


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





Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
epetroel
Sr. Member
****
Offline Offline

Activity: 428


View Profile
August 24, 2011, 02:01:30 AM
 #7


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
Member
**
Offline Offline

Activity: 77


View Profile WWW
August 24, 2011, 06:11:55 AM
 #8

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
Sr. Member
****
Offline Offline

Activity: 392



View Profile
August 24, 2011, 07:44:05 AM
 #9

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

Seconded!

nmat
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 25, 2011, 01:29:10 AM
 #10

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
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
August 25, 2011, 04:15:15 AM
 #11

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.


Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
tvbcof
Legendary
*
Offline Offline

Activity: 1988


View Profile
August 25, 2011, 04:58:24 AM
 #12

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.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!