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

[pointbiz]

PointBiz,

What is next on your list?

Creating offline transactions from just the script hashes/indexes and private keys?
Or some multisig magic?

N1bor

I'd like to do something with split keys for the use case of savings wallets. The goal would be to have a secure paper wallet if both computers are compromised. A casual user should be able to use bitaddress.org at work and at home to print each part of the key. Keys will need to be split and matched in bulk because once you bring a key back together it is "compromised" (if you are sufficiently paranoid) and must be spent immediately to another address. Users would divide their savings up into convenient amounts so they can cash out small portions of their savings without compromising the whole amount. For example taking 1000 BTC and sending 50 BTC to 20 bitcoin addresses. You print two copies of each half key (A & B). Keep one set of copies together in a safety deposit box (A + B). Keep one half of the keys at work (A) and one half of the keys at home (B).

[1714103780]

1714103780

[1714103780]

1714103780

[1714103780]

1714103780

[pointbiz]

Another simple enhancement idea:

upon clicking the Print button, if the user has not generated new addresses since the last time he clicked it, it should tell him: "For security, new addresses will be generated before printing.  Continue?"  (OK=regenerate and print, Cancel = do nothing).

This will help avert a potential disaster if a user unknowingly prints a large batch more than once and then distributes the duplicate batches.

I realize it's of little use if the user chooses Print from his browser rather than the Print button in the page, but it's far better than nothing, and I think most users will use a Print button provided to them anyway when available, knowing it gives them the overall best chance of printing a print-friendly version.  The advanced user also maintains the option to reprint a batch if needed: he can just use the browser's Print function.

Interesting. Good usability idea.

[phelix]

Is there an Android app able to import the private key?

[pointbiz]

Is there an Android app able to import the private key?

Mtgox mobile... but the app crashes for me on jelly bean 4.1.2 used to work great on ice cream sandwich

 Also u can use mtgox.com in Chrome for Android

[pointbiz]

are there people scrutinizing these new releases to ensure there are no changes to the private key generation or presentment that shouldn't be there?

I review pull requests sent by others. On various occasions people have reported bugs in the code and version 0.1 to 0.4 are no longer online; I made the project open source and available at github at request on this thread and started the commits with v0.5.

v0.5 to v2.0 are online and I recommend you use the last version you have reviewed yourself if you read JavaScript.

Stephen Gornick checks that the online versions checksum matches what is in github.

I would like to invite others to review the safety of the code. I have attempted to arrange the code in a way that the libraries can be reviewed separately from the ninja code. I have recently refactored the wallet code such that each wallet has separate code and does not use methods from the other wallets. So reviews can be focused on the wallet you personally use.

[phelix]

Is there an Android app able to import the private key?

Mtgox mobile... but the app crashes for me on jelly bean 4.1.2 used to work great on ice cream sandwich

 Also u can use mtgox.com in Chrome for Android

not sure if kidding...   as far as I know gox mobile is not able to import bitcoin private keys.

If it is not available maybe we should suggest it to one of the app developers (bitcoinspinner, bitcoinwallet). I think it would be relatively simple for them to add this feature.

[Stephen Gornick]

not sure if kidding...   as far as I know gox mobile is not able to import bitcoin private keys.

Using "Bitcoin by Mt. Gox Mobile", v3.2 (Dec 30, 2011) for Android here's how:

At the bottom is "Transfer", then you see a tab for "Redeem".  Then click the magnifying glass to scan the QR code.  Scan, click "Redeem coins" and you're done.  The app tells you how much coin was on the address and it will automatically sweep that amount into your Mt. Gox account.  If at a later time any more funds arrive at that address, another transaction will be made to sweep them at that time as well.

Another method to redeem these keys is with Blockchain.info/wallet.  This is only done through the web interface, and not from the Blockchain for Android (or iOS) mobile app.

I just had requested this feature from EasyWallet:

One feature that would be useful would be the ability to redeem a private key.

[...]

But if Easywallet were to have this feature (to redeem a private key), I could then hand a paper Bitcoin to someone and then that person can use a mobile to go to Easywallet.org, click Redeem, scan the private key QR code and be done.  After the transaction confirms they can spend it.  That's easy!

[Stephen Gornick]

Stephen Gornick checks that the online versions checksum matches what is in github.

