Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 28. (Read 153371 times)

First of all, great work! I am considering to use this for long term storage. How many have reviewed the code as safe? The older bugs really freaks me out, I don't want to come back in 10 years when bitcoin is worth $10k/btc just to figure out my wallet doesn't work. Is version 2.2 really safe ?

True, but the printer knows its capabilities and will render at an appropriate size.  If you're passing it a bitmap, you're stuck with either (1) sending a low-resolution bitmap that may not print with adequate quality or (2) sending a really high-resolution bitmap that most likely is overkill.  In either case, the printer will probably have to scale the image.

bitaddress.org uses the highest error-correction level (H) for its QR codes.  Private keys are thus rendered to a QR code with a 41x41 grid.  It renders each space in the grid as a 20x20 block, producing an 820x820 PNG that gets printed at approximately 1 1/16".  820/1.0625=about 771.76 dpi, which doesn't correspond to the native resolution of any printer I've heard of.  When printing paper wallets with the note artwork, scaling artifacts may be visible.  In testing with a Firefox nightly build on WinXP, printing to an HP LaserJet 1020, tops and bottoms of some elements of the QR codes have "rough" edges, most likely an artifact of a dithering algorithm somewhere in the rendering path.

There are no visible scaling artifacts in the notes generated by my script when the resulting PDF is printed from either PDF-Xchange Viewer or Adobe Reader.  (Can't say the same for the PDF viewer built into Firefox...it does an especially crappy job.  Considering the results produced above, it could be a rendering deficiency in Firefox.) My script renders QR codes to EPS and lays them out on the page with PostScript which is then converted to PDF by Ghostscript.

Just as a test, I thought I'd try combining the note image used by bitaddress.org with an SVG private-key QR code:

https://dl.dropbox.com/u/57535575/test.html

It renders on-screen and prints properly in Firefox for Linux.  On Windows, it renders properly in both Chrome and Firefox, but the QR code doesn't print in Firefox at all and prints at low resolution in Chrome.

As an aside, SVG QR codes can be generated with something like this (as was used in the preceding example):


This depends on qrencode, pstoedit, transfig, and an awk script, fix-qr-eps.awk:


The purpose of the awk script is to add a white background to the image; it edits the EPS produced by qrencode before converting it to SVG.  What it would take to do this in JavaScript, I couldn't say.

I just saw the following message from v2.2:


Should that say "multiply" not "multiple"?

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.2 (685e977461ce00ab1a0925f193463727b4d28db0) 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
d414530eea984e9ebdd40dc27af9078cd73dc3b3  -

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


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.2"
685e977461ce00ab1a0925f193463727b4d28db0 v2.2 critical bug fix for Vanity Wallet multiplication of a public key with a private key

$ git checkout 685e977461ce00ab1a0925f193463727b4d28db0
$ git rev-list --max-count=1 HEAD
685e977461ce00ab1a0925f193463727b4d28db0

$ sha1sum bitaddress.org.html
d414530eea984e9ebdd40dc27af9078cd73dc3b3  bitaddress.org.html

This is the fix to the critical bug above.

Sorry about the bug and thanks for finding it so fast. I have added unit tests to the code base to help avoid these type of bugs. I have added a specific test that shows the bug is now fixed.

The fix is now live as part of v2.2:
https://www.bitaddress.org/bitaddress.org-v2.2-SHA1-d414530eea984e9ebdd40dc27af9078cd73dc3b3.html
 - critical bug fix to Vanity Wallet multiplication of a public key with a private key.
   Bug was due to incorrect construction of BigInteger object. Which results in the incorrect
   Bitcoin Address being displayed. Therefore, v2.1 has been taken offline.
 - new translations code and initial spanish translation. Thanks to dserrano5 for translating.

I ran these numbers through my own utility for Windows and would guess it's probably a bug in the bitaddress application.  My Windows app provides the "correct" answer in all cases.

If I do Add instead of Multiply on these same numbers, BitAddress gives me output that matches my utility's output.

I can't get something to work correctly using EC Multiplication. Might be a bug, or I am doing something wrong.

Key A:
Private: B1202A137E917536B3B4C5010C3FF5DDD4784917B3EEF21D3A3BF21B2E03310C
Public: 0429BF26C0AF7D31D608474CEBD49DA6E7C541B8FAD95404B897643476CE621CFD05E24F7AE8DE8 033AADE5857DB837E0B704A31FDDFE574F6ECA879643A0D3709

Key B:
Private: 7DE52819F1553C2BFEDE6A2628B6FDDF03C2A07EB21CF77ACA6C2C3D252E1FD9
Public: 04F04BF260DCCC46061B5868F60FE962C77B5379698658C98A93C3129F5F98938020F36EBBDE6F1 BEAF98E5BD0E425747E68B0F2FB7A2A59EDE93F43C0D78156FF

Multiply Public A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB

Multiply Private A * Public B
Address: 1GvHY3ttLBc4yS9gNy8tJKxKQ5vBvBJ9Xa **Incorrect**

Multiply Private A * Private B
Address: 1HK25YbSJnfgBWGwA4uSZMnkpu6AXY17UB


Great utility, thank you PointBiz for the application!

To generate a split key there is a new feature (v2.1) in the Vanity Wallet on bitaddress.org
It requires using two computers that are not compromised by the same attacker. For example using your computer at HOME and one at WORK.

Save the bitaddress.org HTML (get it from github) and check the SHA1 hash.

Open your saved bitaddress on your HOME computer and go to the Vanity Wallet tab. Click generate on Step 1. Print the page. We will call this key pair A (which consists of public key A and private key A). Copy and paste public key A into an email and send it to yourself at WORK.

Open your saved bitaddress on your WORK computer and go to the Vanity Wallet tab. Click generate on Step 1. Print the page. We will call this key pair B. Copy and paste public key B into an input box for Step 2. Then get public key A from the email you sent above and paste it into the other input box for Step 2.

Select Add and click Calculate Vanity Wallet. You will now have a secure Bitcoin address for saving.

When you later go to combine the private keys on one computer to get your coins out of savings then spend the whole balance (aka sweep) and don't use that same address anymore for savings. Consider it compromised.

See this thread:
https://bitcointalksearch.org/topic/idea-for-highly-secure-paper-wallet-using-split-keys-114074

not really. at some point they will be squeezed into the print raster and potentially end up differently sized.

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.1 (d34b4f7f9a219293238f93507617586f5ba4db17) 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
af431934553aeef3e042e796a31ee101cdabc496  -

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


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.1"
d34b4f7f9a219293238f93507617586f5ba4db17 v2.1 Vanity Wallet add/multiply public/private keys. Code refactors.

$ git checkout d34b4f7f9a219293238f93507617586f5ba4db17
$ git rev-list --max-count=1 HEAD
d34b4f7f9a219293238f93507617586f5ba4db17

$ sha1sum bitaddress.org.html
af431934553aeef3e042e796a31ee101cdabc496  bitaddress.org.html

v2.1
https://www.bitaddress.org/bitaddress.org-v2.1-SHA1-af431934553aeef3e042e796a31ee101cdabc496.html
 - Vanity Wallet now supports adding/multiplying of public/private keys.
   Compressed keys not supported.
 - refactored wallet HTML/JavaScript to make the code more modular.
   Now it's easier to add/remove a specific wallet.
 - reusable public and private key math has been extracted to
   ninja.privateKey and ninja.publicKey
 - created unit tests

If your intent is to print a QR code, your best bet is to render it in a vector format (SVG, EPS, etc.) and let the printer scale it. The pixels will end up getting rendered as a grid of black and white squares, which can be scaled up/down to any size without losing quality.

My note generator script includes code that renders QR codes to EPS. Rendering to SVG isn't too different from that.

Ultimately I believe smartphone apps expecting to scan a bitcoin address should be tolerant of seeing a bitcoin address decorated with a URL, a URI, or pretty much anything.  They should be smart enough to see it's a string with a valid Base58Check-encoded substring... and should extract the substring and process just it.  This is easy for a program to do with confidence.

The whole idea of needing 3 QR codes is something I'd suggest making an option that most people won't need but some people will.  Ironically, despite having the opinion that "most people won't use this", I'm one of the people who will want it, because I value being able to scan bitcoin addresses with my USB handheld wedge wherever I want, and in many places, I won't want a URL cluttering it up.

exactly. QR codes are readable the best when they are aligned to full pixel/dot sizes. e.g. 6 dots per module.

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 )

