If this is real, then the "Rig Box" would be still a much much more efficient beast in comparison.

50.4 Giga Hash / S @ 2,500w @ $24,980

About $4M in these would take over the network.

Does it show up after restarting Armory? I've had problems with Armory only scanning the first address when importing multiple keys to the same wallet.

Hi cypherdoc,

RE: the "Export private keys" screen not being as clear as it could be.

I have written up some help text with screenshots and put it into the MultiBit help here:
http://multibit.org/help_exportingPrivateKeys.html

Edit: I have also transcribed the "how to run from a USB drive" into:
http://multibit.org/help_runFromUSBDrive.html

The QR code is the exact same data, but in a QR code.  The primary goal was that you could use the paper backup as both a backup, and a means to transfer a wallet to your smartphone, just by scanning it (there are currently no Bitcoin Android apps that leverage my wallet format, but I'm getting help to work on one, now).  But it would also be useful if you have a webcam setup for scanning QR codes -- it'll pick up the exact same letters as shown on the page, and you can just copy the text into the "paper backup import" dialog.

For anyone in this thread who has no idea what I'm talking about, the paper backup looks like this:

The "root key" is a Bitcoin address that serves as the "root node" of the deterministic wallet.  All other addresses are based on it.  The chaincode is another 32-byte number that helps you get from PrivKey(i) to PrivKey(i+1) or PubKey(i) to PubKey(i+1).    In order to have "type 2" deterministic wallets, you will need to be multiply the priv/pub keys by a number... so the chaincode is used to create that number.

As described by gmaxwell, you could easily use lots of different chaincodes to create different address "branches".  Right now, in Armory, there is only one chaincode per wallet.  But you could could add multiple chaincodes to create multiple "branches" that would then appear unrelated -- i.e. you could give someone a watching-only wallet with the first chaincode, another person with a different chaincode but same root public key -- they'll generate two completely different address chains even though they both have the same root public key.  You can generate all private keys in both, but the two people will not be able to generate or even recognize addresses on the other branch.

If someone steals your wallet, they get all your old addresses and the next 100, but no more.  When you start using addresses, the key pool keeps getting refilled with random addresses based on the random number generator on your computer.  The attacker will generate different (and thus useless) addresses.   Therefore, if someone steals your wallet, it "unsteals" itself after you go through 100 addresses.

Since the point of deterministic wallets is to produce the same sequences of addresses every time, the attacker will always generate the exact same addresses until the end of time.  They have permanently stolen your wallet, and could wait years before executing an attack, if they knew you were going to keep using it.

However, I'm of the opinion that this is basically irrelevant.  The severity of attacks on both types are not much different, and many cases they are the same -- because if the attacker has access to your system to steal it, they can install a process to continue stealing your wallet.  I firmly believe that users' not having sufficient backups is a tremendously more significant risk to their wallets.  As such, deterministic wallets are superior since they only require one backup at time of creation.

Yep. That is the compromise.  The current wallets unsteal themselves.

rjk,

Unfortunately, it hasn't reached that stage yet.  It still requires the blockchain in memory, though I have made a lot of progress switching to a non-full-RAM implementation.  It was an early design decision due to it being a creative, experimental tool, not a wide-user-base client.  I'm paying for that now, by having to overhaul pieces of the C++ code run like a "normal" application.   Unfortunately, it's a lot of work, and will need a lot of testing when it's done.

And, Armory still requires the Satoshi (regular) Bitcoin client to be running -- Armory connects to it as a single peer and uses it to receive not-in-the-blockchain transactions yet, and to send tx to be broadcast.  This gives Armory the security of having all the most advanced networking security behaviors in the regular client, as well as full-validation behaviors, but does make Armory even more burdensome to use.

THIS is why Armory is still alpha.  It's very usable if you have 4GB of RAM and don't mind running the regular client, too.  But it's going to take quite a bit of work just to support everyone else. 

I've been asked about this a few times.  I think I will do it eventually, at least for Windows (where there's a fairly consistent environment).  But that's low priority, at the moment...

If you would like to do it yourself:  Here is the vantiygen thread, and the download link for Windows binaries.  You will have to run it from the command line to supply the arguments and make sure the window stays open when it's done.   But it's actually quite simple once you get to the directory with the executable in it.  You should only need to type something as simple as: 

 

The third option there is for GPU (OpenCL) vanitygen, which is, of course, much faster than the CPU.  There are many more customization options, but I'll let you look at the thread for that.   When you run it, it will tell you how long it expects to take (a timeframe for 50% chance of success).  6 letters (such as 1Cypher) will take a few days on a CPU, a few hours on a GPU.  Every letter after that, multiply by 58 (it gets out of hand quickly!).

Check back with it every couple hours and see if it succeeded.  Just copy (or type) the very long string into the Armory import-address dialog and you're done! 

@cypherdoc

Thanks for your enquiry about running MultiBit on a USB drive.
You do not mention which operating system you are using.   The instructions are slightly different from OS to OS but here are the instructions for on Windows:

Installing MultiBit to run on a USB drive for Windows.

1) Insert your USB drive into your PC.

2) Run the MultiBit Windows installer. On the screen with the question "Select the installation path:" click on the "Browse" button and select a directory on your USB drive.

3) Run the rest of the installation as normal.

4) Once the installation is done, in Explorer navigate to your USB drive's MultiBit installation directory.   It is the directory with the "multibit.exe" file.

5) Create a new text file called (exactly) "multibit.properties".   Leave the file empty.
This is the MultiBit configuration file.   Having a copy in the installation directory (rather than the user's application data) tells MultiBit to run locally.  

6) To run MultiBit locally, double click on the multibit.exe file.
You will have a single default wallet created, called multibit.wallet.   You can create new ones using the 'Create Wallet' button and doing a save into your USB drive.   You will be using a locally stored blockchain (called multibit.blockchain).

Notes and Gotchas
1) The path of the wallets in the configuration file contains the USB drive letter which may change according to how many other drives you have plugged in.   In this case the wallets other than multibit.wallet will not be found when MultiBit opens.   You can just use the "Open Wallet" button to load them.   I will put on my TODO list to stored the wallet filenames in relative form as this would get round this.
2) With the instructions above, it assumes you have Java installed on the machine you plug into.   You can also have a "Java Runtime Environment" stored on the USB too so that it is guaranteed to run.   I will write up some notes on how to do this.
3) The installer will add some shortcuts for running MultiBit pointing to the USB drive.  Of course these will not work if the USB drive is removed.

Let me know how you get on - running MultiBit on a USB drive will be quite useful to people so I would be interested in your experience and comments.  It probably needs a custom screen in the installer where the user can choose a "Run locally" option.