Oops, I'm late.

v2.0
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html

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

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


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.0"
54c26d38e68eb87ea5b083f07091b547e10f8eac v2.0 Vanity Wallet, Paper Wallet updates

$ git checkout 54c26d38e68eb87ea5b083f07091b547e10f8eac
$ git rev-list --max-count=1 HEAD
54c26d38e68eb87ea5b083f07091b547e10f8eac

$ sha1sum bitaddress.org.html
c0300a88d2de421106560185e4916f4eee6ed9df  bitaddress.org.html

[phelix]

not sure if kidding...   as far as I know gox mobile is not able to import bitcoin private keys.

Using "Bitcoin by Mt. Gox Mobile", v3.2 (Dec 30, 2011) for Android here's how:

At the bottom is "Transfer", then you see a tab for "Redeem".  Then click the magnifying glass to scan the QR code.  Scan, click "Redeem coins" and you're done.  The app tells you how much coin was on the address and it will automatically sweep that amount into your Mt. Gox account.  If at a later time any more funds arrive at that address, another transaction will be made to sweep them at that time as well.

Another method to redeem these keys is with Blockchain.info/wallet.  This is only done through the web interface, and not from the Blockchain for Android (or iOS) mobile app.

I just had requested this feature from EasyWallet:

One feature that would be useful would be the ability to redeem a private key.

[...]

But if Easywallet were to have this feature (to redeem a private key), I could then hand a paper Bitcoin to someone and then that person can use a mobile to go to Easywallet.org, click Redeem, scan the private key QR code and be done.  After the transaction confirms they can spend it.  That's easy!

thanks for explaining. that is very cool. more apps need it.

@pointbiz: sorry that I could not believe it

[casascius]

Here is a request I'd like to make:

Currently there's a page for Vanity Wallet.

It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address.  I would like this page enhanced.

Here is what I'd like changed:

1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys).  Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.

2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).

The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.

The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.)  Shipping is included.

[Red Emerald]

Here is a request I'd like to make:

Currently there's a page for Vanity Wallet.

It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address.  I would like this page enhanced.

Here is what I'd like changed:

1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys).  Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.

2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).

The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.

The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.)  Shipping is included.

This would be awesome.  That's a great bounty, too!

[dserrano5]

I forked the bitaddress.org github repo to translate it to spanish and placed the result here. My fork lives at https://github.com/dserrano5/bitaddress.org and the SHA1 of the page is 291366b7fd6f76c4242b430d8a7cb7d34079aa9a.

[Michael_S]

Hi pointbiz,

I have a request for two slight (?) (but very useful) enhancements to the javascript html file on bitaddress.org:

Both are for the "Paper Wallet" tab:

1) To offer the option of using my own private keys instead of new random ones.
2) To offer an option for reducing the size of the secret key QR code such that it can be covered by a 2.5 cm (1 inch) square hologram sticker. For this the secret QR code size should be only 1.5 cm in size, such that 0.5 cm border is left on each side where the hologram sticker can be attached to. The size of the white square surrounding the QR code could be reduced from 3 cm to 2.5 cm to match the size of the hologram sticker.
Also, when this option is checked, the private key should not be printed in plain text on the bill, and instead a place holder text could be printed, reading for example:
[For the private key see QR code in the square field labeled "Spend"]
Alternatively (if there are worries that the QR code might not be readable anymore if this small), there could be another checkbox opting for printing the plain text secret key instead of a QR code within this 1.5 cm x 1.5 cm area.


You may ask why I do not use http://print.printcoins.com/ instead of requesting this feature from bitaddress.org.
The reason is quite simple: printcoins.com uses server-side php scripts etc. to generate the printed bills, so the private keys are sent to the server (and this even unencrpted via http right now). To generated 100% safe printed bills with the "printcoins.com method" I would need to download the various source files, set up my local web server and run this code on that server on an offline PC. On the other hand, for bitaddress.org I just need to view the HTML source, copy-paste it to a single new txt (or "html") file on my PC and can run it immediately in any browser on any offline PC.

Translating all the printcoins.com stuff to javascript is probably much more work than adding the two features above to bitaddress.org's javascript html file, that's why I assume I have higher chances to get this done at this place.

With this feature, everyone would ultimately have a really easy method for generating bitcoin bills absolutely securely for purposes of private promotion/gifts/etc.

