I do arbitrage trading, so I regularly transfer coins all over the place.  No way I could tell which addresses were for CryptoXChange with any reliability.

I do have detailed e-mail records of all my trades (hundreds, probably thousands) there from my trading bot though (date/time, amount of trade, BTC/USD balance at the time).

Pretty big gap there between 1 and 10 million.  I imagine most people would fall somewhere in between.

- 5758 USD + 250 AUD + 0.25 BTC
- No idea
- 12/6 (was trying to set up a bank account so I could actually make a withdrawal)
- 0

If someone local intends to pursue them in court, I'd be happy to talk about assigning my debt for some percentage of what is recovered.

Nothing.  At this point I'm assuming my money there is lost.

I sent my docs over to them a couple weeks ago and had no problems.  Got a confirmation e-mail from them as well that they had received my docs.

He's talking about 256 bit AES keys here, not Public/Private key pairs.  Asymmetric keys are weaker than AES keys in general (which is why they need to be much larger).  I'm not familiar enough with ECDSA though to make a judgement about key strength for bitcoin key pairs in particular.

I don't get it.  Which "posts from yesterday"? 

Yup, they owe me about $5,900 and I've had no communication on my recent support tickets or any hint that I'll ever be getting my money back. 

Funny, I withdrew $3,000 yesterday to Dwolla and got the money the same day.  Ditto on (I believe) the 18th.  Was actually quite surprised as I'm used to waiting several days.

You might be surprised.  Spend a little time looking over questions in the PHP tag on StackOverflow.com and you'll see way too many devs who are completely ignorant about SQL injection

I've had several bots trading on the same account without much trouble - you just have to track externally (in a database or whatever) which trades go with each bot.

The fun thing is when your bots trade with each other on the same account (can happen occasionally, even with well designed bots if they have different objectives).  Gox seems to handle that just fine, but other exchanges have been a mixed bag.

Interesting to see Chris Larsen involved with this.  Ever since I first heard about Bitcoin I thought it would be something that would be right up his alley.  Gavin and I were also both very early adopters of his Prosper.com platform as well.

I believe "Ecliptic Curve DSA" should be "Elliptic Curve DSA"

To add a bit to this, I e-mailed Taslim as well and got a response back from him today. 

I specifically asked if they had any information from the original claims process that Bitcoinica set up previously, and he replied that they do not.  So even if you submitted a claim previously through Bitcoinica, you will almost certainly need to re-submit your claim along with supporting information through the liquidator.

And much of that is probably completely unenforceable in court.  Considering they are actually based in the US, at least you have a reasonable chance of taking them to court should try to actually enforce any of those terms (unlike many other exchange operators that are not based in the US).

I've been reading slashdot forever (have a 5 digit UID) and I agree with you there.  I still enjoy the site, but seems like the crowd there is a lot less techy than it used to be.

Hmm.. I'll have to take a look at this, could be interesting.

Seems like just separating the website orders from orders placed via the API would probably be enough.

I realize that some orders placed through the API could be from actual humans using an alternate client, but I'd bet that volume is pretty small relative to bots and website orders.

Yes, the concept is very similar.  I've taken a quick look at OT, but not enough to really understand it yet.  I'll make sure to look at it more closely to see if it would work for what I'm trying to do here before I code anything.  But I want to make sure I have a sound idea of the requirements first though.

I've been thinking about how an exchange could handle bitcoins securely as part of a side project I'm working on. 

Using an encrypted wallet on a firewalled non-public-facing machine seems like an obvious first step.  I'm also thinking about how to secure the application itself such that even if the app server and database were rooted, an attacker with full knowledge of the system still could not exploit it in a way that would cause coins to be lost.

So, here are my initial thoughts on how this might work.  I'm sure I'm missing something here, so I'd love it if any security experts could comment on any holes that might exist in this system:

1.  The server will have a 256-bit AES key derived from a password and a salt.  This will not be stored anywhere in the system.
   a. Password will need to be provided at application startup to "bootstrap" the app and generate the key.

2.  The server will have a 2048-bit RSA key that it will use to sign transactions in the system.
   a. The public key will be stored as plain text in a config file.
   b. The private key will be stored encrypted in a config file using the server AES key.

3.  Each user will have a 256-bit AES key derived from their password and a salt.  This will not be stored anywhere in the system.
   a. Note that this will change every time they change or reset their password.

4.  Each user will have a 2048-bit RSA key associated with their account and stored in the database.
   a. The public key will be stored in the database as plain text.
   b. The private key will be stored in the database encrypted using the user's AES key.
   c. When a user's password is changed or reset, a new RSA key will be created for the user.
      i. The old RSA key will remain valid for transactions created before the date the new key was created.  This is to ensure that in-process
         transactions (orders, withdrawals, etc.) that were signed with the old key can still be processed.
   d. The association of a key to a user will be digitally signed by the server (hash of userid + encrypted private key + public key + timestamp).
      i.  This is to prevent a user with database access from tampering with a key or associating their own key to another user
          in order to fake a signed transaction from that user.

5.  A user will be able to submit a signed bitcoin withdrawal request.
   a.  The request will be signed with the user's private key hash of (id + userid + amount + to address + timestamp)
      i.  By itself, this is vulnerable to replay attacks.  See 6(b) for solution to mitigate this risk.

6.  Requests will actually be processed by another app + bitcoind running on a separate firewalled machine with all incoming ports blocked and access only via console.
   a.  Before processing a request, the app will validate the request signature.
      i.   Calculated hash of (id + userid + amount + to address + timestamp) in request matches signed hash.
      ii.  Key used to sign the request actually belongs to the user associated with the request.
      iii. Key used to sign the request was valid as of the timestamp on the request.

   b.  The processing app will keep a separate local database with the ids of all processed transactions. 
      i.   Before processing a transaction, it will first verify that the transaction was not already processed. 
      ii.  If it was, the transaction will be rejected.  This is to protect against replay attacks.

So that covers withdrawals.  Other transactions (orders, trades, deposits, any other transactions that manipulate account balances) would be handled in a similar fashion with transactions either signed by the user submitting them or signed by the server itself.  The idea is that the server should always be able to provably audit transactions and account balances to ensure they have not been manipulated (even if a hacker had compromised the database itself)