[ANN] bitaddress.org Safe JavaScript Bitcoin address/private key

[casascius]

So it's JavaScript it means it is client side computing no private key is transmitted over the internet?

That is correct.  Run it offline as a further assurance.

[1715211324]

1715211324

[1715211324]

1715211324

[1715211324]

1715211324

[1715211324]

1715211324

[Stephen Gornick]

So it's JavaScript it means it is client side computing no private key is transmitted over the internet?

That is correct.  Run it offline as a further assurance.

Run it offline, from a liveOS (e.g., boot to an Ubuntu distribution image) for even further assurance.

Brian Krebs gives an example of doing this for online banking here:
 - http://krebsonsecurity.com/2012/07/banking-on-a-live-cd/

[dooglus]

So it's JavaScript it means it is client side computing no private key is transmitted over the internet?

That is correct.  Run it offline as a further assurance.

It's a single file too - all the graphics, css, scripting are part of the main HTML file.  So just save the page to a USB stick and take it to an offline machine to generate your offline keys & brain wallets.

[BkkCoins]

I just comment out these two lines in src/rpcdump.cpp:

Code:

        pwalletMain->ScanForWalletTransactions(pindexGenesisBlock, true);
        pwalletMain->ReacceptWalletTransactions();

Then you can import keys really quickly.  Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys.  I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.

I did this too, and also modified the -rescan code so that -rescan=170000 (for example) only scans from block 170000 and beyond.  Perfect if you know you're importing recently-received funds.  IIRC, the way I did it was to modify ScanForWalletTransactions() to have one more 64-bit-integer parameter to say how many blocks to skip, and then created an overload so calls lacking the skip number will default to 0.

This way I can import lots of private keys, but only wait for a blockchain rescan once, and only from the starting point where I began receiving payments with those keys.

Both excellent ideas. Except I use the Ubuntu PPA and don't compile my own source. Drats.
We should petition for a new API call for this. Something like "setrescanstart" which can be default 0 or set off (-1) or given a block # to rescan from, just for the current session. That would save a lot of people time.

[casascius]

Both excellent ideas. Except I use the Ubuntu PPA and don't compile my own source. Drats.
We should petition for a new API call for this. Something like "setrescanstart" which can be default 0 or set off (-1) or given a block # to rescan from, just for the current session. That would save a lot of people time.

Rescan is a command-line function, and their command line parser is already well-suited to grabbing and passing numeric arguments, so combining it with the actual rescan argument to me makes the most sense.

Actually, ongoing, a rescan shouldn't be necessary to import a private key with its balance, and ideally the client will maintain an index allowing for instant lookup of value behind a bitcoin address.  Even though the developers haven't considered such an index a priority feature, there is some discussion about maintaining a meta-tree to break the barrier of not having to carry a full block chain, and that meta-tree would serve the same purpose as the index and make a block chain rescan unnecessary.

[BkkCoins]

Rescan is a command-line function, and their command line parser is already well-suited to grabbing and passing numeric arguments, so combining it with the actual rescan argument to me makes the most sense.

Makes sense to me. Something like defaults to scan from block 0, but you can give it a block # to scan from or negative number meaning from current block. eg. -10 scan last 10 blocks. And import privkey doesn't need to rescan as you can just issue the rescan command after importing a whole batch of keys.

[slothbag]

Is it possible to include the ability to encrypt and decrypt the private key string and private key QR code with a simple passphrase.

I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.

[Stephen Gornick]

I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.

That topic occurs earlier in this thread, but is not being implemented on BitAddress.org:
 - http://bitcointalk.org/index.php?topic=43496.msg750838#msg750838


And it was suggested by about a half dozen people on the bitcoin banknote thread:
 - http://bitcointalk.org/index.php?topic=92969.msg1036869#msg1036869

[casascius]

Is it possible to include the ability to encrypt and decrypt the private key string and private key QR code with a simple passphrase.

I would like to print up a paper wallet but require entering a pass phrase to decode it.. then I can leave the paper wallet on a desk and be pretty confident if someone took it they wouldn't be able to use it without some brute force cracking.

I am thinking of proposing specs for this, and then modifying my Casascius Bitcoin Utility to be a proof of concept.

What I have in mind...  You all know that 5xxxxx is a private key... I am thinking of defining another prefix (e.g. Pxxxxxx) to be a "private key that needs something else to be redeemed".  (In minikeys, Sxxxxx is a private key, and Pxxxxxx could be a protected minikey)

That "something else" could be a passphrase, another private key, or a combination of both.  The specification I draft will accommodate base cases.

My utility will be needed to actually decrypt them, but by publishing and standardizing the encoding, I'll be able to get others to jump on the bandwagon (similar to how I did with the minikey).

[payb.tc]

on the new brainwallet tab, i updated my local copy to say input type="password". perhaps you could think about this for the next revision.

people probably aren't using this in public, but might still feel better not having their phrase shown on the screen.

[slothbag]

I am thinking of proposing specs for this, and then modifying my Casascius Bitcoin Utility to be a proof of concept.

What I have in mind...  You all know that 5xxxxx is a private key... I am thinking of defining another prefix (e.g. Pxxxxxx) to be a "private key that needs something else to be redeemed".  (In minikeys, Sxxxxx is a private key, and Pxxxxxx could be a protected minikey)

That "something else" could be a passphrase, another private key, or a combination of both.  The specification I draft will accommodate base cases.

