API fail part II: BTC-E faceplant

[2112]

I was absolutely floored when I found out that $100 million MBS trades are done by voice telephone call.

Now, the call is recorded, but still… no crypto, nothing.  Yow.

Just for the historical explanation purposes:

For the telephone trading the primary line of defense is ANI:

http://en.wikipedia.org/wiki/Automatic_number_identification

Straight ANI is often strenghtened by either quick comparison with real time billing information or various SS7 tracing/call maintenance features.

http://en.wikipedia.org/wiki/Signalling_System_No._7

While pikers trade with touch-tones the whales get service of the dedicated VIP staff. It is a form of biometric authentication, people employed in high-value account service have extraordinary auditory  memory (or visual memory, for the in-person service).

[1715000215]

1715000215

[1715000215]

1715000215

[1715000215]

1715000215

[2112]

I thought the same thing!  Then I started learning about FIX.  Unfortunately, it's a disaster.

Worst case of design-by-committee I've ever seen.  More of a trainwreck than all the XML standards rolled into one.

I think the meta-problem here is that FIX was created by the big Wall Street firms, and for them hiring ten programmers instead of one to implement some needlessly-overcomplicated protocol is no big deal.  In fact, the IT managers kinda like this because it increases the size of their fiefdom.  So, sadly, pre-bitcoin the organizations in a position to standardize this kind of thing also had an incentive to make it as complicated as possible.

In principle I'm in favor of standardization, but if an API is designed well it should really only take you 2-4 hours to write a plugin for it.  I guess that's part of the reason why I'm so prone to rant about crappy APIs.  If the exchange does a good job, the fact that there's no standard isn't really that much of a big deal.

I think you forgot to consider "quality of design" versus "quality of implementation" dichotomy. You also completely neglected "cost of initial implementation" versus "cost of ongoing maintenance". FIX maybe like a camel: a horse designed by a commitee. But it has some of the best and most reliable implementations.

I wish that hiring one smart programmer would always guarantee a good solution. But I'm emphatically absolutely positively sure that this isn't a case. Your LiMP design is nice, lean and mean. But for comparison take a bitfury's proposal of mining protocol, where he had made completely newbie mistakes:

https://bitcointalk.org/index.php?topic=84791.0

I actually have an extensive experience in deploying and maintaining SOA (Service Oriented Architecture). We've been in a good position to be able to charge per-request and per-error, and our TOS contract has special provision to deal with people who believe that "if an API is designed well it should really only take you 2-4 hours to write a plugin for it." Both salespeople and tech support people are trained to recognize them as problem customers and charge/treat them appropriately.

I posted about this earlier in slush's thread about Stratum:

https://bitcointalk.org/index.php?topic=55842.msg664479#msg664479

Anyway, I was going to post links to a quite well designed trading protocol that is easier to implement than FIX. But Interactive Brokers are now require to have a properly funded production acount before they let you play with their API with a "paper trading" account. You may still want to review the freely available demos and documentation.

I just post one quote from the "IB gateway" (technically the better term would be "IB proxy") I find crucial:

Must remain running to maintain access to IB trading system.      Yes      Yes     

[2112]

Anyway, given the interest Mr. P wrote out the specification a little, for this thing provisionally called BTC-UXP. All comments more than welcome.

I did a quick look&see. It doesn't seem to have the protection against placing duplicate orders in case of transport failure/timeout. At the minimum all the imperative verb calls should have an OrderID argument that needs to be unique.

There may be some sort of replay attack made out the above flaw, but I don't have a motivation to delve deeper.

[MPOE-PR]

It is a form of biometric authentication, people employed in high-value account service have extraordinary auditory  memory (or visual memory, for the in-person service).

In other words, a wizard does it?

Anyway, given the interest Mr. P wrote out the specification a little, for this thing provisionally called BTC-UXP. All comments more than welcome.

I did a quick look&see. It doesn't seem to have the protection against placing duplicate orders in case of transport failure/timeout. At the minimum all the imperative verb calls should have an OrderID argument that needs to be unique.

There may be some sort of replay attack made out the above flaw, but I don't have a motivation to delve deeper.

That part's intentionally left blank.

If the exchange implements by-connection security (cookie based/https website logins are of this sort) then all orders are valid even if duplicate. If the exchange implements stateless by-payload security (such as the GPG scheme MPEx uses) then the exchange should also enforce unique-payload (either through hashing or some other method).

In either case these are considerations of exchange security, NOT of communication protocol. At least that's the thinking.

[2112]

If the exchange implements stateless by-payload security (such as the GPG scheme MPEx uses) then the exchange should also enforce unique-payload (either through hashing or some other method).

Hopefully to actually take the duplicate order you require at least a different IV (initialization vector) in the GPG armor and it is not sufficient to
simply reformat the armored message.

I personally don't like the houses where accepting duplicate(or otherwise confused) orders are part of the business plan. It always ends in litigation when somebody's cat steps on the keyboard and cleans the account.

With the volume and frequency so low I'm inclined to think that the connection-less protocol is not a problem. It will be if the frequency of trades rises.

In other words, a wizard does it?

I should've probably written "freakish" not just "extraordinary". It is more like a Rainman than a wizard.

[MPOE-PR]

MPEx uses a double layer: to talk to it you first clearsign then the resulting pgp message you encrypt (per FAQ). In order to duplicate you would have to re-sign the order somehow.

I personally don't like the houses where accepting duplicate(or otherwise confused) orders are part of the business plan. It always ends in litigation when somebody's cat steps on the keyboard and cleans the account.

