Bitcoin Forum
July 28, 2017, 07:09:26 PM *
News: BIP91 seems stable: there's probably only slightly increased risk of confirmations disappearing. You should still prepare for Aug 1.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 [77] 78 79 80 81 82 »
  Print  
Author Topic: www.BITSTAMP.net Bitcoin exchange site for USD/BTC  (Read 216446 times)
Rampion
Legendary
*
Offline Offline

Activity: 1106


View Profile
January 08, 2015, 10:45:32 AM
 #1521

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.

1501268966
Hero Member
*
Offline Offline

Posts: 1501268966

View Profile Personal Message (Offline)

Ignore
1501268966
Reply with quote  #2

1501268966
Report to moderator
1501268966
Hero Member
*
Offline Offline

Posts: 1501268966

View Profile Personal Message (Offline)

Ignore
1501268966
Reply with quote  #2

1501268966
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1501268966
Hero Member
*
Offline Offline

Posts: 1501268966

View Profile Personal Message (Offline)

Ignore
1501268966
Reply with quote  #2

1501268966
Report to moderator
spin
Sr. Member
****
Offline Offline

Activity: 358


View Profile
January 08, 2015, 10:51:03 AM
 #1522

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. 

If you liked this post buy me a beer.  Beers are quite cheap where I live!
194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL
Rampion
Legendary
*
Offline Offline

Activity: 1106


View Profile
January 08, 2015, 10:52:10 AM
 #1523

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.

oda.krell
Legendary
*
Offline Offline

Activity: 1316



View Profile
January 08, 2015, 11:09:35 AM
 #1524

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).

Not sure which Bitcoin wallet to use? I suggest to take a look at Electrum.
Electrum is an open-source lightweight client: user friendly, fast, and one of the safest ways to store, send or receive bitcoins.
For executables (Windows, OSX, Linux, Android), source code and documentation, see the Electrum homepage.
Rampion
Legendary
*
Offline Offline

Activity: 1106


View Profile
January 08, 2015, 11:18:06 AM
 #1525

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.

bernard75
Legendary
*
Offline Offline

Activity: 1092



View Profile
January 08, 2015, 01:27:38 PM
 #1526

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

Activity: 1288



View Profile
January 09, 2015, 06:19:23 PM
 #1527

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

Looking to launder your loot dipshit?

GAWSOME class action
(Homero Garza throws Stuart Fraser under the bus)
ION: XPY successor
                 Make sure to read

                 BitcoinTalk rules
          /s
SpanishSoldier
Sr. Member
****
Offline Offline

Activity: 392


View Profile
January 09, 2015, 06:22:10 PM
 #1528

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.
qxzn
Hero Member
*****
Offline Offline

Activity: 603



View Profile
January 09, 2015, 08:06:24 PM
 #1529

Site is back up, but order placement is not working, orders getting queued indefinitely
xybersurfer
Member
**
Offline Offline

Activity: 61


View Profile
January 10, 2015, 08:41:41 PM
 #1530

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
*****
Offline Offline

Activity: 603



View Profile
January 12, 2015, 07:59:13 PM
 #1531

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.
qxzn
Hero Member
*****
Offline Offline

Activity: 603



View Profile
January 12, 2015, 08:03:22 PM
 #1532

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
*****
Offline Offline

Activity: 603



View Profile
January 12, 2015, 08:54:06 PM
 #1533

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.
xybersurfer
Member
**
Offline Offline

Activity: 61


View Profile
January 13, 2015, 03:57:54 AM
 #1534

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).
MusX
Full Member
***
Offline Offline

Activity: 175


View Profile
January 19, 2015, 02:28:33 PM
 #1535

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.

oda.krell
Legendary
*
Offline Offline

Activity: 1316



View Profile
January 19, 2015, 03:18:18 PM
 #1536

@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.

Not sure which Bitcoin wallet to use? I suggest to take a look at Electrum.
Electrum is an open-source lightweight client: user friendly, fast, and one of the safest ways to store, send or receive bitcoins.
For executables (Windows, OSX, Linux, Android), source code and documentation, see the Electrum homepage.
spin
Sr. Member
****
Offline Offline

Activity: 358


View Profile
January 23, 2015, 07:53:48 AM
 #1537

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?

If you liked this post buy me a beer.  Beers are quite cheap where I live!
194YjsiwmGm3hcbPcJWWyzRAS9CQLX1fJL
smoothie
Legendary
*
Offline Offline

Activity: 2044


LEALANA Monero Physical Silver Coins


View Profile
January 23, 2015, 07:56:30 AM
 #1538

A full blown audit needs to be done on bitstamp.

Wouldn't use it otherwise.

███████████████████████████████████████

            ,╓p@@███████@╗╖,           
        ,p████████████████████N,       
      d█████████████████████████b     
    d██████████████████████████████æ   
  ,████²█████████████████████████████, 
 ,█████  ╙████████████████████╨  █████y
 ██████    `████████████████`    ██████
║██████       Ñ███████████`      ███████
███████         ╩██████Ñ         ███████
███████    ▐▄     ²██╩     a▌    ███████
╢██████    ▐▓█▄          ▄█▓▌    ███████
 ██████    ▐▓▓▓▓▌,     ▄█▓▓▓▌    ██████─
           ▐▓▓▓▓▓▓█,,▄▓▓▓▓▓▓▌          
           ▐▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▌          
    ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓─  
     ²▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓╩    
        ▀▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▀       
           ²▀▀▓▓▓▓▓▓▓▓▓▓▓▓▀▀`          
                   ²²²                 
███████████████████████████████████████

. ★☆ WWW.LEALANA.COM        My PGP fingerprint is A764D833.        SMOOTHIE'S HEALTH AND FITNESS JOURNAL          History of Monero development Visualization ★☆ .
LEALANA  PHYSICAL MONERO COINS 999 FINE SILVER.
 
oda.krell
Legendary
*
Offline Offline

Activity: 1316



View Profile
January 23, 2015, 11:58:49 AM
 #1539

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).

Not sure which Bitcoin wallet to use? I suggest to take a look at Electrum.
Electrum is an open-source lightweight client: user friendly, fast, and one of the safest ways to store, send or receive bitcoins.
For executables (Windows, OSX, Linux, Android), source code and documentation, see the Electrum homepage.
mmitech
Legendary
*
Offline Offline

Activity: 1092


things you own end up owning you


View Profile
January 23, 2015, 02:12:06 PM
 #1540

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
Pages: « 1 ... 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 [77] 78 79 80 81 82 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!