My utility will be needed to actually decrypt them, but by publishing and standardizing the encoding, I'll be able to get others to jump on the bandwagon (similar to how I did with the minikey).

Funnily enough, initially I was thinking the best approach was to modify your dot.net wallet app to include private key encryption and a QR renderer.  Then I thought it would be easier for this BitAddress tool, but if thats already been discussed and rejected I guess its back to modifying your dot.net app.  If the code is generic enough it should compile and run in Mono and be cross platform.

I like your proposal.  Keep us posted.

[casascius]

I am thinking of proposing specs for this, and then modifying my Casascius Bitcoin Utility to be a proof of concept.

What I have in mind...  You all know that 5xxxxx is a private key... I am thinking of defining another prefix (e.g. Pxxxxxx) to be a "private key that needs something else to be redeemed".  (In minikeys, Sxxxxx is a private key, and Pxxxxxx could be a protected minikey)

That "something else" could be a passphrase, another private key, or a combination of both.  The specification I draft will accommodate base cases.

My utility will be needed to actually decrypt them, but by publishing and standardizing the encoding, I'll be able to get others to jump on the bandwagon (similar to how I did with the minikey).

Funnily enough, initially I was thinking the best approach was to modify your dot.net wallet app to include private key encryption and a QR renderer.  Then I thought it would be easier for this BitAddress tool, but if thats already been discussed and rejected I guess its back to modifying your dot.net app.  If the code is generic enough it should compile and run in Mono and be cross platform.

I like your proposal.  Keep us posted.

I have already added the QR stuff, I have just done so many dirty hacks to my code to perform one-off tasks that it's now a total mess and I'd be embarrassed to check it in.  But I'd zip it up and e-mail it to you if you wanted to start where I left off.  It will print QR paper wallets and dump the bitcoin addresses to a text file, but prints a hard coded quantity and dumps to a hard coded text file because I was just in a hurry to get some more coldwallets I could use with my website (where the private key is on paper but the bitcoin address stays online so the server can serve it)

[pointbiz]

on the new brainwallet tab, i updated my local copy to say input type="password". perhaps you could think about this for the next revision.

people probably aren't using this in public, but might still feel better not having their phrase shown on the screen.

That's a good point. I think it's worthwhile to have the ability to toggle show/hide for passphrase text.
I'll add that to the next version.

[dooglus]

on the new brainwallet tab, i updated my local copy to say input type="password". perhaps you could think about this for the next revision.

people probably aren't using this in public, but might still feel better not having their phrase shown on the screen.

That's a good point. I think it's worthwhile to have the ability to toggle show/hide for passphrase text.
I'll add that to the next version.

Maybe also the option to have 2 boxes where I can type the passphrase twice, have it not show up, but have an indication of whether I typed it the same both times.  I understand some people might want the passphrase displayed on-screen, so they can check whether they typed it right, but for those who don't want it displayed it's useful to have a "type it again to make sure" box.

[fivemileshigh]

[newb]

Re:the brain wallet tab:

Is there a minimum recommended passphrase ? Are 30 characters enough?

[/newb] thanks!

And further: is bitaddress.org the only way to recover the private key, or are there alternatives?

[dooglus]

[newb]

Re:the brain wallet tab:

Is there a minimum recommended passphrase ? Are 30 characters enough?

[/newb] thanks!

And further: is bitaddress.org the only way to recover the private key, or are there alternatives?

bitaddress is just doing an sha256 hash of the brain wallet passphrase to get the private key, and then encoding it into wallet import format in the standard way.  So creating an alternative would be trivial.  I don't know of existing software that will do the job, but it probably already exists.

For the first step:

Code:

$ echo -n 'abcdefghijklmnopqrstuvwxyz 123' | sha256sum
daa0f2bcf5f0ea99d3df46a07af6202f781ff46016ce14b94b66eee000b0056b  -

[BkkCoins]

Blockchain.info has now added Brain Wallet support with the same format.

Note that the value above,

daa0f2bcf5f0ea99d3df46a07af6202f781ff46016ce14b94b66eee000b0056b

is the hex version of the private key. You can verify that by plugging it into the Wallet Details tab on bitaddress.org and see that you get the same WIF format private key. I also verified that the hex version can be imported into blockchain.info directly.

So if bitaddress.org were to vanish you could still use blockchain.info. But vanishing is impossible if you save the page to your local computer first (since it can be opened in a browser locally any time later and still function).

[BkkCoins]

Might it be useful/possible to add a feature to wallet details that could sum keys like the vanitygen keyconv utility?

I think the wallet details tab can be used to create a hex public key for input to vanitygen. This allows third party vanity address generation now. The result is a partial key that must be combined back with the original hex private key to form the new trusted private key (and address).

But currently users would have to trust a third party to compile the keyconv utility, or compile it themselves. So having bitaddress.org with such a sum tool would make it easier for third party address generation to be workable.

Not sure how hard that sum process is but it seems like it may be useful, and perhaps could be used in other applications involving third party private keys.

[dooglus]

Blockchain.info has now added Brain Wallet support with the same format.

I'm not seeing it.  Where can I find the brain wallet support on blockchain.info?

Thanks.

[rockxie]

Blockchain.info has now added Brain Wallet support with the same format.

I'm not seeing it.  Where can I find the brain wallet support on blockchain.info?

Thanks.

Import / Export