Topic: How would you like to design a bitcoin banknote? - page 13. (Read 94820 times)

I made a couple minor revisions myself to the Bitcoin-note.svg file that I had.  It can be obtained at https://casascius.com/bitcoin-note.svg.zip, and is now 1128210 bytes (uncompressed).  Note that I might have a different revision than you, so some of the changes I made might not make sense relative to yours.

I did the following:

• REMOVED the embedded png's.  They are gone, nothing replaces them.  Oh well.  That's why the file is smaller.
• I uncovered the "Strength in Numbers" text, which was actually present in the file but covered over by solid objects that looked like scribbling.  The text is actually comprised of letter shapes, so there's no dependency on the Ubuntu font.
• I added labels "Load/Verify Balance" and "Spend (Private Key)", using letter shapes rather than a font.
• The white "bitcoinbitcoinbitcoinbitcoin" stripe wasn't present in this file, so I added it (also converted the letters to shapes, so it's not a font)

I'm not an artist by any means, but these manipulations were well within what I could do.

EDIT: fixed link

I don't have much experience with SVG any help making it smaller would be appreciated. We could look into what Casascius said about the base64 encoded PNGs.

I'll take a look when I get some time.

I meant that the white space reserved for the private key should be bigger. If you look in the code I posted I use the same multiplier to make the QR Code canvas bigger. That's what I meant by ratio.

I have not tried changing the error correction level maybe that alleviates the issue. Not sure of the pros/cons of reducing the error correction level other than what you've stated.

However the argument could be made that if the QR code is that damaged then the human readable key may be as well.

However these are not intended for long term carry around storage.

That being said I have been carrying some around in my wallet since early on... I will pull them and see how damaged they are.

I don't believe the art should actually be that large - and is only that large because it contains base64-encoded PNG graphics that ought to be vectorized.  Vector graphics ordinarily are pretty slim on space.

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.

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.

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

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.

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

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

Awesome. Doing a big print run now 

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.

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

You changed your mind I see! AWESOME!

+1

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

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

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

+1

I made this some time ago:

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.

very nice BTC service +1