Pages:
Author

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

legendary
Activity: 1148
Merit: 1001
things you own end up owning you
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...

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
legendary
Activity: 1470
Merit: 1007
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...

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).
legendary
Activity: 2492
Merit: 1473
LEALANA Bitcoin Grim Reaper
A full blown audit needs to be done on bitstamp.

Wouldn't use it otherwise.
sr. member
Activity: 362
Merit: 262
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 Smiley

Anyway it just causes hassles and it doesn't seem right.  Can anyone confirm if they see the same issue?
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.
full member
Activity: 175
Merit: 100
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.
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)

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).
hero member
Activity: 609
Merit: 505
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.
hero member
Activity: 609
Merit: 505
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.
hero member
Activity: 609
Merit: 505
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.
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)
hero member
Activity: 609
Merit: 505
Site is back up, but order placement is not working, orders getting queued indefinitely
sr. member
Activity: 728
Merit: 256
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.
legendary
Activity: 3654
Merit: 8909
https://bpip.org
So, what's a good exchange to trade on nowdays?

Looking to launder your loot dipshit?
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.
legendary
Activity: 1148
Merit: 1018
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.
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).
legendary
Activity: 1148
Merit: 1018
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.
sr. member
Activity: 362
Merit: 262
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. 
legendary
Activity: 1148
Merit: 1018
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.
Pages:
Jump to: