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

[BkkCoins]

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.

Not really a problem as with the current design the portion with key can just be cut off. The person printing would still own the funds but the customer uses it as a pay slip - simply an easy way to say "pay here" instead of needing a smart phone to present a QR code. eg. at a restaurant your bill may come with such a slip or be printed with one by enabled POS system. I just saw this tool as an existing and handy way someone could make use of. Perhaps there is other uses for a keyless bill.

Thx. for the detailed response.

[Michael_S]

Here are photos of my first self-made hologram-free DEMO bitcoin paper note (or bitcoin paper bill) (it still contains the default text of my enhanced version of the bitaddress.org tool)

Printed with my old black&white laser printer plus an orange text marker and finished acc. to my own specifications (except that I used only 4 staples instead of 8 due to lack of space):

Fully sufficient for private purposes/promotions/gifts, I would say. Click photos to enlarge.

Front side:
     

Reverse side:
     


Equipement:
- Ubuntu 8.04
- Firefox 3
- Brother MFC monochromatic laser printer
- A pair of scissors
- "tesa film" transparent adhesive tape
- stapler w/ 4 staples
- an orange text marker

[Michael_S]

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.

Not really a problem as with the current design the portion with key can just be cut off. The person printing would still own the funds but the customer uses it as a pay slip - simply an easy way to say "pay here" [...]

Great idea - I did not see it that way! And in the "amount" field the printing person could put the amount that the customer has to pay. Nice use of this indeed - payslip instead of cash note.

And works without any further change, example:

[Michael_S]

[...]
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.

Apparently Chrome is optimised for paperless work...  

Interestingly, Firefox is able to display svg files correctly when I enter its path in the URL line, but when I enter the same path as "Full path of image file" in my enhanced bitaddress.org tool, it does not get rendered on the screen (with png instead of svg it works fine in either case).

In contrast, with Opera it is rendered in all cases (on the screen) - but Opera has the printer rendering problems...

Anyway - with png files everything works perfectly fine with my Firefox Browser GUI-based open source bitcoin note printing software suite ;-) - just a little slow (but not painfully slow) with javascript.

[Michael_S]

I am thrilled to announce an update: My 2nd version is available here (now 9.3 MB zip file size):

http://dl.dropbox.com/u/18219492/Bitcoin/bitaddress-org_Michael_S_enh_v2-zip.zip

Main changes:

• Now Denominations on the bottom left / top right are supported
• added Casascius designs (5 pieces) on top of the 10 from salfter: Different color flavours, and there is the horizontal "bar" at the bottom at the "amount", which is missing in salfter's version (it depends on personal taste)
• added possibility to include own designs without the need to change one line of source code in the html file. Simply call your files "0.png" to "9.png" and you can start straight away.
• some slight fixes in the treatment of entering own addresses&keys - behaviour is more logical now in the case that some wrong addresses were entered, or if there are more items in the list than what the parameter "Addresses to generate" says. (So this is already fine-tuning of the tool, as you can see...)
• In the fields for denomination and amounts, underscores are replaced to no-break-spaces, i.e. this way you can "move" your denomination number to the right as much as you want so that it gets nicely centered to the place where you would like it to be. The default entries, if you start the tool, demonstrate what can be done, so no need for special tutorial etc. - just look at the default settings, modify and try out...

Screenshot:


PS: For the reverse side design, have a sneak here (all included in the zip file): https://bitcointalk.org/index.php?topic=92969.msg1386215#msg1386215

[phelix]

I am thrilled to announce an update: My 2nd version is available here (now 9.3 MB zip file size):

http://dl.dropbox.com/u/18219492/Bitcoin/bitaddress-org_Michael_S_enh_v2-zip.zip

Main changes:

• Now Denominations on the bottom left / top right are supported
• added Casascius designs (5 pieces) on top of the 10 from salfter: Different color flavours, and there is the horizontal "bar" at the bottom at the "amount", which is missing in salfter's version (it depends on personal taste)
• added possibility to include own designs without the need to change one line of source code in the html file. Simply call your files "0.png" to "9.png" and you can start straight away.
• some slight fixes in the treatment of entering own addresses&keys - behaviour is more logical now in the case that some wrong addresses were entered, or if there are more items in the list than what the parameter "Addresses to generate" says. (So this is already fine-tuning of the tool, as you can see...)
• In the fields for denomination and amounts, underscores are replaced to no-break-spaces, i.e. this way you can "move" your denomination number to the right as much as you want so that it gets nicely centered to the place where you would like it to be. The default entries, if you start the tool, demonstrate what can be done, so no need for special tutorial etc. - just look at the default settings, modify and try out...

Screenshot:


