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

[BkkCoins]

What is the copyright/licensing on the art? If I wanted to use it an open source project would that be a problem? Is a vector version available somewhere that could be used for rendering at a different resolution? Thx.

[pointbiz]

What is the copyright/licensing on the art? If I wanted to use it an open source project would that be a problem? Is a vector version available somewhere that could be used for rendering at a different resolution? Thx.

The wallet art work is public domain. Look in Casascuis banknote thread for the link to the SVG and PSD.

[BkkCoins]

What is the copyright/licensing on the art? If I wanted to use it an open source project would that be a problem? Is a vector version available somewhere that could be used for rendering at a different resolution? Thx.

The wallet art work is public domain. Look in Casascuis banknote thread for the link to the SVG and PSD.

Oh, nice. Thank you. Will do.

[Bitcoin Oz]

Someone should sell archive paper you can print these wallets on for longer term storage. I would buy some for btc 

[bitpop]

why dont u go to kinkos and laminate them?

[pointbiz]

Awesome job!

I have one minor request: can the Art be the default, and the checkbox be "Hide Art"?

Also, the Ubuntu font didn't come through on the PNG.  (The font dependency can be removed by converting the text to "outlines", essentially shapes, before doing the conversion... in Illustrator it's just right click and "convert to outlines"... not sure what it is in other tools).

If you can fix these two things and publish them at the bitaddress.org URL (at /, rather than /something), a 10 BTC silver round with free shipping is awaiting you! (your choice, plated or non.)  I will PM you a code and a link.

v1.8
https://www.bitaddress.org/bitaddress.org-v1.8-SHA1-97d52a44eeb261e2398e98e1eed2bd56b99c845a.html
 - Paper Wallet Tab: Art wallet is now the default.
 - Paper Wallet Tab: The PNG has been resized to fit better into physical wallets when printed.
 - Paper Wallet Tab: The PNG has been rendered using the Ubuntu font.


Looking forward to that shiny silver 
Thanks for the fun project!

[casascius]

PM'd you code for free silver coin

I'm doing orders right now so if you order now it will be prepared right now

Thanks for the awesome work!

[nibor]

Have added a pull request for the Vanity Address Tab to Git:
https://github.com/pointbiz/bitaddress.org/pull/3

Any chance of someone to reviewing it?
Is trival, just 126 lines added and one changed.

I saw on github you are still making changes. I will consider adding your tab. Could you also merge with the newest version v1.7 ?

I'd like to give this Vanity Address thing a try... do you have a link that would guide me through the process?
Who do I contact to find the vanity address?

I have rebased to your latest version. Give it a try.

To test out download vanity generator from:
https://bitcointalk.org/index.php?topic=25804.0

Then create a new key on the tab. Keep the private key safe.
Then run:
oclvanitygen.exe -P PUBLICKEYFROMABOVE 1prefix

This with after some time return a private key.
If you then put this private key and the one you originally generated into the bitaddress.org page it will then
generate the actual private key in WIF and confirm that the address is the one that starts with the prefix you want.

In a vanity pool someone else would run the oclvanitygen for you.

[Stephen Gornick]

v1.8
https://www.bitaddress.org/bitaddress.org-v1.8-SHA1-97d52a44eeb261e2398e98e1eed2bd56b99c845a.html

I can verify that the BitAddress.org website has been updated and returns the same HTML from the latest commit (31433898c7b984ff532bd8f24a286ba5e6426e1e) 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
97d52a44eeb261e2398e98e1eed2bd56b99c845a  -

Then from my bitaddress.org repo:

$ git pull
$ git rev-list --max-count=1 HEAD
31433898c7b984ff532bd8f24a286ba5e6426e1e

$ sha1sum bitaddress.org.html
97d52a44eeb261e2398e98e1eed2bd56b99c845a  bitaddress.org.html

[salfter]

Just started fooling around with testnet a bit for a project I have in mind...tried creating some addresses, but bitcoind (running on testnet) won't import the private keys generated by bitaddress.org.  Testnet private keys begin with 9, but the ones returned by bitaddress.org begin with 5 (same as for mainnet):



Likewise, the keys in my bitcoind wallet (or keys generated with vanitygen -T) can't be brought into bitaddress.org.

[pointbiz]

Just started fooling around with testnet a bit for a project I have in mind...tried creating some addresses, but bitcoind (running on testnet) won't import the private keys generated by bitaddress.org.  Testnet private keys begin with 9, but the ones returned by bitaddress.org begin with 5 (same as for mainnet):



Likewise, the keys in my bitcoind wallet (or keys generated with vanitygen -T) can't be brought into bitaddress.org.

