www.BITSTAMP.net Bitcoin exchange site for USD/BTC - page 8.

mmitech

legendary

Activity: 1148

Merit: 1001

things you own end up owning you

Quote from: oda.krell on January 23, 2015, 07:58:49 AM

Quote from: smoothie on January 23, 2015, 03:56:30 AM

A full blown audit needs to be done on bitstamp.

Wouldn't use it otherwise.

Which ties in with my own request from a few days ago...

Quote from: oda.krell on January 19, 2015, 11:18:18 AM

When can we expect the next financial audit of Bitstamp's customer deposits?

The last one was almost a year ago (March 2014). Back then, the plan was to do them quarter yearly. That didn't happen unfortunately.

In my opinion, after the recent hot wallet hack, it would seem like an extremely good idea to announce, and then undergo another audit of your exchange, to reassure your customers, and the crypto market in general.

As a long-term customer of Bitstamp, I'd really appreciate an answer from someone in charge to this simple question:

Do you have an ETA for the next financial audit? (That were once promised to be held quarter yearly).

I would also like to know if they are still solvent (by performing an audit from a trusted third party and publishing the results), I don't have any funds in the exchange for now, but I wont send any funds if an audit is not performed ASAP...at this point I personally think that the risk of leaving funds or trading at Bitstamp has become equal or even higher than trading at BTC-e.

Edit: once before the hack happened, the CEO (Nejc kodrič) said that they have a reserve fund to cover the whole hot wallet funds in case they had a problem with it (hackd, lost, technical issues...), but I personally don't think that they had 19000 BTC sitting around just in case... I can imagine 500-3000 BTC but not 19000 BTC

oda.krell

legendary

Activity: 1470

Merit: 1007

Quote from: smoothie on January 23, 2015, 03:56:30 AM

A full blown audit needs to be done on bitstamp.

Wouldn't use it otherwise.

Which ties in with my own request from a few days ago...

Quote from: oda.krell on January 19, 2015, 11:18:18 AM

When can we expect the next financial audit of Bitstamp's customer deposits?

The last one was almost a year ago (March 2014). Back then, the plan was to do them quarter yearly. That didn't happen unfortunately.

In my opinion, after the recent hot wallet hack, it would seem like an extremely good idea to announce, and then undergo another audit of your exchange, to reassure your customers, and the crypto market in general.

As a long-term customer of Bitstamp, I'd really appreciate an answer from someone in charge to this simple question:

Do you have an ETA for the next financial audit? (That were once promised to be held quarter yearly).

smoothie

legendary

Activity: 2492

Merit: 1473

LEALANA Bitcoin Grim Reaper

A full blown audit needs to be done on bitstamp.

Wouldn't use it otherwise.

spin

sr. member

Activity: 362

Merit: 261

Been experiencing problems with the new site but nobody's helping:

I'm pretty sure they have a floating point rounding issue in the withdrawal API somewhere.

I withdrew BTC0.29 the other day using API. And it shows as 0.29 in my withdrawal list etc. But the tx in the blockchain goes only for 0.28999999.

Talk about nickel-and-diming

Anyway it just causes hassles and it doesn't seem right. Can anyone confirm if they see the same issue?

oda.krell

legendary

Activity: 1470

Merit: 1007

@hazek

When can we expect the next financial audit of Bitstamp's customer deposits?

The last one was almost a year ago (March 2014). Back then, the plan was to do them quarter yearly. That didn't happen unfortunately.

In my opinion, after the recent hot wallet hack, it would seem like an extremely good idea to announce, and then undergo another audit of your exchange, to reassure your customers, and the crypto market in general.

MusX

full member

Activity: 175

Merit: 100

Quote from: xybersurfer on January 12, 2015, 11:57:54 PM

Quote from: qxzn on January 12, 2015, 04:54:06 PM

Quote from: qxzn on January 12, 2015, 04:03:22 PM

Quote from: qxzn on January 12, 2015, 03:59:13 PM