PS: For the reverse side design, have a sneak here (all included in the zip file): https://bitcointalk.org/index.php?topic=92969.msg1386215#msg1386215

I like the higher resolution and the custom text option. Thanks!

Want to use bills like these when introducing people to Bitcoin and maybe as geocaching treasures.

[BkkCoins]

The problem with any of these printed bills with tamper proof or black overlay is that someone who compromises the bill can just use bitaddress to produce a new replacement that isn't compromised but with no balance. This is the side effect of it allowing a custom input key. (But any hacker could get around by making a hacked version, so I'm not saying it shouldn't be available.)

That issue should be considered for any usage where the overlay/tamper proof sticker is readily available. And also the issue that a recipient may not know what should be the correct tamper covering.

[Michael_S]

The problem with any of these printed bills with tamper proof or black overlay is that someone who compromises the bill can just use bitaddress to produce a new replacement that isn't compromised but with no balance. This is the side effect of it allowing a custom input key. (But any hacker could get around by making a hacked version, so I'm not saying it shouldn't be available.)

That issue should be considered for any usage where the overlay/tamper proof sticker is readily available. And also the issue that a recipient may not know what should be the correct tamper covering.

True - should therefore never be used for higher amounts than pocket money.

Just to confirm: When you wrote this:
   "This is the side effect of it allowing a custom input key."
- you were referring to your own earlier proposal of an additional feature that enables printing notes with BTC address only and w/o public key, right? Note that this is currently not possible with the tool (but of course any hacker could add this feature to it).

PS: In fact anyone can now reproduce these bills easily. So whoever produces it should add some own issuer attributes to the note to at least make it more difficult/not worthwhile for someone to reproduce it, like e.g.:
- personalized design
- Hand-written Signature
- Personal/Company stamp
- personalized rear side
- or a combination of these

[Michael_S]

I am thrilled to announce an update: My 2nd version is available here (now 9.3 MB zip file size):

http://dl.dropbox.com/u/18219492/Bitcoin/bitaddress-org_Michael_S_enh_v2-zip.zip

Main changes:

• Now Denominations on the bottom left / top right are supported
• added Casascius designs (5 pieces) on top of the 10 from salfter: Different color flavours, and there is the horizontal "bar" at the bottom at the "amount", which is missing in salfter's version (it depends on personal taste)
• added possibility to include own designs without the need to change one line of source code in the html file. Simply call your files "0.png" to "9.png" and you can start straight away.
• some slight fixes in the treatment of entering own addresses&keys - behaviour is more logical now in the case that some wrong addresses were entered, or if there are more items in the list than what the parameter "Addresses to generate" says. (So this is already fine-tuning of the tool, as you can see...)
• In the fields for denomination and amounts, underscores are replaced to no-break-spaces, i.e. this way you can "move" your denomination number to the right as much as you want so that it gets nicely centered to the place where you would like it to be. The default entries, if you start the tool, demonstrate what can be done, so no need for special tutorial etc. - just look at the default settings, modify and try out...

Screenshot:
<IMAGE-removed-in-this-quotation>

PS: For the reverse side design, have a sneak here (all included in the zip file): https://bitcointalk.org/index.php?topic=92969.msg1386215#msg1386215

I like the higher resolution and the custom text option. Thanks!

Thanks, glad to hear it is of use for others! Always happy  to hear what others have done with it, e.g. if someone has created a Christmas gift with it or something like that...

Want to use bills like these when introducing people to Bitcoin and maybe as geocaching treasures.

GEOCACHING TREASURES --> THAT's indeed a very good Idea I think!!

[BkkCoins]

Just to confirm: When you wrote this:
   "This is the side effect of it allowing a custom input key."
- you were referring to your own earlier proposal of an additional feature that enables printing notes with BTC address only and w/o public key, right? Note that this is currently not possible with the tool (but of course any hacker could add this feature to it).

No. I was referring to being able to supply the private key as input for printing a bill. In the past it was randomly generated and so impossible to reprint a replacement bill (except of course by someone who alters the code, which is always available to a hacker).

[casascius]

Someone could also just do Copies: 2 in the print dialog or any other number.

Preventing someone from supplying their own keys isn't going to enable anything not yet possible

[BkkCoins]

Someone could also just do Copies: 2 in the print dialog or any other number.

Preventing someone from supplying their own keys isn't going to enable anything not yet possible

I wasn't referring to someone making multiple copies. I meant someone who received the printed bills could remove any tamper sticker or overlay, remove the balance, then print a new bill using the same private key, apply a new sticker or overlay, and pass the bill off as original. It wasn't as easy to do this before because they would need to modify the code the use a given private key.

My only point here is that people should not trust bills like this at face value even with tamper proof stickers. You may as well just use pokemon stickers or whatever is handy.

