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

[jerfelix]

v2.3
https://www.bitaddress.org/bitaddress.org-v2.3-SHA1-1d067dc4f3103622ca9de332c3c86fc57d76ec83.html
 - Vanity Wallet now supports compressed keys.
 - Elliptic Curve and Bitcoin.ECKey libaries now support compressed keys.
 - English Json used for translations is now output to a textarea when
   you run the unit tests.
 - more unit tests, use ?unittests=true to run them.

I love bitaddress.org, and I consider it the Gold-Standard - er, the Bitcoin-Standard site for creating paper wallets.

That said, I see that you are using SHA256(passphrase) for the Brain Wallet.  Also, if I am following threads and people correctly, it seems that you respect the opinions of casascius.  He is advocating for a standard Brain Wallet function (based on scrypt as the key derivation algorithm).

https://bitcointalk.org/index.php?topic=139390.msg1484171#msg1484171

Any thoughts?  Do you think you will be updating bitaddress.org?  And if so, how will you handle previously generated brainwallets with SHA256 - hopefully we'll still have easy access to them on bitaddress.org.


Also, I have an idea for something a little different, but I am heavily using your bitaddress.org 2.2 code.  (I'll snag 2.3, now that I see it's out there.)
Thank you for making it easily licensed.   I am actually going to try to keep your code, byte-for-byte, intact, so that people can peer-review my derivation faster (since many eyes have already reviewed your code.)

Thanks again!

[pointbiz]

v2.3
https://www.bitaddress.org/bitaddress.org-v2.3-SHA1-1d067dc4f3103622ca9de332c3c86fc57d76ec83.html
 - Vanity Wallet now supports compressed keys.
 - Elliptic Curve and Bitcoin.ECKey libaries now support compressed keys.
 - English Json used for translations is now output to a textarea when
   you run the unit tests.
 - more unit tests, use ?unittests=true to run them.

I love bitaddress.org, and I consider it the Gold-Standard - er, the Bitcoin-Standard site for creating paper wallets.

That said, I see that you are using SHA256(passphrase) for the Brain Wallet.  Also, if I am following threads and people correctly, it seems that you respect the opinions of casascius.  He is advocating for a standard Brain Wallet function (based on scrypt as the key derivation algorithm).

https://bitcointalk.org/index.php?topic=139390.msg1484171#msg1484171

Any thoughts?  Do you think you will be updating bitaddress.org?  And if so, how will you handle previously generated brainwallets with SHA256 - hopefully we'll still have easy access to them on bitaddress.org.


Also, I have an idea for something a little different, but I am heavily using your bitaddress.org 2.2 code.  (I'll snag 2.3, now that I see it's out there.)
Thank you for making it easily licensed.   I am actually going to try to keep your code, byte-for-byte, intact, so that people can peer-review my derivation faster (since many eyes have already reviewed your code.)

Thanks again!

Thanks!

I just read the brain wallet thread you mentioned. My thoughts are that yes most likely I will add a new brain wallet algorithm involving scrypt with some of the techniques mentioned by casacius and Gavin. SHA256 will be available via a drop down for choosing your algorithm.

I like to follow this topic and I only want to implement standards or would be standards. Some people are using various big integer to word list algorithms but none is advocating theirs as a standard nor do they explain why they use non standard lists etc.

Casascius has been the biggest supporter of bitaddress.org since the beginning. He has put up bounties to get BIP38 which uses scrypt into JS and it will be the next feature on bitaddress.org

[casascius]

