I think strongcoin.com and blockchain.info/wallet are doing something similar. Would be great to see it in bitaddress as well, since its a simple standalone tool.

Yes, but BitAddress has the unique feature of working entirely offline once you've saved a copy of the webpage. I can copy the saved page using a USB stick to an offline computer and run it there. Then my private keys are never on a machine connected to the Internet.

I did not realize there was interest in this feature. I've shied away from any passphrase protection features because I'm wrestling with the idea if it's better for bitcoins to be stolen then to be lost... there might be a greater chance of people forgetting versus people actually getting robbed. Especially in these early days... that being said I passphrase protect my desktop wallet.

And now for the workaround....

With the current version of BitAddress you can go to the Wallet Details tab and enter a passphrase (instead of a private key) and then you will be prompted to confirm you want to SHA256 hash your passphrase to generate a bitcoin address along with private key details. You can copy/paste the bitcoin address somewhere and then print it, or print the whole page and physically destroy the private key, etc. Then you've accomplished your goal of having a bitcoin address and accessing it's private key through a passphrase. No need to print an encrypted private key that later needs a passphrase anyway to decrypt.

Of course, it's not as elegant as the feature you have described. The current functionality is one passphrase to one bitcoin address versus what you proposed sounds like one passphrase to many bitcoin addresses.

I don't think this would be too hard to implement on the Paper Wallet tab... I'd probably need to include an AES javascript library... I'll think about it.

I don't think this would be too hard to implement on the Paper Wallet tab... I'd probably need to include an AES javascript library... I'll think about it.

The paper wallet tab would work well with a passphrase simply by appending an incrementing number to the end of the passphrase for each iteration.

Instead of sha256("my passphrase"), it would be sha256("my passphrase1")... sha256("my passphrase9999") etc.

Obviously, "my passphrase" is inappropriate as a passphrase, but is used here for clarity.

I see AES as unnecessary. If there is a demand for an "encrypted" paper wallet (that presumably requires a memorized key), then why not just print a deterministic paper wallet with no private keys (all of which can be recreated with a memorized key). To quell the concern that the memorized key might not have enough entropy, the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.

Of course, it's not as elegant as the feature you have described. The current functionality is one passphrase to one bitcoin address versus what you proposed sounds like one passphrase to many bitcoin addresses.

Nice workaround, but you're right; I was thinking of having the same passphrase for all the wallets on a single sheet of paper. I want multiple addresses, and don't want to have to remember multiple passphrases for them.

Maybe it would be useful to have the option to print the same page of addresses twice - once encrypted (for my bookshelf) and once unencrypted (for the bank vault in the event that I lose the wetware copy of the passphrase).

I see AES as unnecessary. If there is a demand for an "encrypted" paper wallet (that presumably requires a memorized key), then why not just print a deterministic paper wallet with no private keys (all of which can be recreated with a memorized key). To quell the concern that the memorized key might not have enough entropy, the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys.

The problem I see with that approach is that if I try to redeem one of my paper wallets on a compromised machine, I lose them all, not just one. Once you have the salt and my passphrase you have all my paper wallets.

The problem I see with that approach is that if I try to redeem one of my paper wallets on a compromised machine, I lose them all, not just one. Once you have the salt and my passphrase you have all my paper wallets.

That assumes the same salt and passphrase were used to produce all your paper wallets. If it were one salt per page, or one salt per address, that wouldn't be the case. If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.

That assumes the same salt and passphrase were used to produce all your paper wallets. If it were one salt per page, or one salt per address, that wouldn't be the case. If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

I think I was probably using the terminology wrongly, mixing "keys" with "wallets", etc.

Quote

the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys

That's the part that made me think a single salt plus the passphrase would give up all the private keys in the wallet in one fell swoop.

But if the salt was long enough to not be brute-forceable, and each address in the wallet had its own salt, that could work nicely.

That assumes the same salt and passphrase were used to produce all your paper wallets. If it were one salt per page, or one salt per address, that wouldn't be the case. If each address had its own salt, and you knew that you needed to redeem salt+passphrase, then you could do that (for example) directly on MtGox (which allows redemptions of arbitrary strings as private keys, which it converts via sha256 to a 256-bit value).

I think I was probably using the terminology wrongly, mixing "keys" with "wallets", etc.

Quote

the paper wallet (with no private keys) could also have a single salt string printed on it, where the salt and the memorized key are required to regenerate the private keys

That's the part that made me think a single salt plus the passphrase would give up all the private keys in the wallet in one fell swoop.

But if the salt was long enough to not be brute-forceable, and each address in the wallet had its own salt, that could work nicely.

If you have to have a unique salt for every address, why even bother being deterministic... That's not deterministic anymore.

I was picturing the paper wallet page having a text box at the top for a secret key. You put that it and it encrypts all of the private keys with the same key. This should be quite simple to do.

I would probably print one unencrypted page for a physical safe, then enter a key to encrypt all of the private keys and print that page out to keep in my desk at home.

If I use one of my paper keys on a compromised computer, I don't want to lose all of them. Non-deterministic wallets should guarantee this.

Hi guys, I created a fork and branch (comp_wif) with a few changes to add support for compressed public keys. Bitcoin 0.6+ utilizes compressed pubkeys when generating new addresses and the dumpprivkey/importprivkey commands support both formats. Naturally I wanted my favorite bitcoin utility to support it as well.

This is actually the first time I've used github, and it's been years since I did any java programming, but I think it was trivial enough to implement without making too much of a mess! I really only changed the "Wallet Details" tab. It now accepts and displays WIF keys with the compression marker and displays the corresponding compressed public key and bitcoin address. I think I managed to avoid introducing any errors but if anyone would like to give it a second look I'd appreciate it.

Great work! Thank you for the contribution. I reviewed the code looks good. I have to catch up a bit on the compressed keys stuff to be 100% sure.Thank you for the bug fix on the zero padding of base64 keys.

I will get this merged to the master branch and posted on bitaddress.orgI will post here when it's live.

Also, step 5 of "How do I use a Bulk Wallet to accept Bitcoins on my website?" says "Use the original wallet file you generated in step 1", but step 1 doesn't involve making a wallet file, just a list of keys:

Quote

"Use the Bulk Wallet tab to pre-generate a large number of bitcoin addresses (10,000+). Copy and paste the generated comma separated values (CSV) list to a secure text file on your computer. Backup the file you just created to a secure location."