The same could be said for coins if the tamper proof stickers were easy to get and print a first bits on but I think that is difficult.

[casascius]

Someone could also just do Copies: 2 in the print dialog or any other number.

Preventing someone from supplying their own keys isn't going to enable anything not yet possible

I wasn't referring to someone making multiple copies. I meant someone who received the printed bills could remove any tamper sticker or overlay, remove the balance, then print a new bill using the same private key, apply a new sticker or overlay, and pass the bill off as original. It wasn't as easy to do this before because they would need to modify the code the use a given private key.

My only point here is that people should not trust bills like this at face value even with tamper proof stickers. You may as well just use pokemon stickers or whatever is handy.

The same could be said for coins if the tamper proof stickers were easy to get and print a first bits on but I think that is difficult.

How would this attack be better for an attacker who has the means to make new bills versus just making n copies of a new bill, funding it once, and spending it in n different places?  Why bother matching the key of some other bill?  It is just a random number.

[fivemileshigh]

Bug/feature request:

when printing the non-tamper-proof version, the top-right denomination covers up a bit of the plaintext private key, see example:



Michael, could you also make another change? I would like to see a cutting guide (plain square box) around the plaintext private key, to make it easier to cut it to the same size as the qr code box. I would also like the qr code be left at the original size, for easier scanning. Along with printing the back of the bill with the provided pattern I would think this would be plenty tamper proof enough for the small amounts likely to be found on these bills. I would tape the whole face of the bill with wide scotch tape, like you did with your bill earlier. This is likely as tamper-proof as the hologram idea, and probably more durable overall.

Really paranoid types like me can also place a small piece of foil or other opaque materials in between the plaintext and qr code to provide extra protection against scanning with a strong light. Just enough of the qr needs to be blocked out, not the whole thing, right?

[Michael_S]

Bug/feature request:

when printing the non-tamper-proof version, the top-right denomination covers up a bit of the plaintext private key, see example:

(In the IMG tag of your post, I changed the "https" to "http" and more importantly the "www" to "dl" such that your public dropbox image gets displayed here!)

Here's how you can get around it:
In the field "Denomination (top-right)" you can enter
   "<font size=1>____________</font>5", or similarly
   "<font size=2>_________</font>5", or similarly
   "<font size=4>_______</font>.
I thought that this was clear from the example of the pre-configured content in this field, which is
   "<font size=1>_</font>500".
This was actually the reason for me pre-configuring it with that content - to lead the user towards using the input correcty.
But maybe I should enter a note saying that "_" gets converted to non-removable " ".

You can put any amount of "blanks" there to move the denomination to the right. However, since more than one successive blank gets removed in HTML text rendering by the browsers, you enter underscores instead of blanks, which are converted to non-removable space ("&nbsp;" to be precise) internally by the tool, so non-removable blank characters (&nbsp;) get rendered. So you have full control to shift the denomination as much to the right as you like.

Michael, could you also make another change? I would like to see a cutting guide (plain square box) around the plain-text private key, to make it easier to cut it to the same size as the qr code box.

The "cutting guide" is already there! Just cut out along the line! (for the "black" squares: you may decide for yourself if you cut out closely along the solid black square or along the outer thin line.)

Note that the "plain-text private key square" does NOT have the same size as the QR code but it is intentionally a little larger than that (ca. 18 mm as opposed to 15 mm)! The reason is that it should PROTECT the QR code when you cover the whole thing with a hologram sticker. If it was exactly the same size, it would be very very difficult to line up exactly, and you would very like damage the QR code with the hologram sticker if you assemble your note.
That's why some margin in size is needed. The hologram then has a size of 2.54 or 2.85 cm (depending which one you purchase), i.e. there is still a lot of space left at the edges such that the hologram can be properly attached.

So you see - everything is thought out well! :-)

I would also like the qr code be left at the original size, for easier scanning. Along with printing the back of the bill with the provided pattern I

Request rejected! ;-)
The reason for plotting SMALLER QR codes in the first place was to be able to cover the QR code with above sized hologram that can be purchased easily. With the original sized QR code that is not possible, because even larger square holograms are not readily available on the market  - the largest standard sizes are 1 inch and 1.125 inch, to what I know (and if they were available, even larger ones would not look nice).

About the ease of scanning: The 15 mm size is well enough for scanning. I tried it out myself: I printed out QR codes of smaller sizes as well (and I have a rather old and cheap laser printer Brother MFC-7820N), and my cheap smartphone "Samsung Galaxy Ace" could scan it very well down to a size of 11 mm, so there is a 36% margin in size for the 15 mm chosen! Also the error protection was good: When I drew a few lines across the 15 mm QR code, the smartphone was still able to detect the right code, so I am convinced that 15 mm is a good choice. And if it still does not work to scan it, you have still the plain-text private key in the sealed pocket as fall-back, so ...

