How would you like to design a bitcoin banknote?

[unclemantis]

Mike,

Check this link out.

http://www.advlaser.com/Preprinted-Checks-for-Quicken-QuickBooks-s/6.htm

[midnightlightning]

There seems to be a bug. In the QR-code field of the private key is the public key, so both QR-codes are the same and are reflecting the public key. The private key in text format is correct.

Whoops, stupid error. Fix pushed to the repo now.

[unclemantis]

There seems to be a bug. In the QR-code field of the private key is the public key, so both QR-codes are the same and are reflecting the public key. The private key in text format is correct.

Whoops, stupid error. Fix pushed to the repo now.

Hey! Guess what!?

When you click print, just the QR codes appear!

[unclemantis]

There seems to be a bug. In the QR-code field of the private key is the public key, so both QR-codes are the same and are reflecting the public key. The private key in text format is correct.

Whoops, stupid error. Fix pushed to the repo now.

Hey! Guess what!?

When you click print, just the QR codes appear!

Now back to the idea I brought up with Mike about preprinted checks.

Thoughts!?

[World]

EDIT: Working version of BitAddress.org code with Psy's banknote backgrounds: https://github.com/MidnightLightning/bitaddress.org

very nice BTC service +1

[midnightlightning]

Hey! Guess what!?

When you click print, just the QR codes appear!

Hey! Guess what!?
Turn on "print background images" in your browser's print popup and the full banknote appears! 

Of course the caveat to that is that Google Chrome doesn't have that option for the user to enable. I did add the CSS triggers to force it to do so from the page side, so that browser should be working now too.

[ThomasV]

I made this some time ago:

[unclemantis]

Hey! Guess what!?

When you click print, just the QR codes appear!

Hey! Guess what!?
Turn on "print background images" in your browser's print popup and the full banknote appears! 

Of course the caveat to that is that Google Chrome doesn't have that option for the user to enable. I did add the CSS triggers to force it to do so from the page side, so that browser should be working now too.

+1

[cbeast]

can anybody post all 4 bills in one post so it is easier to vote?

Voting is finished, though the four candidates are collected here in the "call to vote" post by casascius.

I think I have just about got the reward payout scheme just about finalized.  And the gracious donation of 10BTC, I think I am going to say should go to the person who successfully marries the BitAddress.org codebase with the SVG version of what is pretty much certainly the first-place winner: the banknote presented to us by Psy.

I plan to tackle integrating this with BitAddress.org's code, though it won't be the SVG version, since the QR code generation on BitAddress.org uses HTML Canvas elements, not SVG elements. So there's two ways to go on this: use the existing BitAddress.org QR library and draw the full banknote as a canvas element (using JPEG/PNG version of the banknote background; output would be a canvas element, which the browser would render as JPEG or PNG. Might be less quality on a print) or find a new QR library that can generate SVG output (could print higher res) rather than canvas (or modify the existing QR library to be SVG; haven't checked to see how hard that is...).

EDIT: Working version of BitAddress.org code with Psy's banknote backgrounds: https://github.com/MidnightLightning/bitaddress.org

YA BABY! Freaking awesome!!!!! I have been waiting for this!

Very cool. You have given me a reason to go buy a new color print cartridge.

[pointbiz]

Working draft for v1.7:
https://www.bitaddress.org/bitaddress.org-v1.7-SHA1-.html
- Using the SVG with the small dimensions from Psy's downloads (795px wide).
- At this moment you need Ubuntu fonts installed on your system for it to look proper. Meaning it's not using WebFonts.
- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.
- Please note this is unsigned work and SVGs are capable of including JavaScript!


I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size. Also, there is a CSS oddity where Chrome is rending the private QR Code a few pixels more to left than Firefox or IE9....

[Domrada]

That is really slick having it integrated with bitaddress.org.  Thanks!

[unclemantis]

Working draft for v1.7:
https://www.bitaddress.org/bitaddress.org-v1.7-SHA1-.html
- Using the SVG with the small dimensions from Psy's downloads (795px wide).
- At this moment you need Ubuntu fonts installed on your system for it to look proper. Meaning it's not using WebFonts.
- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.
- Please note this is unsigned work and SVGs are capable of including JavaScript!


I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size. Also, there is a CSS oddity where Chrome is rending the private QR Code a few pixels more to left than Firefox or IE9....

You changed your mind I see! AWESOME!

+1

[unclemantis]

Hey Mike! Have you thought about what it would take to get the background note preprinted at one of those Checkq places?

[pointbiz]

Working draft for v1.7:
https://www.bitaddress.org/bitaddress.org-v1.7-SHA1-.html
- Using the SVG with the small dimensions from Psy's downloads (795px wide).
- At this moment you need Ubuntu fonts installed on your system for it to look proper. Meaning it's not using WebFonts.
- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.
- Please note this is unsigned work and SVGs are capable of including JavaScript!


I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size. Also, there is a CSS oddity where Chrome is rending the private QR Code a few pixels more to left than Firefox or IE9....

You changed your mind I see! AWESOME!

+1

Thanks.