Huh I thought only the Bitcoin address was different for testnet. Thanks for letting me know.

Do you know what byte should be used for test net?

[pointbiz]

https://en.bitcoin.it/wiki/List_of_address_prefixes

The wiki says the prefix should be 2 not 9 but it doesn't show an example.

[casascius]

The correlation to prefix depends on the length.  Different length, different set of prefixes.

If someone wants to post any testnet key, I can decode it and tell what bytes are in it.

[salfter]

The correlation to prefix depends on the length.  Different length, different set of prefixes.

If someone wants to post any testnet key, I can decode it and tell what bytes are in it.

Here's one I had vanitygen create a couple of minutes ago:

Code:

Address: mocupbVqze93jsSPnvmi1HWYQtP5gh6Bs9
Privkey: 91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6

[dooglus]

https://en.bitcoin.it/wiki/List_of_address_prefixes

The wiki says the prefix should be 2 not 9 but it doesn't show an example.

I think that was my fault - sorry about that.  I calculated the leading symbol given the 'version' byte for 160 bit hashes, and then forgot that the testnet private key wasn't a 160 bit hash...  I just updated the wiki page.

Anyway, if you look at src/base58.h in the bitcoin source tree you'll see the version bytes for private keys are defined:

Code:

    void SetSecret(const CSecret& vchSecret, bool fCompressed)
    { 
        [...]
        SetData(fTestNet ? 239 : 128, &vchSecret[0], vchSecret.size());
        [...]
    }

ie. the version byte is 239 for testnet, and 128 otherwise.

I just made 5 new testnet addresses in a new wallet and dumped their private keys:

Code:

chris@chris:~$ bc dumpprivkey mfqu6YriHRhQZUrqHT38oNyKZ6dLbzhF9y
cRxmHP4nkYKhvwdACAvkdi9RvrUsdWSGvajDr5UT91c2dQzdSXQD
chris@chris:~$ bc dumpprivkey mk2Ctt7XheaAe26UKDUkJpasTj6VYuQCKa
cS7SUNgwGL7uvEQDvWXyANAxxsTpP4btZdTX2GjPSADWZGNfE68Q
chris@chris:~$ bc dumpprivkey msv4rcL8Cuxa5VwxUBfoZ8Szjzuu7uyx6h
cUY1mz1RhgjxPgvLhsoxtkMPrhpqroTP693P1S662rSjTR8mfTZz
chris@chris:~$ bc dumpprivkey mpzij847QrnU76Ea4gfTyqgHpmkzTzjChC
cMf54jpB8cwm2wJFsf5AzBhL3vTMARwpNwEy7dHLvE9Vu8HSsMCF
chris@chris:~$ bc dumpprivkey mffRkRw2ZiSBN5CxGVZxLyfiUYxtDWzDCF
cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm

Looks like the private key begins with a 'c'.  I also dumped the private keys of the 17 old addresses in my 'real' testnet wallet.  They all begin with 'c' too.  You'll notice too that testnet privkeys are 52 characters long, whereas realnet (?) ones are 51 characters long.

[dooglus]

Here's reasoning to show why the testnet privkey will start with 'c':