...again - everything is thought out very well! :-)


@fivemileshigh QUESTION: What browser and operating system did you make your screenshot from? (I used firefox 3 on Linux and firefox 13 and 14 under Windows - everywhere same result). It seems that your browser positions the denominations a little bit higher than my browser does. In my case the denominations at the bottom-left and top-right are exactly lined-up with the respective BTC symbol.

[fivemileshigh]

I think you've covered my questions quite well Michael, thanks. Tip sent.

It was Firefox 12 on OSX 10.6.8. Safari doesn't render well because I have the min font size set to 12, FF is "stock".

[BkkCoins]

Here's how you can get around it:
In the field "Denomination (top-right)" you can enter
   "<font size=1>____________</font>5", or similarly
   "<font size=2>_________</font>5", or similarly
   "<font size=4>_______</font>.
I thought that this was clear from the example of the pre-configured content in this field, which is
   "<font size=1>_</font>500".
This was actually the reason for me pre-configuring it with that content - to lead the user towards using the input correcty.
But maybe I should enter a note saying that "_" gets converted to non-removable " ".

Is there no way to use text-align right to avoid all this?

[Michael_S]

Here's how you can get around it:
In the field "Denomination (top-right)" you can enter
   "<font size=1>____________</font>5", or similarly
   "<font size=2>_________</font>5", or similarly
   "<font size=4>_______</font>.
I thought that this was clear from the example of the pre-configured content in this field, which is
   "<font size=1>_</font>500".
This was actually the reason for me pre-configuring it with that content - to lead the user towards using the input correcty.
But maybe I should enter a note saying that "_" gets converted to non-removable " ".

Is there no way to use text-align right to avoid all this?

Good idea - I will do it like that!

Anyway, the usage of "___" will be needed if one wants to move the number a little away from the BTC symbol, especially for one-digit denominations it may otherwise look a little imbalanced.

[Michael_S]

I think you've covered my questions quite well Michael, thanks. Tip sent.

It was Firefox 12 on OSX 10.6.8. Safari doesn't render well because I have the min font size set to 12, FF is "stock".

Thanks a lot for the tip! My first earnings in BTC  

Interesting to know about OSX Firefox... maybe it would be good to be able to move the position of the denominations up and down a little from the user's side. But this is CSS based, which is static as far as I know (I don't want to use php etc. of course, this should remain purely html&javascript based), but maybe I do it by defining several style sheet templates (e.g. 5 or so) and then select based on some user input parameter one of them to allow more optimum positioning of the denominations....

[casascius]

I would also like the qr code be left at the original size, for easier scanning. Along with printing the back of the bill with the provided pattern I

Request rejected! ;-)
The reason for plotting SMALLER QR codes in the first place was to be able to cover the QR code with above sized hologram that can be purchased easily. With the original sized QR code that is not possible, because even larger square holograms are not readily available on the market  - the largest standard sizes are 1 inch and 1.125 inch, to what I know (and if they were available, even larger ones would not look nice).

About the ease of scanning: The 15 mm size is well enough for scanning. I tried it out myself: I printed out QR codes of smaller sizes as well (and I have a rather old and cheap laser printer Brother MFC-7820N), and my cheap smartphone "Samsung Galaxy Ace" could scan it very well down to a size of 11 mm, so there is a 36% margin in size for the 15 mm chosen! Also the error protection was good: When I drew a few lines across the 15 mm QR code, the smartphone was still able to detect the right code, so I am convinced that 15 mm is a good choice. And if it still does not work to scan it, you have still the plain-text private key in the sealed pocket as fall-back, so ...

...again - everything is thought out very well! :-)

I thought I saw a checkbox that re-enabled the original size when I played with it and this wasn't even an issue?  By the way, thanks for this fantastic contribution to the community!  This alone takes paper notes a huge leap ahead.

Just thought I'd provide some input: that 36% margin in size is dependent on a lot of things that are not guaranteed.  The smaller the code, the more damage if something happens to it.  Laser toner is notorious for flaking off certain kinds of paper when creased or for no reason at all.  Someone else's printer may have poorer print quality than yours, or may have an ink cartridge that leaves black or white streaks, or may be using a print technology (e.g. dye sublimation) that makes beautiful photographs but has a hard time with black-to-white edge transitions.

On the other hand you might have a perfectly readable QR code but a user can't read it because his mediocre smartphone can't focus on the code as close as it needs to be for the smaller dots to be made out.  Quite simply, there are advantages to letting the QR code occupy the available space rather than leaving white space the user doesn't want on the assumption that there's no advantage to do it any other way.