Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coinbase – Exchange API

docs.exchange.coinbase.com

Post reply on HN
Print view View original

21–30 of 42 posts

Re: Coinbase – Exchange API

#21

Post by functionCall »

clarkmoody wrote: post #6
artursapek wrote: post #4

Earlier quoted context omitted.

Really? I've found Kraken's pretty hard to work with. They're inconsistent in some ways, like their currency pair names (sometimes "XXBTXZEUR", sometimes "XBTEUR"). Also, they are the only ones I've come across who don't just use plain old integers for ids - they have some weird scheme that has string ids formatted like O6W5EU-VY7YF-CS3XNP. That said, they're better than say BTC-e and OKCoin :)

The way Coinbase is doing the streaming WebSocket data looks very good. My frame of reference is Bitstamp and Mt. Gox before that... Keeping a proper copy of the order book on the client side should be fairly straightforward. Bitstamp's API makes it impossible to keep the full order book synced. They broadcast the top 20 rows over the socket, but for many situations that's not good enough.

Bitstamp has a new websocket channel https://www.bitstamp.net/websocket/ where you can get full order book updates.

Re: Coinbase – Exchange API

#22

Post by minimax »

(Thoughts from someone who works in this space)

Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address.

I think I understand why they are doing this. They want to have a clean REST order entry interface, but still allow participants to know immediately when they are filled (via the websockets feed). Ultimately, they should implement a websockets order entry interface and stream accepts, fills, cancels, and rejects only to the involved participants. They should not expose any client generated ids on the public feeds, and only non-marketable orders and trades should hit the public feed. This is how it works literally everywhere else. Also it wouldn't hurt to have time-in-force (IOC, etc) and support for non-displayed orders.

Re: Coinbase – Exchange API

#25

Post by mrchicity »

minimax wrote: post #22

(Thoughts from someone who works in this space) Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address. I thin…

Also if they're charging 25 bps to be a taker vs. 0 to make, people will want a post-only order.

I actually like the idea of putting ClOrdIDs on the feed, maybe encrypted with some key only the sender has? Would make excluding one's own orders so much easier and no concerns about who sees what first: http://www.wsj.com/articles/SB100014241278873237981045784550...

Re: Coinbase – Exchange API

#26

Post by benjaminjackman »

minimax wrote: post #22

(Thoughts from someone who works in this space) Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address. I thin…

I have not rwad the article but from what you are describing it sounds like they probably should just use itch.

I think anonymity in markets might be something we should experiment with getting rid of. Doing that right is hard because it is difficult to prevent sock-puppetry-spoofing which would require regulations and penalties for rat hole order shredding.

So order anonymity is 'easier'. But now the exchange has to deal with spoofers. Or not. but they must be explicit about their policy with regards to spoofing and rigoursly and rapidly enforce that policy. If they are not they create a syatem where some participants will break the rules to gain advantage and others will follow them and suffer. And allowing spoofing might be a violation of dodd-frank (i am not sure if this exchange implicitly falls under its scope or not) so again, some participants might feel to play it safe while others wont have such qualms.

Atleast using an order based feed makes it easier to track bogus orders which increases the difficulty for spoofers vs motivated play by the rules dont commit hundreds of felonies per day liquidity providers.

Trading ...ugh

Re: Coinbase – Exchange API

#27

Post by mrchicity »

clarkmoody wrote: post #3

After having looked at dozens of Bitcoin exchange APIs, this one was a breath of fresh air. The only other respectable API out there belongs to Kraken [1]. [1] https://www.kraken.com/help/api

Polling is an awful API for market data, especially when the poll rate is limited. People end up gaming the system with multiple accounts and getting additional "peeks" into the order book. Maybe it doesn't matter for Bitcoin but it's a bad design for a serious exchange.

Re: Coinbase – Exchange API

#28

Post by benjaminjackman »

mrchicity wrote: post #25
minimax wrote: post #22

(Thoughts from someone who works in this space) Exposing _all_ order entry traffic on the public market data feed is not great, especially the part where they expose client generated order uuids on the public feed. This allows market participants to potentially identify other market participants' orders based on their client order uuids e.g. if they are using a uuid generator that incorporates the MAC address. I thin…

Also if they're charging 25 bps to be a taker vs. 0 to make, people will want a post-only order. I actually like the idea of putting ClOrdIDs on the feed, maybe encrypted with some key only the sender has? Would make excluding one's own orders so much easier and no concerns about who sees what first: http://www.wsj.com/articles/SB100014241278873237981045784550...

Another option is to include the pricefeed order id in the order submit ack message sent on the order channel to the submitter.

Re: Coinbase – Exchange API

#30

Post by kordless »

tlrobinson wrote: post #10
Animats wrote: post #8

Looks straightforward enough. They note that your trading 'bots should be running on Amazon AWS East for minimum latency. They're encouraging high frequency trading. Since they're coming up with zero fees, they may have huge 'bot volume. Then they can announce they are the biggest exchange.

Heh, you could imagine Bitcoin HFT shops spinning up EC2 instances until they happen to get one close to Coinbase's. (I don't know AWS networking well enough to know if this would make much of a difference, or even if the overhead of the HTTP API wouldn't make the difference negligible)

> could imagine

I imagine they are already thinking about it. Affinity and HFT go hand in hand.

Post reply on HN