I think you are thinking about the AES encrypted private keys feature you requested. I've always wanted to do an artistic paper wallet but I have no artistic skills I'm happy that Casascius procured this public domain design.

[a5an0]

Working draft for v1.7:
https://www.bitaddress.org/bitaddress.org-v1.7-SHA1-.html
- Using the SVG with the small dimensions from Psy's downloads (795px wide).
- At this moment you need Ubuntu fonts installed on your system for it to look proper. Meaning it's not using WebFonts.
- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.
- Please note this is unsigned work and SVGs are capable of including JavaScript!


I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size. Also, there is a CSS oddity where Chrome is rending the private QR Code a few pixels more to left than Firefox or IE9....

Awesome. Doing a big print run now 

[unclemantis]

Working draft for v1.7:
https://www.bitaddress.org/bitaddress.org-v1.7-SHA1-.html
- Using the SVG with the small dimensions from Psy's downloads (795px wide).
- At this moment you need Ubuntu fonts installed on your system for it to look proper. Meaning it's not using WebFonts.
- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.
- Please note this is unsigned work and SVGs are capable of including JavaScript!


I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size. Also, there is a CSS oddity where Chrome is rending the private QR Code a few pixels more to left than Firefox or IE9....

You changed your mind I see! AWESOME!

+1

Thanks.

I think you are thinking about the AES encrypted private keys feature you requested. I've always wanted to do an artistic paper wallet but I have no artistic skills I'm happy that Casascius procured this public domain design.

Oh ya, About the AES thing. I am sure you will get around to it EVENTUALLY Thank you again for the paper integration

[midnightlightning]

- Check the "Art?" checkbox on the Paper Wallet tab to see the SVG art wallet. It is a 4MB SVG external download via iframe.

4 megabytes? Ouch that's a big download. I might take a look at optimizing that SVG for web use, and see how hard it is to add in the Ubuntu font within it, since it's not a standard font for all OSes.

But in the meantime, I wrote my own Data URI encoder, so saved out a much higher quality JPEG of the banknote (377 Kb, rather than 100 Kb), which should be good for most at-home printing.

I also updated my branch to use HTML Canvas elements for the complete banknote! This means no browser CSS issues or needing to use browser-specific transforms to get the address text to go vertical.

I feel the public and private QR codes should be the same ratio... so at this moment the white boxes are not the correct size.

But the two addresses are different lengths; You've got more text to encode with a private key, so the QR code has more rows/columns. Forcing their outer dimensions to be the same means the private key's cells are smaller.

One change I made to my version's QR code is to reduce the error-correcting level of the QR codes. The bitaddress.org code has it at level "H", the highest error-correction possible. Since the original display of that site has the QR codes rather small, that seems like a good idea. However, I've been working with QR codes for a few years now at my day job for print publications, and one non-intuitive thing I've found is that when a QR code has to be printed small, it actually works better to decrease the error-correcting, since that means there's less rows/columns to the code, making the overall cells of the code larger and easier for scanners to see. If you adhere to the other QR design guides (black on white (not white on black), and a border of white around (4 "cells" wide suggested)), having a lower error correction for a handheld print piece is better. If there's a glare or a bad angle to scan from, the user can just take the print piece to better lighting and scan there (For a billboard or poster setting, where the users can't control the lighting or it might get damaged, higher error correction is better).

Since these banknotes use black on white, and are fairly large, I've dropped the error correction down to "M" (medium), and ensured there's a two-cell blank border around the codes (Yes, the suggestion is four, but the background color of the banknote around that border is pretty light and the codes pretty large, so shouldn't be an issue).

Give it a try and see what you think: https://github.com/MidnightLightning/bitaddress.org

[ErebusBat]

How will the error correction from H=>M effect damage from being folded or perhaps water damage (ink jet)?

[midnightlightning]

How will the error correction from H=>M effect damage from being folded or perhaps water damage (ink jet)?

A single fold from an optical perspective would add a line to the glyph, though the shadow of the fold would likely not be as dark as the black ink of the QR code itself, so shouldn't interfere, especially if there's perpendicular lighting illuminating the note. Severe crumpling could make the square edges of the QR code cells look wavy, but once calibrated, a QR reader generally looks at the centers of each cell for their color, rather than the edges, so if the cells are large enough, it compensates for a blurred edge.

If water (or some other solvent) moves the ink from a black cell to a white cell, it might move enough ink to make the white cell appear dark enough to register as "black". But again, the size of the cells will determine how much movement of the ink is needed for that to happen, and larger cells make it less likely there's enough movement to incorrectly register that cell as "black".

Generally "H" error correction means 30% of the cells could be modified and still recover the data (except for the calibration cells), and "M" means 15% of the cells could be modified. So even if a water droplet landed on the QR code and blurred some cells, it would likely be <10% of the code, and still be readable regardless of if it were "H" or "M". Though, I'll do some tests with my home inkjet and see what I come up with.

[casascius]

Practically speaking, even if the QR code is demolished beyond cooperation with a reader, if you can still read the human-readable private key with your own eyes, you're going to be able to recover the coins.