----------
Here is an illustration of how I think it should look (smaller QR code (or alternatively plain text)) and changed text next to the square:


And here is my idea how I would create a gift/promotion bitcoin paper bill, if I do not have any holograms at hand:
I use a solid-black printed square of paper (here indicated in red for illustration purposes) and attach it with 4 stripes of transparent tape (here indicated as transparent cyan coloured lines):


If I use a paper material that has a coarse surface, it shall not be possible to remove the transparent tape (and therefore view the private key) without trace.
The hand-written message/greeting/hand-written signature serves as a "pragmatic" kind of counterfeit protection.

I think this is an easy to use do-it-yourself gift/promotion bitcoin paper bill.

[kangasbros]

Both are for the "Paper Wallet" tab:

1) To offer the option of using my own private keys instead of new random ones.

I think this feature is kind of for very small niche... Just take the graphic from elsewhere and create the note yourself.

Spotted from the web: Finland-themed bitaddress.org, translated to finnish.
https://cdn.anonfiles.com/1354187274492.html

[Michael_S]

Both are for the "Paper Wallet" tab:

1) To offer the option of using my own private keys instead of new random ones.

I think this feature is kind of for very small niche... Just take the graphic from elsewhere and create the note yourself.

Of course, manually patching the bill together with a graphics program is always possible. However, the idea of solutions like bitaddress.org or printcoins.com is to simplify the job and be able to print it with little efforts and no special skills.

Moreover, I do not agree at all with the statement that this feature is for a "very small niche" only - at least not less of a "niche" than what "printcoins.com" is made for. Or one could define the Bitcoin community as a whole as a "very small niche" today, which is probably true compared to the number of people paying with EUR and USD today, so with the same argument one could justify that any development in the Bitcoin world is just useless. Similarly, any special developments within the Bitcoin world could be considered niches by themselves, since each such development may be of interest only for a subset of all Bitcoin users - So with the same argument all these things are unnecessary either. So where do you draw the line for what is a "niche" and what is not, and who decides it?

--> Instead, let's wait for an open discussion and let's not have the idea killed in advance by classifying it as a "very small niche" by some individuals who are not interested in the respective development/feature - maybe other individuals are very well interested.


I think anybody skilled in javascript can add such feature to bitaddress.org's html file - I may try to also hack this into the code myself, but I have never programmed javascript, so not sure if I can do it...

All we need is to identify the point in the javascript code where the size of the QR code is defined, and to identify the place where the random addresses are generated for the paper wallet and replace it by an interface where it is read in from a list of copy-pasted public-private-key pairs.

PS: One motivation for using non-random addresses for such paper bitcoin bills is to use vanity addresses for personalized gifts, e.g. like 1TomXjk4d93jfZT45RZEtcEtcEtcEtcEtc or whatever.

Spotted from the web: Finland-themed bitaddress.org, translated to finnish.
https://cdn.anonfiles.com/1354187274492.html

Cool ! Unfortunately I don't speak Finnish

[BkkCoins]

I think support for custom private keys is a great idea and I have an idea how it could be handled without much change to layout and interface.

There is already a bulk wallet tab. So when you choose the paper wallet maybe it can check here first and deposit the keys in that tab after completion. That also provides a way for the creator to back them up in bulk with a simple copy/paste. A slight alteration of the paper wallet code could check that tab before generating and if a series of keys/addresses is already present then it could use them to create the bills instead of generating new ones.

This way you could mix random keys, replace some with vanity keys, or take the ones from your existing wallet and paste them in to make paper bill backups. It would also possible to use a seed and have all your bills generated sequentially from the seed (eg. using an Electrum temporary wallet listing and pasting it here).

I could also see the ability to use vanity addresses useful as custom "gift certificates" for various businesses. Using this method above avoids re-designing layout and perhaps only a simple help text would let people know this is an option.

@Michael_S - I have javascript skills and can code this if you like this idea. I'd prefer to do it if it were to be accepted into the main version but I guess it's also possible as a custom version.

[Michael_S]

I think anybody skilled in javascript can add such feature to bitaddress.org's html file - I may try to also hack this into the code myself, but I have never programmed javascript, so not sure if I can do it...

@Michael_S - I have javascript skills and can code this if you like this idea. I'd prefer to do it if it were to be accepted into the main version but I guess it's also possible as a custom version.