Not three QR codes. Still two. It is an "either or"
--> See the prev. post in the screenshot, it shows such an example. No problem to scan them when printed out on paper - I tried with smartphone and tablet. The QR code pixels are even larger than in case of the priv. code in the small variant:

Relative QR code pixel sizes:
- Defaut bitaddress.org = 2.5
- BTC addres when incl. full URL of blockchain.info or blockexplorer.com: 1.75
- Priv QR code in the small variant: 1.4 (smallest size implemented)
- Still readable with Galaxy Ace smartphone: 1.1

PS: in most applications, it is not the idea to add funds to that address, but rather to take the funds from that address (like voucher). So having the "http://etc" inside the QR code is a win in user comfort when checking the balance. The drawback is that if someone wants to add funds to that address with a smartphone app like "bitcoinspinner", he/she needs to copy the address out of the URL string after scanning. But as said, that's not the idea in most cases.
And anyway - that feature is OPTIONAL. It is still possible to print the old-fashioned QR code (this is even the default).

but it makes loading more difficult. three qr codes???

I still could not resist. here is yet another update, version 5 6 6b --> NOW 10.

UPDATE: Version 6 with small improvement in inter-browser-interoperability for the load/save feature.

UPDATE 30 Nov 2013: Get Version 10 (GPG signed zip file) of my tool with mBTC denomination support and some cleanups! (11.8 MByte)

My main concern was that there are so many settings now that one would like to save the complete set of settings in the GUI.
--> Now, you can!
Also, I added some German-language stuff (text templates and reverse-side-"INFO"-design).

Changes in Version 5:

HTML File:
* Added a feature to save and load all the settings on the "Paper Wallet" tab.
* Added German language templates for the text to be displayed on the note

