Java


Spreading the workload around. Bitcoind resource usage is increasing, running in VMs is putting too much load on the main servers but a mac mini can run a full node without problem freeing up resources.

Actually that is an old maintenance message which i forgot to update, the servers were switched a few months back. The old mac minis are being fired up again and some processes are being moved over (Bitcoind, Email server etc) as well as upgrading the firmware on the firewall and installing the latest mysql cluster version. Should be back fairly soon.

All PingIt and Bank Deposits should be clear now.

I am going to close all zendesk tickets regarding PingIt and Bank deposits, if any users are still having problems with orders please create a new ticket. The following surnames have orders with incorrect reference numbers that I have not been able to resolve: LOOR, SMITH, KING, BAKER - please contact me.

Deposits will remain disabled until the end of the Japanese bank Holiday on the 4th. 12:00 AM Tonight (3rd Jan) the site will be going down for approximately 30 mins - 1 hour maintenance.

Sorry everyone one server crashed, should be fully functional now, have a great new year.

The verifier does not allow inline script tags, line 36:

https://github.com/blockchain/My-Wallet-Integrity-Checker/blob/master/chrome/mywallet.js

Please PM with a link to your website and I can give you a code to bypass the api limits.

Malicious browser extensions are a type of malware and it is the mostly users responsibility to ensure they have a clean OS when dealing with financial sites. No bitcoin users should be running random exe's and if you are using any bitcoin websites you shouldn't be installing random extensions (specifically ones which ask for permission to run on blockchain.info/Mt.Gox/instawallet etc). The current version of the js verifier specifically allows for other extensions to continue to run scripts.

Multisig is the only full proof solution to this problem.

After some discussion with Steve it appears someone may have attempted to login to his wallet however they were unable to pass the two factor authentication test. I believe he has moved the coins elsewhere now anyway.


Sometimes the verifier can throw erroneous warnings if there is a problem downloading any of the scripts. If an error is displayed try refreshing the page, if it keeps appearing there may be a problem but otherwise the error can be ignored.

------

There are currently no known specific threats to any wallet or the site in general.

I cannot find your email, please send me your wallet identifier to help@blockchain.info

You have just modified the javascript in your own browser. The javascript is the bitcoin client and if you modify the client then of course you can change it to print the password or private keys etc. It would be trivial to modify the Bitcoin-Qt source to add an alert box which prints the password in a similar fashion.

This is how the service works, client side.

The information should not have been posted publicly, but:

- The user has not lost any money
- The wallets private keys are still safe
- The user has his own backups, we have backups of every version of the wallet.

A normal hosted wallet could have simply done.

The ip address the wallet was last updated with.


With the sharedKey two factor authentication can be disabled.

Every version of a wallet is stored (every time it is updated). The users has been sent those backups, with instructions to import them into another client or a new blockchain wallet.

There isn't really any ability to lock a wallet, but yes with access to the sharedKey and some custom crafted http requests he could have achieved that affect. Nethead has an email associated with the account so he will have been automatically emailed backups. With backups the extortion would be easily circumvented by importing the wallet into Multibit or any other client. This is one of the reasons why it's always a good idea to keep your own backups.

Since the users password is never sent to the server a randomly generated key is used instead for server side authentication. With that key you have the ability to control some of the meta data associated with a wallet. As that key was posted publicly on the forums nethead should start a new wallet.

Your sharedKey was contained within the information posted. This key gives someone the ability to authenticate themselves with blockchain.info as the owner of that wallet, including the ability to overwrite it.

The coins will be safe though. I have emailed you 6 recent backups of the wallet. They can either be imported into Multibit (http://multibit.org) or imported into a new wallet at https://blockchain.info/wallet/import-wallet. You are welcome to continue using blockchain.info if you desire.

Please PM me the problem.

I do not like it, in the case of "Roger vs Nethead" a yes/no was all that was needed to confirm he was likely the owner of the bitcoin address in question. The fact that his email address and ip was revealed was not of much consequence as that information was already know to the bitcoinstore, so the end result was the same.

Blockchain's policy stands as it always has "We will not sell, distribute or lease your personal information to third parties unless we are required by law to do so.". Hopefully if required to do so by law we will be holding as little information as possible.

Yes I am fully aware this policy was broken and I apologise for that. Steps have been taken to resolve the immediate problem of admin access and make determining information on wallets more difficult in future by hashing addresses.  The same hashing will be done with ip addresses.

Slight mix up with the names on a deposit order. It has now been resolved.


 

That sentence refers to access logs from regular pageviews to the site and queries to api. When a wallet is created and updated the ip address is recorded and this has always been stated on http://blockchain.info/privacy and https://blockchain.info/wallet/anonymity. I will changed it to keep the hashed ip/24 only.