Topic: Bitoption.org API Discussion (Read 6575 times)

LOL, not quite what I was going for. Just something to help my coding through the future changes.

TOTALLY. Let me think about how to implement.

This is a very polite way to say "why the fuck is everything broken right now??" by the way.

Could we get a version number for the API and a way to retrieve it?

You can and should always ask about security! No worries. Keep the questions coming.

Security sounds good. I actually realized I had no real reason to question it, but better safe than sorry. Odd that the mt gox hack stuff is going down right after I asked about your site. I guess I should have been asking about theirs.

I have some low buy offers in; I'm curious how they'll deal with those. Sounds like we will have a 'go back in time' moment.

Here's how password security on bitoption works:

1) We take your password via an SSL-only POST request.  (This used to be a GET request before we turned on the anti-CSRF functionality. POST is marginally more secure; some logs will log the entire URL, so there was a chance of leakage that way, but it would only be at the endpoints of the request.) As it is, this is now encrypted end to end.

2) We have a sitewide secret salt that is used in all hashes

3) We have a per-account 'nonce' that is used to salt the password.

4) We store only the sha-256 hash of the password,secret,and nonce.

As far as I know, the combination of 3 and 4 is industry best practices for one factor authentication; it means that a rainbow attack is computationally difficult, in that each rainbow table is only effective for one account.

Happy to take further suggestions.

Someone just made a fortune buying 10,000 bitcoins at $0.01 a piece and it wasn't me!!!

Looking at the API, I was a little concerned by the fact that we are sending passwords in plaintext, and not a hash. I know we are using https, but I do hope that the passwords are not being stored in plaintext? A salted hash is best security practice for storing passwords. A random salt for each user, perhaps generated from their username is best, so that a brute force attack can't be used against everyone at once..

Major update for API Developers:

We have moved to using posts for many API requests. I'll update here when I've had a break. Read our main thread for information about CSRF vulnerability cuddlefish pointed out to us today.

I think you may at times want to send a bunch of bulk updates, like "I've got bids and asks in on these dates at these strikes, for this strike and date, update / reset all my bids and asks." This bears a little more consideration, I think. Let's start with the first two and see what needs we have.

Sounds good. Yeah, I thought that the stop loss system would lead to a whole bunch of problem. I suppose one can assume their bot will handle it.

I'm not sure I followed where you are going with updateAllStrikeBids. Is the idea to push all of your bids up or down a little. I admit that might be useful, depending on the final implementation of the bot.

And updateAllDateStrikeAsks, is there a reason that has a "date" in the name while the other doesn't? I'm still not completely familiar with the API so I might be missing the obvious.

PS you should have my email, I signed up with mine.

I also propose:

updateAllStrikeBids:
  strike
  underlying
  type
  date
  bidask=optional
  num=optional
  expireTime=optional

updateAllDateStrikeAsks:
  strike
  underlying
  type
  date
  bidask=optional
  num=optional
  expireTime=optional


I would anticipate even a vaguely sophisticated bot is going to tier out its bids/asks, so this second set might or might not be useful, but I want to make sure to support a sort of 'everything in this line should change' function.

OK, So let's agree on some functionality here.

There's no point in changing the strike of a bid, plus we may tie margin logic to different strike prices, so

updateBid:
  token
  bidId
  bidask(optional)
  expiredate(optional)
  cancelifbtcusdgt(optional)

updateAsk:
  token
  askId
  bidask(optional)
  expiredate(optional)
  cancelifbtcusdgt(optional)

 
Expire dates are relatively easy. Stop Loss prices have a whole bunch of problems, including (but not limited to):

. Possible manipulation some day when the options market grows
. Thin markets in down trading times
. Mt Gox websockets / order book functionality is not perfect and might miss something
. Significant database load; we're essentially queuing an update / delete on every websocket notice. This may be non-scalable.


There's also the question of what you actually do with the them once expired; I'd say they should stick around and get annotated 'canceled when blah happened.'  A good 25% of support questions are currently "what happened to my XXX?" Of those, 20% have been the market so far, the rest are people just being confused, bad interface, or memories.

The more I think about it, the more I think the bid bot should be responsible for keeping track of Gox, or Tradehill, or wherever. I'll shoot you some python websockets code that you can include in the bot for just such a purpose; I think I have your e-mail right?

There are two thing I would really like to see in the API.

First, I'd like the ability to change the bid/ask price on an open contract. It just seems cleaner than canceling and replacing, and it shouldn't be too hard to implement. This would be nice on the website too.

Second, and this one is harder, I'd like to be able to place an expiration on my open contracts. A time expiration would make me feel a lot more confidant and safer, especially if I were running a bot. If I get disconnected somehow, I know my open contracts will expire in an hour or two or whatever I set. Along with this should go a "renew" option which would let me change the expiration time.

Along the line of an expiration time, it would be nice to perhaps have an expiration price. If mt gox trades above, or below, a certain price the open contract gets canceled. This could by default be set (for asks at least) to anything that would instantly be in the money, since I'm pretty sure that no one ever wants to write a contract that is immediately in the money. This would require getting constant data from mt gox, but perhaps it could be implemented.

Update, I believe it is working now. A second typo, sorry.

Hit me up on email / google talk, we'll get it sorted.

Not yet.

That's because I'm an idiot. It's fixed, or should be.

still seeing 500 response on attempt to exercise contractId 19

Correct usage for canceling open options:



cancelOpenBid?token=&bidId=
cancelOpenAsk?token=&askId=

I incorrectly had something else here earlier.

a note on /bid and /ask:

The api documentation incorrectly states that you price them with bid= and ask=.

This has been changed to bidask= for both, simplifying things a bit.

Also up today:


listOpenContracts(token)
 you get back rows with bidId and askId among other things.
cancelOpenBid(token,bidId)
cancelOpenAsk(token,askId)

Good thoughts.

I see you improved the formatting for the history; much easier on the eyes.  You might also improve the sorting so the commission always falls after the purchase/sale; It'd be nice for writes to say 'sell.'  Just some eye candy ideas.

I'm fielding a good number of requests, comments and questions from API developers at bitoption.org; I thought I'd put a spot in place for them here.


To get the ball rolling; added today:

/mailResetToken?name=
/resetPassword?reset_token=&newpass=