Zip-container:
* some sample settings text files included that contain complete GUI settings - can be loaded
  into the GUI with the HTML file's new feature by simple copy-paste into the GUI's "settings"
  text box.
* Added reverse side German language designs of the bitcoin note for the version
  with the infos for newbies.
* Version history included

Screenshot Version 5:



I think now I am REALLY done - this was my VERY last one!

Delta-Screenshot of Version 6:


Change in Version 6:
* Final fix of a browser-interoperability problem (affects mutual exchange of setting strings
  on Linux between [old] firefox and Opera). Background:
  - On Linux, Opera saves line-breaks to \r\n, not to \n, when saving settings to the text box
    and copying to clipboard.
  - However, old firefox on Linux converts \r\n to \n\n when loading settings from the text box.
  This implies that then saving settings in an Opera instance of this tool and loading them back
  into firefox, all line breaks will get converted to TWO successive line breaks!
  This version of the tool is able to autodetect this situation 100% reliably and correct it
  automatically, without the user taking any notice of it. Behaviour will always be correct!
  Note: In version 5 of this tool there was a similar check implemented already, but it required
        some user interaction to remove the extra line breaks, and "false alarms" were sometimes
        possible.
* NOTE: The Parameter settings format has changed between versions 5 and 6!
        If you have created some setting files with version 5 and want to use them in version 6,
        edit them in a text editor as follows:
        1) At the very beginning of the string,
           replace <-VERSION5-> by <-VERSION6-><-MICHASNEXTPARA->
        2) Add one line break just after "<-VERSION6->", i.e. before the first <-MICHASNEXTPARA->

Change in Version 6b (mainly bugfixes):
* saving the GUI state of one of the selection boxes failed due to a copy-paste error in the
  source code. Fixed.
* The load/save of the GUI settings now by default keeps the "private keys"/"btc addresses"
  fields untouched. Some dialog still allows you to deviate from this new default behavior (the dialog
  only appears when applicable, so you do not get bothered by extra dialogs in the normal case).
* spelling errors and sub-optimum layouts fixed in a few of the selectable text templates.

I could not resist. here is yet another update, version 4. I think all the user requests of the previous posts are taken into account, and more than that (that you did not think of yet, maybe)!

It has lots of new useful feature, and I also fixed artifacts of some of the rear-side designs and also slightly improved the text content at that occasion. All in the new zip container, as usual:
http://dl.dropbox.com/u/18219492/Bitcoin/bitaddress-org_Michael_S_enh_v4-zip.zip

UPDATE 30 Nov 2013: Get Version 10 (GPG signed zip file) of my tool with mBTC denomination support and some cleanups! (11.8 MByte)

First the screenshot, then what is new...:



Don't worry about the yellow and red traces, this is just the result of the (optional!) overlaid watermark demo file, one new feature in version 4! You can define any file to function as a watermark file, thereby personalizing your own prints (don't publish your watermark file digitally of course!). This should make counterfeiting more difficult, as opposed to the situation if everybody uses exactly the same design.

More new feature (hope I don't forget any):

• BTC address QR code can now optionally defined to show not only the address, but the complete blockexplorer.com or blockchain.info URL of that address. This makes it MUCH easier for newbies, and also much faster for experts, to look up the balance of the bitcoin note with a smartphone, because upon scanning a URL, the browser will automatically pop up and you see the balance instantly without doing anything!
• The colors of the face values (denominations) at the bottom left and top-right are now automatically changed if you select a different design. This is very nice! The colors match the color scheme of the respective design and are therefore well suited. You can still set your own color of course and can also deactivate that feature if you want. (also remember the "glow" feature from version 3. Personally, I prefer having it activated at the top-right and deactivated at the bottom-left, like in the screenshot above.)
• Text templates are prepared for a number of different purposes that the bitcoin note can be used for. Just see yourself. I invented some fully fictional names to illustrate the use, like Ronny Paulus, Henry Fiat, Abrahamovic L., Jonny B. Cashedy or the Jekyll & Isle Ltd. Company   Feel inspired to print bitcoin notes for your own purposes.
• Finally I found out where in the source code to change the vertical gap between the 3 prints per page (I just had to replace one "height: auto;" by "height: 290px;")! Now it should be easier to cut them out, they are not that close any more!
• Rear-side designs overhauled and improved - improved content and artifacts removed (too narrow line spacing cut off the lower parts of letters like y, g, etc.)
• In the GUI, the "Activate Advanced Design Features" checkbox did not always do what the user supposed it to do in version 3. Now I re-organised the GUI without changing the function of that checkbox, such that now everything is logical and reasonable.

I thing now I am really done - this was my last one!

PS: I think the whole tool is intuitive, and in most cases the "?" buttons are not really needed by the average user. However, should one user lack some information or wants some deeper insight, he/she will in all probability find the needed (deeper) information behind the respective "?"-Help-Button.

You could set the default user-definable text to just, "This voucher will expire on December 31, 2099".

This will look a lot cleaner.  The far-in-the-future date says to the user, "you can replace this text by typing something else here" implicitly, instead of explaining it to them in more words than needed.  And if they print that date, then no harm no foul!