www.BITSTAMP.net Bitcoin exchange site for USD/BTC

[bitcoinmarketmaker]

Bitstamp, very fast withdrawals, SEPA and international transfers.

I am shifting large volumes from Mt.Gox to Bitstamp, until Mt.Gox has their withdrawal speed back to reality and then I will think about moving some volume back.

[klabaki]

Nice to have:

2. The usage of different API keys instead of the full access model.

Our API security model is also being reworked.

If you modify the API anyway, could you also have a look at this?

TL;DR: I'm having troubles designing my tradebot because bitstamp API doesn't provide enough information; I'm asking for help and/or requesting this information to be provided through the API

Bitstamp allows to do JSON/HTTP-based API trading using https://www.bitstamp.net/api/function/

The tradebot that I'm about to create needs to know the current balance and the currently open orders at a synchronised(!) point in time.
The API allows to get the current balance using /api/balance/ and the currently open orders using /api/open_orders/. But this is awkward and doesn't work properly because:

- The access is not synchronized: It is possible that a trade happens just inbetween the API calls for balance/open orders, causing the returned information to be inaccurate (I've already seen losses due to this effect while testing)

- The list returned by /api/open_orders/ can be quite large; it's wasting bandwidth, which is rare at my site. (and I need to download this list quite often)

To work around these problems, I'm trying the following approach:
The bot maintains an offline list of all open orders that it has posted to the market using /api/buy/ and /api/sell/; it also keeps track of canceled orders.
The bot keeps itself up-to-date about all user transactions using /api/user_transactions/. This allows my bot to know the current balance before and after every transaction.
Now I'm trying to match the user transactions to the open orders, i.e. the bot tries to figure out what user transaction happened due to what open order.
If this matching can be done, then I'm happy because then the bot could know about open orders and balance at any point in time (i.e. before and after every transaction).

However, this matching can be quite tricky. Let me show you an example where I think it's impossible:

Code:

* The bot initializes in a clean state, i.e. without any open orders and without pending transactions
* The bot calls /api/buy/ to buy 2 BTC at 122 USD each; saving the returned order id in variable X
* The bot calls /api/buy/ to buy 2 BTC at 120 USD each; saving the returned order id in variable Y
* The bot calls /api/cancel_order/ to cancel order X, the API indicates that canceling was successful
* The bot calls /api/user_transactions/ and receives one transaction with the following information:
BTC: +1
USD: -120

Now, the tricky question is: What open orders does the bot have after this transaction??

I know about at least two possibilities:
1.: After the bot canceled order X, someone else sold 1 BTC, which partially fulfilled order Y. Consequently, after the transaction, there's one remaining open order: buy 1 BTC at 120 USD each
2.: Even before the bot posted order X, there already was someone else's order to sell 1 BTC at 120 USD each, causing order X to immediately match against it. So order X was only "buy 1 BTC at 122 USD each" while it was canceled. Consequently, after the transaction, there's one remaining order: buy 2 BTC at 120 USD each

So my bot can't know what open order caused the received transaction
This makes it impossible to maintain an offline list of all open orders posted by the bot.

It would be a lot easier to code this stuff if the user transactions returned by /api/user_transactions/ would contain an additional entry about what open order's id issued this transaction.
In the example above it would clearly indicate order id X or order id Y, allowing the bot to maintain an offline list of open orders.

Consider this post as being a feature request

The problem arises whenever a user trade happens while the bot is cancelling an order. There's a lack of information to tell whether the user transaction happened due to partial fulfillment of the cancelled order, or due to fulfillment of some other open order.

Besides the feature request above, it could also be solved if the API function to cancel an order would not only return true or false, but also the state/remaining amount of the cancelled order at the point of time when it is cancelled.

[tex83rb]

congratulation for great service, so much more efficient than mtgox

[dexX7]

If you modify the API anyway, could you also have a look at this?e/remaining amount of the cancelled order at the point of time when it is cancelled.

A nice and fast realtime streaming API would be great. I found out how to use their socket.io API some days ago, but the worst part: it's slower than the good old pulling and doesn't include timestamps.

[kakobrekla]

Our API security model is also being reworked.

How about reworking your trading engine to a less scammy one, its been over a year now.

[webr3]

A new feature was added a couple of days ago, ripple withdraws which do not arrive within 1 hour are now automatically marked as failed.

[vdragon]

Can someone write a tutorial how to transfer ripple from one account to another via bitstamp? Because its confusing

[cmp]

Is the socket.io actually working? I can't get the live_orders to work. Also, the live_trades works 1 out of 3 times. Any suggestions?

cmp

[kakobrekla]

Gox qualitat.

[dexX7]

Is the socket.io actually working? I can't get the live_orders to work. Also, the live_trades works 1 out of 3 times. Any suggestions?

cmp

I can't really help, but report my experience. live_orders connects, but never returned any anything besides the connected notification. The events 'order deleted', 'order created' and 'order changed' should deliver the data. live_trades works more or less, but sadly I had to find out, it's significantly delayed.

[klabaki]

TL;DR: I'm having troubles designing my tradebot because bitstamp API doesn't provide enough information; I'm asking for help and/or requesting this information to be provided through the API

[...]

It would be a lot easier to code this stuff if the user transactions returned by /api/user_transactions/ would contain an additional entry about what open order's id issued this transaction.
In the example above it would clearly indicate order id X or order id Y, allowing the bot to maintain an offline list of open orders.

Consider this post as being a feature request

No response from Bitstamp team

A nice and fast realtime streaming API would be great. I found out how to use their socket.io API some days ago, but the worst part: it's slower than the good old pulling and doesn't include timestamps.

How did you find that out? I can't find documentation..... Can you give me a hint?

[kakobrekla]

TL;DR: I'm having troubles designing my tradebot because bitstamp API doesn't provide enough information; I'm asking for help and/or requesting this information to be provided through the API

[...]

It would be a lot easier to code this stuff if the user transactions returned by /api/user_transactions/ would contain an additional entry about what open order's id issued this transaction.
In the example above it would clearly indicate order id X or order id Y, allowing the bot to maintain an offline list of open orders.

Consider this post as being a feature request

No response from Bitstamp team

Eh? I think we can all agree CSS has priority, no?

[klabaki]

TL;DR: I'm having troubles designing my tradebot because bitstamp API doesn't provide enough information; I'm asking for help and/or requesting this information to be provided through the API

[...]

It would be a lot easier to code this stuff if the user transactions returned by /api/user_transactions/ would contain an additional entry about what open order's id issued this transaction.
In the example above it would clearly indicate order id X or order id Y, allowing the bot to maintain an offline list of open orders.

Consider this post as being a feature request

No response from Bitstamp team

Eh? I think we can all agree CSS has priority, no?

Yes, of course, we agree.

.... so you're saying this isn't CSS?

[dexX7]

How did you find that out? I can't find documentation..... Can you give me a hint?

Sure. I looked at the source code of bitstamp.com and noticed the socket.io connection. You can alter the port from 8080-8086 I think. Depth should come with live_orders and the events 'order deleted', 'order created' and 'order changed', but I never received anything besides the connection confirmation. But as said before. It doesn't seem that reliable and seems to have a delay. :/

Code:

<html>
  <head>
  </head>
  <body>
    <h2>Bitstamp Streaming API</h2>
    <div id="message">
    </div>
    <script src="https://www.bitstamp.net/s/js/socket.io/socket.io.min.js"></script>
    <script>
      var uri = 'https://websocket.bitstamp.net:8080/live_trades';
      var conn = io.connect(uri);
      conn.on('connect', function() {
        var e = document.getElementById('message');
        e.innerHTML = e.innerHTML + '<div class="message">Connected to: ' + uri + '</div>';
      });
      conn.on('trade', function(data) {
        var e = document.getElementById('message');
        e.innerHTML = e.innerHTML + '<div class="message">Trade received: ' + JSON.stringify(data) + '</div>';
      });
      conn.on('error', function(data) {
        var e = document.getElementById('message');
        e.innerHTML = e.innerHTML + '<div class="message">Error: ' + JSON.stringify(data) + '</div>';
      });
    </script>
  </body>
</html>

[klabaki]

How did you find that out? I can't find documentation..... Can you give me a hint?

Sure. I looked at the source code of bitstamp.com and noticed the socket.io connection. You can alter the port from 8080-8086 I think. Depth should come with live_orders and the events 'order deleted', 'order created' and 'order changed', but I never received anything besides the connection confirmation. But as said before. It doesn't seem that reliable and seems to have a delay. :/

Thanks a lot

I'm getting delays up to 60sec here, but it seems fine otherwise: The returned data is complete, but it's not chronological.

It looks like the trades drop in at a fixed rate, so if there are multiple trades at once (e.g. due to a large order), then the delays accumulate.

Especially appreciated: /live_trades returns the transaction ids. This allows us to sort them chronologically and get the timestamps from good old bitstamp.net/api/transactions/.

I'll dig into /live_orders later... Hopefully it's as easy as sending some init-message to trigger it.

[dexX7]

And I miss the timestamps.

I would be very thankful, if you share any new findings. 

[Drawie]

As a warning to all Bitstamp users I repeat what many have already said: Use offline wallets and secure passwords.

My Bitstamp account apparently got hacked, all the money on the accout were spent on coins and the coins were then withdrawn to an address outside Bitstamp. I tried logging in one day and the site told me that my login ID ja password didn't match and as I retrieved my password via email, I found my account cleaned.

I have no idea how someone could have found out my ID/PW combination as I store them nowhere else but in my head and I haven't clicked any fishy banners while being logged into Bitstamp or anything like that. Also my password was rather strong. Could be a database break-in?
Anyway, as I and many else have said, keep your passwords secure and your coins offline. Cost me a bit over 3k $ not to follow those guide lines.

Ps. To the hacker if you're reading this, I hope you die a long painful death of cancer What you are doing is f'king cheap and I feel nothing but deep pity towards you. Now go catch a cancer.

[bernard75]

This wouldnt have happened with email confirmation.
At least not that easily.

[Drawie]

This wouldnt have happened with email confirmation.
At least not that easily.

As default, I thought I had all three e-mail confirmantions on. I haven't touched them ever and they were all on when I checked my security settings. Im clueless how the low-life could have gotten the coins out of Bitstamp so easily.

[dexX7]

And 2FA.

I suggest you sanitize your system and when you're sure, you're clean, change every credentials you have. Mind to share some intel? IP, withdrawal address etc.? I can't do anything specific, but I'd say it's good anyway, to have that data available..

Hope your loss wasn't that big. :/

Edit: is your API access enabled? (Account - Settings - at the bottom)