I might throw up a bounty to do an "intermediate code generator" as well.  (this won't be hard - just another simple recipe using scrypt,sha256,base58)

Here is what I imagine... another tab that says "Encrypted Wallets"

On the tab there would be two functions: generate intermediate code, and decrypt encrypted wallet

THe intermediate code takes a passphrase and makes a code (or series of codes) out of it.  The code can be used by someone else to generate bip38-encrypted paper wallets without knowing the passphrase.  Intermediate code generator takes a passphrase as input, and outputs a string that simply encodes 4 bytes of salt, 4 bytes of a combined "batch" and "sequence" number, and one compressed EC point.  The EC point is G * sha256(scrypt(passphrase, salt, 16384, 8, 8 ) + batch+sequence bytes) or something substantially similar.  The sequence number can be incremented to create more intermediate codes from the same passphrase without repeating the scrypt.

[Stephen Gornick]

v2.3

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.3 (1d067dc4f3103622ca9de332c3c86fc57d76ec83) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
1d067dc4f3103622ca9de332c3c86fc57d76ec83  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.3-SHA1-1d067dc4f3103622ca9de332c3c86fc57d76ec83.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.3"
54523d36b2680e8ec231c95b776bc2259f6bb328 v2.3 Vanity Wallet now supports compressed keys

$ git checkout 54523d36b2680e8ec231c95b776bc2259f6bb328
$ git rev-list --max-count=1 HEAD
54523d36b2680e8ec231c95b776bc2259f6bb328

$ sha1sum bitaddress.org.html
1d067dc4f3103622ca9de332c3c86fc57d76ec83  bitaddress.org.html

[phelix]

Sending funds does not work any more with the MtGox client: https://bitcointalk.org/index.php?topic=140739

I think we need to get support for scanning private keys into some other client.

[phelix]

FYI: I added "version 6b", which fixes a small bug in the GUI settings saving.

Moreover it improves the load/save behavior w.r.t. the "priv keys"/"btc addresses" fields, plus spelling error corrections in text templates etc. I found this useful when using the tool myself for generating my first real bitcoin vouchers.

I added the download link (html file only this time) in my post #354 above (the post where I announce version 6).

Just replace the "v6" html file with the newer version "v6b" and you'll be ok - load/save formats and GUI layout are identical.

PS: My first btc vouchers from own production with cheap b&w laser printer:


(if you wonder why I chose the first and not the last day of a month as expiry date, have a look at the BTC address at the bottom-right of the photo )

what about putting your code on github? It is kinda hard to trust an archive from dropbox.

[payb.tc]

Bug Report:

the QR codes turn solid black after exactly 18 clicks of the Generate New Address button on the first tab

using Chrome Version 24.0.1312.57 m


...this bug has then also carried over to liteaddress.org

edit: i realised this is actually working fine in regular Chrome, but the bug appears in incognito mode only.

[dooglus]

edit: i realised this is actually working fine in regular Chrome, but the bug appears in incognito mode only.

I can't reproduce in chromium Version 24.0.1312.56 Ubuntu 12.10 (24.0.1312.56-0ubuntu0.12.10.3).

[payb.tc]

edit: i realised this is actually working fine in regular Chrome, but the bug appears in incognito mode only.

I can't reproduce in chromium Version 24.0.1312.56 Ubuntu 12.10 (24.0.1312.56-0ubuntu0.12.10.3).

i can't reproduce it on any other machine i've tried either... this old WinXp pc from the 80's must be having it's own issues.

[pointbiz]

v2.4
https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html
 - French translations thanks to blockgenesis.

Up next is the BIP38 stuff.

[phelix]

I might throw up a bounty to do an "intermediate code generator" as well.  (this won't be hard - just another simple recipe using scrypt,sha256,base58)

Here is what I imagine... another tab that says "Encrypted Wallets"

On the tab there would be two functions: generate intermediate code, and decrypt encrypted wallet

THe intermediate code takes a passphrase and makes a code (or series of codes) out of it.  The code can be used by someone else to generate bip38-encrypted paper wallets without knowing the passphrase.  Intermediate code generator takes a passphrase as input, and outputs a string that simply encodes 4 bytes of salt, 4 bytes of a combined "batch" and "sequence" number, and one compressed EC point.  The EC point is G * sha256(scrypt(passphrase, salt, 16384, 8, 8 ) + batch+sequence bytes) or something substantially similar.  The sequence number can be incremented to create more intermediate codes from the same passphrase without repeating the scrypt.

standardized encrypted paper wallets would be nice

v2.4
https://www.bitaddress.org/bitaddress.org-v2.4-SHA1-1d5951f6a04dd5a287ac925da4e626870ee58d60.html
 - French translations thanks to blockgenesis.

Up next is the BIP38 stuff.

+1

higher resolution art would be nice. It's much too low for my taste.

[Steve]

I might throw up a bounty to do an "intermediate code generator" as well.  (this won't be hard - just another simple recipe using scrypt,sha256,base58)

Here is what I imagine... another tab that says "Encrypted Wallets"

On the tab there would be two functions: generate intermediate code, and decrypt encrypted wallet

THe intermediate code takes a passphrase and makes a code (or series of codes) out of it.  The code can be used by someone else to generate bip38-encrypted paper wallets without knowing the passphrase.  Intermediate code generator takes a passphrase as input, and outputs a string that simply encodes 4 bytes of salt, 4 bytes of a combined "batch" and "sequence" number, and one compressed EC point.  The EC point is G * sha256(scrypt(passphrase, salt, 16384, 8, 8 ) + batch+sequence bytes) or something substantially similar.  The sequence number can be incremented to create more intermediate codes from the same passphrase without repeating the scrypt.

+1 ...I could really use this and would be willing to contribute to make it happen as well.  I just want the ability to create nicely printed paper wallets where the private key is encrypted.

[ThePiachu]

I came across an unusual problem with your website - if you put in a private key that is less than 64 characters long, it doesn't recognise it as a proper private key. For example, this works:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

This doesn't:

E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

but this does:

00E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

As the private key is just a random number, it might be sensible to allow any string length to be able to represent a private key, not just those that are 64 characters long.

[grau]

I came across an unusual problem with your website - if you put in a private key that is less than 64 characters long, it doesn't recognise it as a proper private key. For example, this works:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

This doesn't:

E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

but this does:

00E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

As the private key is just a random number, it might be sensible to allow any string length to be able to represent a private key, not just those that are 64 characters long.

I guess it interprets E14... as negative number (sign bit set) wheras 00E14 is positive. I run into the same in Java, likely present in JavaScript BitInteger class.

[eins78]

higher resolution art would be nice. It's much too low for my taste.

Hi guys,

for the second installment of my "Bitcoin Vending Machine" art project I have started on a new paper wallet design. It is based on the current one (matches the size exactly) and I will try to integrate it into my bitadress fork to use it with the vending machine.

In the spirit of open sauce etc. I thought I'll also put it here, to get some feedback. I diverged from the original layout and text to make it more accessable. If you like it and want to put it into bitadrerss.org, I would certainly make the necessary modifications (like different URLs).


http://image.bayimg.com/91dda23369518e4580629359d92ec34e9d39fb47.jpg

[eins78]

I have started on a new paper wallet design

I monkey-patched it into my "fork" of the bitadress html page, so you can look how it would look. I broke some other stuff (qr code sizing), but the paper wallets work and it is quick hack anyhow.

http://bitcoin.ars.is/paperwallet-art2.html

My plan would be to further develop the paperwallet design and also offer "blank" sheets to download as PDF so you have them printed professionally and then at home you use the generator with the "hide art" option to just print the codes and hashes.

Then the design of the paper and the functionality of bitaddress.org could be a bit more separated, it would be just a matter of supporting different layouts (as in: where to position the stuff). I.e. I could offer a few color variations on the design (I am thinking Euro-Note colours), but they don't need to clog the bitaddress.org repository.

If there is market for it, I would even offset print a batch of blanks on nice paper, possibly with some extra funky features (UV ink?) or even pre-perforation.

(If anyone is interested, the commits are on github, but as I said it is just a quick hack.)

[Dabs]

Hi, can bitaddress make compressed private keys in the bulk wallet part? The ones that begin with Letters instead of number 5. (with corresponding public key of course.) I want to make a few hundred keys.

[pointbiz]

I might throw up a bounty to do an "intermediate code generator" as well.  (this won't be hard - just another simple recipe using scrypt,sha256,base58)

Here is what I imagine... another tab that says "Encrypted Wallets"

On the tab there would be two functions: generate intermediate code, and decrypt encrypted wallet

THe intermediate code takes a passphrase and makes a code (or series of codes) out of it.  The code can be used by someone else to generate bip38-encrypted paper wallets without knowing the passphrase.  Intermediate code generator takes a passphrase as input, and outputs a string that simply encodes 4 bytes of salt, 4 bytes of a combined "batch" and "sequence" number, and one compressed EC point.  The EC point is G * sha256(scrypt(passphrase, salt, 16384, 8, 8 ) + batch+sequence bytes) or something substantially similar.  The sequence number can be incremented to create more intermediate codes from the same passphrase without repeating the scrypt.

+1 ...I could really use this and would be willing to contribute to make it happen as well.  I just want the ability to create nicely printed paper wallets where the private key is encrypted.

Working on it

[pointbiz]

I came across an unusual problem with your website - if you put in a private key that is less than 64 characters long, it doesn't recognise it as a proper private key. For example, this works:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

This doesn't:

E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

but this does:

00E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725

As the private key is just a random number, it might be sensible to allow any string length to be able to represent a private key, not just those that are 64 characters long.

Bitcoin private keys are required to be 32 bytes. It is my understanding this number when represented in hex format should be zero padded so it is clear it represents 256 bits. It's also less risky to represent things this way for compatibility... in case the place you use your private key forgets to zero pad.

[Dabs]

May I suggest the following improvements:

1. Compressed keys for all output of paper wallet and bulk wallet, as an option. (Might as well include all other wallets, single wallets, brain wallets, vanity, etc.)
2. Choose a level of error correction for the QR codes. I prefer High or 30%. What is the level right now for version 2.4 ?