Topic: A public apology to Donald, Patrick and Amir ("Intersango guys") - page 4. (Read 8372 times)

http://blockchain.info/address/1EMLwAwseowTkDtKnEHRKrwQvzi4HShxSX

This is an address some of the stolen money was sent to

Notice the transaction amounts:

1.01100101 BTC
2.01111 BTC
3.0111 BTC
4.01100101 BTC
5.01100011 BTC
6.011101 BTC
7.001 BTC
8.01101101 BTC
9.01100001 BTC
10.01110011 BTC
11.01110011 BTC
12.001 BTC
13.011011 BTC
14.01100101 BTC
15.01100001 BTC
16.01101011 BTC
17.001 BTC
18.01110011 BTC
19.01101111 BTC
20.01101111 BTC
21.0110111 BTC

The part after the decimal point is ascii binary, and it converts to: expect mass leak soon

Also, the address starts with 1EML

Expect Mass Leak

Converter:
http://www.roubaixinteractive.com/PlayGround/Binary_Conversion/Binary_To_Text.asp

(for amounts that don't have 8 decimal places you need to add in more 0's, the 116BTC transaction is irrelevant I think)

And he ought only have hashes of passwords.

Link me to more detail on the "EXPECT MASS LEAK" message?

This +1. To start with, we never saw any communication from them indicating that anything that Zhoutong said was in any way incorrect, or that there was need of an apology to begin with. Of course, that could have been communicated privately, but from what I have seen so far even Zhoutong himself is becoming frustrated with the obvious stonewalling that we are seeing from the Consultancy.

Indeed, stonewalling is the best description that I can imagine for this series of events; to the public, and to those that wish to fix the problems, as it appears - since access to even the domain name has been fraught with problems such as a poor DNS implementation, leading to those that don't even use the forum to be forced to come here and find out the problem, and wait here for a resolution.

We use BCrypt with a pretty high difficulty number. So it will take a long time for the hacker to crack the passwords, possibly months for a moderately complex password.

No, we require email confirmations.

Then everybody who's email account password was the same as their Bitcoinica password better change their password pretty damn quick.

Almost.
Unfortunatly (for the hacker) he doesn't control user's email accounts, and he has no access to users ID documents.

i guess now would be the perfect time to use the signing feature in bitcoin-qt.

If "Bitcoinica Consultancy" is handling things now, why didn't they notify us of the claims page rather than zhoutong? The more I hear from zhoutong, and less from intersango or whatever they call themselves, the more I lose confidence in the new owner/operators.

Brilliant idea, now the hacker can get at all of Bitcoinica's funds.

The hacker wrote "EXPECT MASS LEAK" in transactions from the stolen money. We can only assume he has a copy of the database, so he has access to all the information needed to make a claim.

The team has not confirmed the settlement price yet. But you can expect these arguments:

- I have unrealized profits and I should have them!
- I have unrealized loss and I should wait until I recover!

We have open interest of 100,000 BTC so the conflict of interest is huge. I will leave this for the team to decide but my general suggestion is to use the highest price as the settlement price for longs and lowest price as the settlement price for shorts. You can continue to hedge your position elsewhere (and get some one-time settlement free money from Bitcoinica). It'll be fair for Bitcoinica and the user.

Thanks for the idea.

This is what I wanted to do:

- Drop the Bitcoin official client and re-implement one.
- Store private keys in the database, AES encrypted with a master key (that is associated with the user).
- Store master key in the database, AES encrypted with another hash of the user password (such as the SHA512 hash in place of the BCrypt hash).

This will be effectively a segregated account for the user. Of course we need to solve some problems (like forget password and forced settlements) but this is the general idea.

I'm a web developer so I feel much more comfortable securing the database rather than the wallet.dat. I never trust direct filesystem operations.

Zhoutong,

When I try that, here's what I get:

Forbidden (403)

CSRF verification failed. Request aborted.

More information is available with DEBUG=True.

So that means no forced liquidations.

This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery.   I inquired about this claim before and I don't believe I got a reply: https://bitcointalksearch.org/topic/m.899922  Luke-jr also expressed skepticism: https://bitcointalksearch.org/topic/m.899911

 I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems.   Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.

That said— if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.

What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined.  ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.  

There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client.   Moreover, many aspects of Bitcoin security require that you be a part of the majority clique— even if the majority is "wrong"—, if you can be moved onto a minority chain you can be robbed.   Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk.  So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.

There's the important part!

Good to see this I was really confused what was going on with you and intersango 

I have violated my promise (of "not to post anything [about Bitcoinica]") yesterday, by posting this in the emergency announcement thread:


Undoubtedly, I felt upset about some confusing commenters. I objectively disagreed with Intersango guys' ways of doing things and I think if Bitcoinica is still under my control, some of our customers' immediate issues can be addressed in a more timely manner.

However, I want to express my sincere apology to the General Partners of Bitcoinica LP, because I should not have criticized them when I should bear part of the responsibility by not doing my best in securing the system. The direct cause of the issue is not important, we shouldn't argue about "if someone didn't do X this thing wouldn't have happened", instead, we should say more about "if I did X this thing could be prevented". In this case, I can express these statements:

- If I have firewalled the wallet server properly (like web production servers), this thing could be prevented.
- If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.
- If I have set up strict access policies, and proactively communicate with Rackspace to disable certain insecure features, this thing could be prevented.

Respect for teammates is extremely crucial to achieve productivity. Everyone's reputation has been damaged badly in this event, and we shouldn't criticize each other due to the differences in the way we work. Even though I have announced that I would leave the Bitcoin economy a few days ago, I'm still actively monitoring our customers' feelings and communicating with the General Partners about the progress.

I am also extremely grateful for the Limited Partner (an investment group) of Bitcoinica LP for exceeding their legal obligation to bear the full cost of both recent attacks. Without their active support, Bitcoinica couldn't have survived until today to serve our customers well.

In the end, I would like to request everyone who cares about the community to be objective about this matter. I am no longer legally associated with Bitcoinica and I had no control over the attacked system. However, other team members are working in their greatest ability to deliver a fair solution to everyone. I have the advantage in understanding our customers (because I'm more familiar everyone using Bitcoinica) so I keep contributing some ideas as well. Please appreciate their hard work and understand the difficulties in resolving a serious security attack. We have already assured you the full compensation.

Thank you everyone for showing your support, understanding and patience.

PS. You can claim your Bitcoinica account at https://claims.bitcoinica.com/ now.