The privkey is 33 bytes (if it's compressed, which it is by default?), and the checksum is 4 bytes.  That means the number we convert to base58 is between
  239*256**(33+4)
and
  240*256**(33+4)-1.

When we divide either of these numbers by 58**51 to get the 1st base58 character code, we get 35, which is the code for 'c':

>>> (239*256**(33+4)) / 58**51
35L
>>> (240*256**(33+4)-1) / 58**51
35L

[dooglus]

Here's one I had vanitygen create a couple of minutes ago:

Code:

Address: mocupbVqze93jsSPnvmi1HWYQtP5gh6Bs9
Privkey: 91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6

Ah, that's an uncompressed key.  Those will begin with character code 8, which is '9', and will be only 51 characters long.

>>> (239*256**(32+4)) / 58**50
8L
>>> (240*256**(32+4)-1) / 58**50
8L

[casascius]

Code:

Address: mocupbVqze93jsSPnvmi1HWYQtP5gh6Bs9
Privkey: 91eWjgRmucdtYHpMdsHbn9h8UU8hdoMNSKj8p3QAj6VTLyBnjj6

Code:

chris@chris:~$ bc dumpprivkey mfqu6YriHRhQZUrqHT38oNyKZ6dLbzhF9y
cRxmHP4nkYKhvwdACAvkdi9RvrUsdWSGvajDr5UT91c2dQzdSXQD
chris@chris:~$ bc dumpprivkey mk2Ctt7XheaAe26UKDUkJpasTj6VYuQCKa
cS7SUNgwGL7uvEQDvWXyANAxxsTpP4btZdTX2GjPSADWZGNfE68Q
chris@chris:~$ bc dumpprivkey msv4rcL8Cuxa5VwxUBfoZ8Szjzuu7uyx6h
cUY1mz1RhgjxPgvLhsoxtkMPrhpqroTP693P1S662rSjTR8mfTZz
chris@chris:~$ bc dumpprivkey mpzij847QrnU76Ea4gfTyqgHpmkzTzjChC
cMf54jpB8cwm2wJFsf5AzBhL3vTMARwpNwEy7dHLvE9Vu8HSsMCF
chris@chris:~$ bc dumpprivkey mffRkRw2ZiSBN5CxGVZxLyfiUYxtDWzDCF
cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm

The hex for the first one, and then these five, is

Code:

EF 08 2A 55 D3 89 66 47 6B B9 8E 9C 6A 52 E1 12 B6 4C 19 93 80 46 6C AA 6D A7 2F 27 05 B9 F2 FB 7A 
EF 82 B3 0F A5 47 57 53 33 18 1B 2C 43 AF 41 00 91 60 E8 5D 51 44 18 6E 60 75 B3 C7 37 8F F7 2E D8 01 
EF 87 29 9D 51 D9 76 AD F2 97 AE F1 E5 44 AF 71 28 9C 52 27 C9 3D F5 8A 2B CF 90 8E 93 C3 1C C0 2F 01 
EF CF 7A B0 12 38 EE 02 C3 C1 4E 83 56 3B 66 C6 A9 79 6A 20 ED 79 C3 AA 22 DA 8F 34 33 23 84 41 CF 01 
EF 02 3F 69 DF 19 7D 5B CA F2 74 A0 48 7B C7 10 B6 F4 B8 0B D3 3C 4D 9A E1 E6 F5 74 84 AA 02 BE A6 01 
EF 15 60 49 6D 13 57 30 F5 A1 BB 39 58 0A BB A1 FE 8E A2 70 76 8A 08 C4 9A 66 73 27 72 B0 B8 11 E2 01 

Based on what I know of other private keys, I'm going to guess that EF is always the prefix, and the extra 01 byte means compressed (which lengthens the code to 52).

It looks like uncompressed will always start with 9 (range: 91-93) and the compressed ones always start with c (range cM-cW)

[casascius]

I'm pleased to be able to present the following that I've done some work on.

I have pretty much copied the design but re-rendered everything myself, from scratch, in SVG format.  That is - natively - without converting a raster image.  As a result, the whole thing as SVG weighs in at under 250 KB.  I did this in Adobe Illustrator.



.ai, .png, .svg -> https://casascius.com/graphnote.zip

EDIT followup: updated the image to thicken the lines so they moire less on printers. made the right hand ones whiter

[casascius]

Meanwhile, here is just a brainstorming of my wishes for the next eventual iteration, whether or not they're realistic or possible.

1. choice of multiple art files, while still having art built-in to the single html file.  (multiple art just wouldn't work if you scraped the html without scraping the art, but the default base64-encoded art would still work, despite being low print resolution).  Choices of multiple art could be hardcoded and limited to "art1.png" thru "art9.png" in the same directory as the html file.  The main purpose would be so people can print bills in multiple colors as different denominations.

2. If using my redone SVG solves the performance problem that came along with having a 4 MB SVG last time, then it would be preferable instead of encoding a PNG.  (this also enables the possibility of using SVG+CSS so that the bill color can be set programmatically)

3. I think the bitcoin address and private key should be black.  This is so it will be printed with the black toner/ink, rather than a mashup of color ink, which decreases readability.

4. the QR code as presently rendered looks great on screen but prints with major scaling artifacts (I printed with Chrome, issue could be browser specific).  They are still readable, but the quality could be better.  (If SVG+Javascript is used, then perhaps rendering the QR code by creating black squares would offer really good quality).

5. The 30-character minikey would probably be a better private key than a full 51-character code, simply for user convenience.  Many of them will end up typing them.

6. Some sort of instructions on bitaddress.org for WEB VISITORS (css @screen), explaining to them that by printing the page, they are creating their very own bitcoin address and wallet.

7. The optional choice of some instructions for those receiving PRINTED NOTES (css @print), explaining to them that by receiving the note, they have just received bitcoins and/or a bitcoin wallet, and that they can print unlimited new wallets at bitaddress.org, and that they should be aware that any bitcoins on the note are good until first redeemed by anyone, and that if they didn't print the note themselves, they should promptly move their funds elsewhere just so they can be sure they can't disappear.