Bitcoin Forum

DO NOT USE OLD SAVED JAVASCRIPT from bitaddress.org

See this topic:

Bitcoin Forum > Bitcoin > Bitcoin Discussion > [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key [BOUNTY 0.1BTC]

bitaddress.org is a nice well designed web page which you can "save as HTML" and use on an air-gapped system to generate and print bitcoin addresses and importable private keys.  However, it does not (yet) have a mechanism to provide bug notices to those people who downloaded a buggy version.  (At least, the page you download should display the version number prominently and recommend that you compare that version to the current online page).

The current version is not yet well-tested.  Earlier versions can cause loss of coins in fairly rare cases (it wasn't completely untested).

Also the page should attempt to download a picture (which would say "WARNING: your computer is still connected to the internet") with the alternate text saying "Your computer might be safely disconnected from the internet but check to make sure by trying to ping google.com.  Operating your web browser in offline mode is not enough for high-value wallets.  Be sure to reboot before reconnecting."

It should also provide a link to the official distro site for a bootable live flash drive image of a secure Linux which can run the page and which will never write anything on disk and will never connect to the internet.  (Providing the image itself on bitaddress.org would be nice but is not enough for the paranoid).

Or maybe there is a way to test if Windows is using a swap file?

And also it should include a text box where you can type in random text (such as a list of the cards from a shuffled deck or throws from some dice) which it hashes and XOR's against the random number it would otherwise use.

Additional testing should definitely include looking around on disk for the private key or the printed page in various browser cache files, history lists, and saved browser tab history.

Also you shouldn't print the page using a printer on a different system which might well write the postscript to disk...

I like the idea of putting the version number in the file, I'll do it with the next version. You can compare it to the signed version history:
https://www.bitaddress.org/pgpsignedmsg.txt
You can also see which versions were taken offline because of critical bugs.


There is a wallet details tab that you can use to view details of a private key. You can always modify a few characters of a hex private key to add some extra randomness.

Since there has been a discussion about how Bitcoin addresses can be safely generated as the point sum of two public keys, you ought to consider making Bitaddress.org support creation of such addresses.  This has generated a lot of interest, and would be a relatively simple change.

The result of making the change I propose, is that someone could paste in an EC point generated from somewhere else (e.g. smartphone) and the entire sheet of paper wallets would then have "half" private keys.  (they are still full length, but they are only half of what's needed to spend the funds).

The other "half" needed to redeem the funds would be the private key used to create that other EC point.  Basically, the paper wallet would be completely immune to a compromised machine or even a fake website, as long as the attacker didn't also control the independent source of that other EC point.

In brief:

1. Allow a user to paste in a public key (which is 65 bytes).  Detect typos by verifying that X and Y are on the curve.  Recall that a public key is an EC point.

2. You generate a Bitcoin address exactly the same way - but as you are computing the Bitcoin address - right after you generate the public key (pubkey = privkey * G), you do an EC point addition, adding in the public key you were just given. (so, pubkey = privkey * G + point)

3. You encode the private key in some way that indicates that it is only half of a private key.  This clues redeemers into the fact that some other key is needed. (I would like to propose that this be signalled by using something other than 0x80 as the version byte when doing the base58 encoding, perhaps something that makes the Base58 coded number start with '6' instead of '5').

EDIT: I recommend you use the version byte 0xA2 for this purpose.  Codes will start with a 6.

I will put a bounty on it.  One of my silver coins mailed to the address of your choice.

I'm reading that thread now... your bounty has peaked my interest.