Well, I did it! I acquired some JavaScript skills - sufficient to do the necessary changes. And I did all the features that I was mentioning a few days ago, plus more! It works very neatly, and the interface is still readable. Also thoroughly tested, works with Windows and Linux versions of FIREFOX.

All changes only affect the tab "Paper Wallet" in bitaddress.org! Here a visual impression first (screesnshot):


Main changes for the "Paper Wallet" tab in very view few words:

• Optional print of smaller priv key QR code to allow applying tamper-evident labels/holograms, plus supporting print of squares next to the bitcoin note (compare screenshot above).
• Supports own private keys entered into the interface (compare screenshot above)
• Better quality of art design embedded in the html file (96 dpi --> 192 dpi) - I took it from casascius
• Support of 10 pre-defined other designs from external *.png files (600 dpi) (=included in my package) - the designs from salfter (compare screenshot above)
• Support of specifying ANY arbitrary image on the user's PC as the art background (will be forced to a fixed aspect ratio of 1.862:1 though)
• Can enter free text for "amount" and for the center area of the bitcoin note (compare screenshot above).
• Vanity-Address generation supported (but very very slow)

--> My enhanced html file (it's basis is the bitaddress.org html file as downloaded from their website on 2 Dec 2012) can be downloaded here, and you can run it offline in standalone-mode on any suitable browser (for sure Firefox works fine while Opera runs faster as long as I keep working on the PC/browser, but Opera fails rendering correctly for the actual printouts. Other browsers not tested.).

--> My complete package (5.7 MB zip file) includes the 10 external HigRes PNG files, a 7-page illustrated documentation/tutorial, the readme and everything digitally signed.

@pointbiz: I would be happy if these changes went inside the official version of bitaddress.org! It is very nice because now everybody can plot his/her own bitcoin notes fully securely (=offline) without any need for IT expert knowledge for setting up a webserver (like printcoins.com'2 solution) or configuring scripts and working on the console (like salfter's solution), and still the notes have very good print quality (600 dpi)!

More info in the documentation or in my readme file, both of which are included in the full zip package.

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

Cheers & Enjoy printing nice Christmas presents
Michael

PS: Thanks to pointbiz (=bitaddress.org), salfter, casascius, printcoins.com and the other "printed bitcoin paper note activists and visionaries" that have inspired me and provided me with material (source code and designs) that I could build on for making this happen. What a great community!

PPS: My donation address is still unknown in the blockchain - I am wondering if and when this is going to change...  

[BkkCoins]

Wow. That's an amazing amount of goodies. I've downloaded and will give it a try. The only thing I would suggest as an improvement (I think it's a bit overwhelming for newbies), is perhaps making all the new stuff initially hidden in a fold with an "Advanced" button at top. So they can use it as before, or click "Advanced" and see all the cool things you can do.

I also suspect that having the address field may lead to serious mistakes if not used carefully. ie. people don't get the key-address alignment right and bills get printed with mismatch. Given that a key should never print with the wrong address I'm not sure that being able to paste the addresses has any benefit.

I can also see a use case for printing without private key. Retail store loads their cash register with sale slips that have addresses from the store wallet. Then during a sale the clerk can hand the slip to the customer to scan, note the sale details and place it in the register with cash as a sale, ready for end-of-day processing. So maybe an option for no key would be useful.

I'll give this a test.

[salfter]

My enhanced html file (it's basis is the bitaddress.org html file as downloaded from their website on 2 Dec 2012) can be downloaded here, and you can run it offline in standalone-mode on any suitable browser (for sure Firefox works fine while Opera runs faster as long as I keep working on the PC/browser, but Opera fails rendering correctly for the actual printouts. Other browsers not tested.).

When developing my note generator, I considered using HTML and CSS to overlay text on SVG artwork. One snag I ran across was that the printed output from Chrome looked like it was rasterized at 72 dpi or thereabouts before it was sent to the printer. Printed output from Firefox was as good as the printer could manage; the output from Chrome was clearly inferior.  Rendering to PDF from both browsers exhibited the same behavior. I suspect you might run into the same print-quality issues with your generator running under Chrome, but I haven't had a chance to test it.  If my hypothesis holds, it'd be a bit of a shame...Chrome is so much faster at running JavaScript.

(As an aside, these issues are part of what led me to shift from HTML & CSS to PostScript for layout...that, and that I'm a little bit more proficient at bending PostScript to my will. It takes browser print-quality issues out of the equation.)

[Michael_S]

Wow. That's an amazing amount of goodies. I've downloaded and will give it a try. The only thing I would suggest as an improvement (I think it's a bit overwhelming for newbies), is perhaps making all the new stuff initially hidden in a fold with an "Advanced" button at top. So they can use it as before, or click "Advanced" and see all the cool things you can do.

I had a similar idea. Did not get yet to the point to make that work... (my lack of java script skills...)

I also suspect that having the address field may lead to serious mistakes if not used carefully. ie. people don't get the key-address alignment right and bills get printed with mismatch. Given that a key should never print with the wrong address I'm not sure that being able to paste the addresses has any benefit.

Fortunately, I took precautions against this in the code, so that this dangerous outcome can never happen! (I should have mentioned it explicitly though such that the user is not afraid using this feature!) The script always checks the whole list for consistency before actually proceeding to generate the graphic outputs, QR codes etc. If a pair [private key ; BTC address] that was entered in the field does not match, then first a warning message will be displayed that the user has to click away, and then in the process of generating the notes/paper wallets (same also for the simple paper wallet w/o art design) each respective non-matchig pair will be replaced by a randomly generated pair instead. Just try it out by entering intentionally wrong BTC addresses or priv keys, and you'll see! :-)

Example:
List of Priv keys = A, B, C, D
List of BTC addresses = a, x, c, d (i.e. 2nd pair [x, C] is not consistent),
then the generated paper wallets/bitcoin notes will be
[a, A], [r, R], [c, C], [d, D],
with [r, R] being a new randomly generated key pair ("x" and "B" are discarded)

In general, you are right that there is probably no great need for the btc address field at all. My idea for including it anyway was the following: The user is able to make sure that he enters the right set of private keys, e.g. those that really match "his/her" list of vanity BTC addresses. Then he/she does not have to browse through the list of generated paper wallets/bitcoin notes and scan the list visually, but instead he/she knows for sure that if there is no warning message displayed, then all the private keys that were entered do match the BTC addresses entered.

I can also see a use case for printing without private key. Retail store loads their cash register with sale slips that have addresses from the store wallet. Then during a sale the clerk can hand the slip to the customer to scan, note the sale details and place it in the register with cash as a sale, ready for end-of-day processing. So maybe an option for no key would be useful.

Intersting idea. But this is neither a "paper wallet" nor a "bitcoin note" then, but more something like a special bank account number handed over to the client for certain purchases, if I understand this correctly. Generally I think a good idea, but I think it would also require a different design and therefore justify an extra tab in the bitaddress.org tool if this is intended to be included.

Just to get aware of the classification that we have here:

(1) paper wallets
(2) bitcoin paper notes (=bitcoin paper bills)
(3) sale slips with only BTC addresses printed on it, w/o priv keys.

Items (1) and (2) have a lot in common: Both contain public BTC address and the matching priv key on one piece. So in both cases, if you own the piece, you own everything that is sent to that BTC address. The difference is that (1) is normally intended for loading the address by the owner him/herself, while (2) is just intended for passing the piece further or spending it, although it can technically be equally well used for "purpose (1)". Also, (2) always has a denominated face value printed on it, whereas (1) typically does not (but it can say something like ">=5 BTC for example"). Also, (2) must have the private key sealed, while for (1) this is optional.

Technically, (2) is a superset of (1). If you produce a piece of type (2), it can do everything that (1) can do for you, plus something more. So I consider the amount of commonalities sufficient to justify having one common tab in the bitaddress.orrg tool for producing pieces of category (1) and (2).

On the other hand, category (3) is completely different. If I transfer BTCs to the indicated BTC address on this piece, it means that these bitcoins are NOT owned by me any more but by someone else. So type (3) kind of pieces is not a superset or subset of (1) or (2) but something completely different.

So the design should be fundamentally different to avoid confusing type (3) kind of pieces with type (1)/(2) kind of pieces:

While (1) and (2) could be designed like something that has value (like a cash note, possibly with a face value included), the design of (3) should more look like an invoice or a slip with somebody else's bank account number.