Quote from: xybersurfer on January 10, 2015, 04:41:41 PM

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

There seems to be some real issues with transactions at the moment. We are seeing subsequent pulls give us different versions of history. For example, I pull the history once and get a large set of trades, then I pull again and I'm missing just two trades from somewhere in the middle of the set. A third pull and the trades are back again. I'm opening a ticket but I think Bitstamp should look at this ASAP.

Actually, this might be my mistake. Will update here as soon as I know.

Yeah, this was a mistake in our code. From what I can tell, bitstamp transaction data is OK, though there have been a few subtle changes in the ordering of records returned.

it hasn't happened again since i posted here. but i'm pretty sure it's not a problem in my code. because when it happens, i log the data that i already have and the data returned from the API call. and it's really easy to see that the data i already have is newer (which should never be the case).

i also noticed an issue of missing trades between the list of trades for the last hour and the list for the last minute. here the hour list lags behind the minute list. and at times a trade is no longer in the minute list but also not in the hour list yet. so i just use the hour list now. so i use a little more bandwidth (but i consider this a minor issue).

I would advice to built a additional data integrity validation layer when operating on bitstamp historical trades API. Since October 2013 bitstamp does not allow to keep data integrity due to removed `since` / `offset` param from trades API method. Be aware that sourcing bitstamp trades data from external sites like bitcoincharts.com might be also affected by lack of data integrity feature on bitstamp.

xybersurfer

member

Activity: 72

Merit: 10

Quote from: qxzn on January 12, 2015, 04:54:06 PM

Quote from: qxzn on January 12, 2015, 04:03:22 PM

Quote from: qxzn on January 12, 2015, 03:59:13 PM

Quote from: xybersurfer on January 10, 2015, 04:41:41 PM

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

There seems to be some real issues with transactions at the moment. We are seeing subsequent pulls give us different versions of history. For example, I pull the history once and get a large set of trades, then I pull again and I'm missing just two trades from somewhere in the middle of the set. A third pull and the trades are back again. I'm opening a ticket but I think Bitstamp should look at this ASAP.

Actually, this might be my mistake. Will update here as soon as I know.

Yeah, this was a mistake in our code. From what I can tell, bitstamp transaction data is OK, though there have been a few subtle changes in the ordering of records returned.

it hasn't happened again since i posted here. but i'm pretty sure it's not a problem in my code. because when it happens, i log the data that i already have and the data returned from the API call. and it's really easy to see that the data i already have is newer (which should never be the case).

i also noticed an issue of missing trades between the list of trades for the last hour and the list for the last minute. here the hour list lags behind the minute list. and at times a trade is no longer in the minute list but also not in the hour list yet. so i just use the hour list now. so i use a little more bandwidth (but i consider this a minor issue).

qxzn

hero member

Activity: 609

Merit: 505

Quote from: qxzn on January 12, 2015, 04:03:22 PM

Quote from: qxzn on January 12, 2015, 03:59:13 PM

Quote from: xybersurfer on January 10, 2015, 04:41:41 PM

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

There seems to be some real issues with transactions at the moment. We are seeing subsequent pulls give us different versions of history. For example, I pull the history once and get a large set of trades, then I pull again and I'm missing just two trades from somewhere in the middle of the set. A third pull and the trades are back again. I'm opening a ticket but I think Bitstamp should look at this ASAP.

Actually, this might be my mistake. Will update here as soon as I know.

Yeah, this was a mistake in our code. From what I can tell, bitstamp transaction data is OK, though there have been a few subtle changes in the ordering of records returned.

qxzn

hero member

Activity: 609

Merit: 505

Quote from: qxzn on January 12, 2015, 03:59:13 PM

Quote from: xybersurfer on January 10, 2015, 04:41:41 PM

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