Mr. P is of the same persuasion, hence MPEx working the way it does. Still, by-connection is probably a perfectly legitimate way to do things, in some cases (which almost never are the cases where it's applied in BTCWorld, but anyway).

With the volume and frequency so low I'm inclined to think that the connection-less protocol is not a problem. It will be if the frequency of trades rises.

Care to elaborate? Seems exactly the opposite would be true.

[2112]

Care to elaborate? Seems exactly the opposite would be true.

With connection-less trading a sudden trading spike is indistinguishable from a DDoS attack.

Because setting up and tearing down TCP/IP connection involves several small packets you will learn that your networking infrastructure has two limits: bps (bits per second) and pps (packets per second) and you will be governed by the pps limit (while staying far away from bps limit) during the most important periods of the trading. The connection failure rates will greatly increase, this will be visible on your side as storms of inquisitive verbs (STAT, STATJSON, etc.) The quote/status dissemination during an active trading is just so much more efficient with the stream-oriented protocols that there isn't much room for discussion when comparing it with RPC-style polling.

In addition to the above "ideal world" failure mode, in a "real world" case when somebody actually tries to DDoS you you can mount the defenses much cheaper and much more efficiently if you'll require keeping up the connection while trading.

Socially, I find this RPC-trading phenomenon puzzling. The very same people who obsessively tune their gaming rigs for minimum lag suddenly are fine with the lag values several orders of magnitude higher when trading for real money instead of playing for toy money.

[MPOE-PR]

Care to elaborate? Seems exactly the opposite would be true.

With connection-less trading a sudden trading spike is indistinguishable from a DDoS attack.

Because setting up and tearing down TCP/IP connection involves several small packets you will learn that your networking infrastructure has two limits: bps (bits per second) and pps (packets per second) and you will be governed by the pps limit (while staying far away from bps limit) during the most important periods of the trading. The connection failure rates will greatly increase, this will be visible on your side as storms of inquisitive verbs (STAT, STATJSON, etc.) The quote/status dissemination during an active trading is just so much more efficient with the stream-oriented protocols that there isn't much room for discussion when comparing it with RPC-style polling.

In addition to the above "ideal world" failure mode, in a "real world" case when somebody actually tries to DDoS you you can mount the defenses much cheaper and much more efficiently if you'll require keeping up the connection while trading.

Socially, I find this RPC-trading phenomenon puzzling. The very same people who obsessively tune their gaming rigs for minimum lag suddenly are fine with the lag values several orders of magnitude higher when trading for real money instead of playing for toy money.

Well, I think the problem is the vast pile of conjecture you're fighting with.

[J-Norm]

The best way to create an API is to FIRST write the documentation. Then once you see that what you are documenting makes sense you then implement each feature that is documented.

That way not only do you have a fully documented API but you also see if what you are designing actually makes sense.

If you program it first and then document it you will run into all sorts of design issues and end up lacking documentation.

[MPOE-PR]

The best way to create an API is to FIRST write the documentation. Then once you see that what you are documenting makes sense you then implement each feature that is documented.

That way not only do you have a fully documented API but you also see if what you are designing actually makes sense.

If you program it first and then document it you will run into all sorts of design issues and end up lacking documentation.

In a for-profit venture that's a little more complicated than in the FOSS world:

0. You write up your goals/principles. This is where a committee should be involved.
I. You write the spec. This is something that should be done by one single person.
II. You throw the spec around. This should be a general effort. Even the cleaning lady is allowed to throw items at the spec (provided she satisfies all applicable requirements for keeping the secret).
III. You implement the spec. This is something that should be done by a team (which is a different beast from a committee).
IV. You revise the complaints of the people implementing to try and ascertain whether it's them being lazy or them having a point. This is a committee + autarch job (as in, some points will have to be decided by means of a large stick or other implement with˙ʎɥʍ s,ʇɐɥʇ 'noʎ ʞɔnɟ ǝsnɐɔǝq etched over the business end).
V. You open a beta. Revise etcetera.
VI. You come out of beta.
VII. The general public starts to take an interest at a higher abstraction level than the simple usage of your product.
VIII. You release some version of the spec for public consumption.

We're on step VIII atm.

[daybyter]

Well from my viewpoint (as a coder implementing some API for trading):

- I usually work as a software engineer modeling applications with tools. But...

- I guess I don't have the same knowledge, that most of you seem to have about trading API's, so for me it's a bit 'learning by doing'.

- My trading app is growing slowly, and I learn step by step what a trading app needs, so my trading lib is growing with my app. That process has to do with trading sites and their restrictions. Some only deliver limited data. Others update their data only after x seconds and so on. So a perfect trade app has to consider those limitations and deal with them in some way.

Learning those problems and finding workaround leads me to some iterative development process, redesigning my code again and again. So even if I had written the specs by 100% before doing any coding, I'd still have to rework my code from time to time as I learn about those trade sites.

But seeing stuff growing and working more and more is fun and keeps me motivated to further the development. So it's ok by me...

[ElectricMucus]

I'm gonna bump this.

Been attempting to get this working for myself, but haven't had any luck either.
If anybody who got this working is available for questioning this would be greatly appreciated.

[daybyter]

I can use some of the btc-e API yet. But I'm still struggling with some features. Would be cool if I could discuss deposit and withdrawal with someone.

[kelpy]

Hi,

What's the object HttpUtils.httpPost ?
Where can i found it?!

Code:

HttpUtils.httpPost( "https://" + DOMAIN + "/tapi", headerLines, postData);

http://pastebin.com/jyd9tACF

I just try with HttpURLConnection with no result.

Thanks in advance.

[daybyter]

http://pastebin.com/rBKRQvrG

[kelpy]

http://pastebin.com/rBKRQvrG

Thanks

[ElectricMucus]

In case anybody here is interested in implementing the interface yourself (that is not copying other peoples code  )

You have to copy the UTF-8 runes of the 'Secret' into a byte array. !Not! convert the hexadecimal string into a number.