There seems to be some real issues with transactions at the moment. We are seeing subsequent pulls give us different versions of history. For example, I pull the history once and get a large set of trades, then I pull again and I'm missing just two trades from somewhere in the middle of the set. A third pull and the trades are back again. I'm opening a ticket but I think Bitstamp should look at this ASAP.

Actually, this might be my mistake. Will update here as soon as I know.

qxzn

hero member

Activity: 609

Merit: 505

Quote from: xybersurfer on January 10, 2015, 04:41:41 PM

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

There seems to be some real issues with transactions at the moment. We are seeing subsequent pulls give us different versions of history. For example, I pull the history once and get a large set of trades, then I pull again and I'm missing just two trades from somewhere in the middle of the set. A third pull and the trades are back again. I'm opening a ticket but I think Bitstamp should look at this ASAP.

xybersurfer

member

Activity: 72

Merit: 10

first of all. good job getting the site backup and running (didn't realize that Nejc Kodric runs Bitstamp)

i've noticed an issues with the Transactions API call (https://www.bitstamp.net/api/transactions/?time=hour)
sometimes a call returns transactions that are older than those in a previous call.

today with this call, i first received:
[{"date": "1420896736", "tid": 7102104, "price": "274.11", "amount": "2.00000000"}, ...]

and in a next call, i received:
[{"date": "1420896324", "tid": 7101926, "price": "276.06", "amount": "4.49916597"}, ...]

i left out irrelevant parts of the lists (with "...").
but clearly date 1420896324 is supposed to come before 1420896736

(i'm not sure whether this is the right place to report this issue)

qxzn

hero member

Activity: 609

Merit: 505

Site is back up, but order placement is not working, orders getting queued indefinitely

SpanishSoldier

sr. member

Activity: 686

Merit: 255

Quote from: suchmoon on January 09, 2015, 02:19:23 PM

Quote from: hashie on January 08, 2015, 05:59:20 AM

So, what's a good exchange to trade on nowdays?

Looking to launder your loot dipshit?

I wish their deposited coins get locked at Bitstamp.

suchmoon

legendary

Activity: 3654

Merit: 8909

https://bpip.org

Quote from: hashie on January 08, 2015, 05:59:20 AM

So, what's a good exchange to trade on nowdays?

Looking to launder your loot dipshit?

bernard75

legendary

Activity: 1316

Merit: 1003

Call me an optonist, but theyv been upfront with it and im sure they can cover it from their reserves.

Rampion

legendary

Activity: 1148

Merit: 1018

Quote from: oda.krell on January 08, 2015, 07:09:35 AM

Solid analysis of the hack, Rampion.

The 'warm wallet' architecture outlined here should be a way to decrease the likelihood of this type of attack (assuming it played out as described above).

Egor is a boss - the solution he proposes is indeed a good one. The fact is that Bitstamp operation was not very sophisticated. They should improve now.

oda.krell

legendary

Activity: 1470

Merit: 1007

Solid analysis of the hack, Rampion.

The 'warm wallet' architecture outlined here should be a way to decrease the likelihood of this type of attack (assuming it played out as described above).

Rampion

legendary

Activity: 1148

Merit: 1018

Quote from: spin on January 08, 2015, 06:51:03 AM

Quote from: Rampion on January 08, 2015, 06:45:32 AM

Quote from: spin on January 08, 2015, 06:42:38 AM

An alternative theory to the above:

I am not sure what bistamp realised and when but regular withdrawals were blocked quite soon after things started. I.e. I submitted a withdrawal request only a couple of hours after the first hack transaction. It was about 4-5am UTC on 4 Jan. That withdrawal remained pending until that evening and was never processed. Usually it's quite quick to process.

So something stopped allowing withdrawals soon after the hack started. Unfortunately the thief was able to continue taking funds because he was presumably using some other vector that did not need the regular withdrawal. E.g. he had control of the private keys. He was (and is?) able to continue taking funds if he had private keys.

My theory is that some automated control system picked up mismatch with what balances should be vs what they actually had and stopped withdrawals. Bitstamp management then at some point figured out what was happening. The hacker is however not blocked by this as he is using another vector (e.g. control of the keys).

It's pretty clear what stopped withdrawals. As soon as money entered the hot wallet, the hacked emptied it. So there was NO money on the hot wallet to honor withdrawals since the very first moment the hack started.

Yeah of course. I assumed that the hacker didn't have control of the full hot wallet. But if he did then that could be the simplest explanation...

I guess I'm hoping they had a control system, that checked for mismatched balances (or unauthorised tx on their wallets). And locked down withdrawals in case of an issue. It should also move funds to safe cold storage.

Occam Razor: it's much simpler to hack a full wallet just by stealing it and seizing the encryption key from the server's memory, that to discover a single private key by other means.

spin

sr. member

Activity: 362

Merit: 261

Quote from: Rampion on January 08, 2015, 06:45:32 AM

Quote from: spin on January 08, 2015, 06:42:38 AM

An alternative theory to the above:

I am not sure what bistamp realised and when but regular withdrawals were blocked quite soon after things started. I.e. I submitted a withdrawal request only a couple of hours after the first hack transaction. It was about 4-5am UTC on 4 Jan. That withdrawal remained pending until that evening and was never processed. Usually it's quite quick to process.

So something stopped allowing withdrawals soon after the hack started. Unfortunately the thief was able to continue taking funds because he was presumably using some other vector that did not need the regular withdrawal. E.g. he had control of the private keys. He was (and is?) able to continue taking funds if he had private keys.

My theory is that some automated control system picked up mismatch with what balances should be vs what they actually had and stopped withdrawals. Bitstamp management then at some point figured out what was happening. The hacker is however not blocked by this as he is using another vector (e.g. control of the keys).

It's pretty clear what stopped withdrawals. As soon as money entered the hot wallet, the hacked emptied it. So there was NO money on the hot wallet to honor withdrawals since the very first moment the hack started.

Yeah of course. I assumed that the hacker didn't have control of the full hot wallet. But if he did then that could be the simplest explanation...

I guess I'm hoping they had a control system, that checked for mismatched balances (or unauthorised tx on their wallets). And locked down withdrawals in case of an issue. It should also move funds to safe cold storage.

Rampion

legendary

Activity: 1148

Merit: 1018

Quote from: spin on January 08, 2015, 06:42:38 AM

I am not sure what bistamp realised and when but regular withdrawals were blocked quite soon after things started. I.e. I submitted a withdrawal request only a couple of hours after the first hack transaction. It was about 4-5am UTC on 4 Jan. That withdrawal remained pending until that evening and was never processed. Usually it's quite quick to process.

So something stopped allowing withdrawals soon after the hack started. Unfortunately the thief was able to continue taking funds because he was presumably using some other vector that did not need the regular withdrawal. E.g. he had control of the private keys. He was (and is?) able to continue taking funds if he had private keys.

My theory is that some automated control system picked up mismatch with what balances should be vs what they actually had and stopped withdrawals. Bitstamp management then at some point figured out what was happening. The hacker is however not blocked by this as he is using another vector (e.g. control of the keys).

It's pretty clear what stopped withdrawals. As soon as money entered the hot wallet, the hacker emptied it. So there was NO money on the hot wallet to honor withdrawals since the very first moment the hack started.

Bitstamp did not realize this on time so the hacker kept emptying the hot wallet during 24 hours - money came in from deposits, money went out to hacker's address. As soon as Bitstamp told customers "DO NOT DEPOSIT TO OLD ADDRESSES" the amount of coins stolen went down dramatically. We still had some coins stolen after Bitstamp shut down, probably from people who did not realize Bitstamp was hacked and deposited directly from the address book of their client.

If Bitstamp realized this immediately after the first 3.100 BTC theft, they would have probably saved +14k BTC.

Topic: www.BITSTAMP.net Bitcoin exchange site for USD/BTC - page 8. (Read 231171 times)