[BOUNTY CLOSED] Open Source (CC) Paper Wallet Kit for safe offline coin storage

[aantonop]

ATTENTION:

We are still working on the layout. Until that is done, any designs submitted will have to be reworked. Please help us make a great layout that works for many uses. Let's get that right first, then we can all design graphics to it

Please do not submit designs yet! (though they are amazing). Help us figure out the layout and security features. If this is to be a successful open project it has to support a number of designers and different styles/uses. For that, we must get consensus!

Recent discussions have uncovered a couple of flaws we need to address:

It would be great if we had 1-1/2" x 1-1/2" stickers. But we don't, we have ones that are too small or too big. So we need ot be creative about how and where we position the things that need to be secret, including human readable versions of the private key for recovery.

Thank you for your patience and for the feedback!

See my next post for thoughts on layout

[aantonop]

Putting together the template to include space for the base58 keys now. For the full private key, are you going to be using another of those 1x1" stickers to cover it?

 

I have not yet decided on the size of the stickers. I can get 1" x 1", 2" x 2" and 2" x 1/2" easily. Other sizes more tricky.
I was hoping to use one size sticker for everything, so I don't have to manage stock of different stickers.

I see two or three approaches:

a) We use larger scratch-off stickers and re-design the template for 2" x 2" areas which contain more information (QR *and* text in the same square). Bigger stickers, but only two of them, one on note, one on stub

b) We use two different sticker sizes: 1x1, and a longer one that fits a line of text 2" x 1" or 3/8" by 2-1/2".

c) We stay with the smaller stickers (1" x 1"). We use only two of them. On the left, we print the private as a QR and cover it. On the stub we print the private key as text in 4 rows, and cover it. No other text for the private key anywhere. For QR scanning, use the note. If things don't go well, your backup stub has a human readable key on it, not a QR.

Another thought: The load-key (public) is completely unnecessary on the stub. We can use that space better, perhaps put the public prefix there.

Acorn, if you do any new template drafts, could you please label the areas as A, B, C, D, (including the text areas) so we can then refer to them as "on A, put QR of private key".


As you hopefully see, I am indeed open to suggestions and feedback. In this case a correction has led to a necessary re-design for a safer wallet.

It will make this a bit of a longer project, but I think it is worth it. Getting the template right is CRITICAL to success and partiicipation.


Thank you !

[acorn]

I have not yet decided on the size of the stickers. I can get 1" x 1", 2" x 2" and 2" x 1/2" easily. Other sizes more tricky.
I was hoping to use one size sticker for everything, so I don't have to manage stock of different stickers.

I see two or three approaches:

a) We use larger scratch-off stickers and re-design the template for 2" x 2" areas which contain more information (QR *and* text in the same square). Bigger stickers, but only two of them, one on note, one on stub

b) We use two different sticker sizes: 1x1, and a longer one that fits a line of text 2" x 1" or 3/8" by 2-1/2".

c) We stay with the smaller stickers (1" x 1"). We use only two of them. On the left, we print the private as a QR and cover it. On the stub we print the private key as text in 4 rows, and cover it. No other text for the private key anywhere. For QR scanning, use the note. If things don't go well, your backup stub has a human readable key on it, not a QR.

Another thought: The load-key (public) is completely unnecessary on the stub. We can use that space better, perhaps put the public prefix there.

Acorn, if you do any new template drafts, could you please label the areas as A, B, C, D, (including the text areas) so we can then refer to them as "on A, put QR of private key".

I think Approach A isn't going to work out so well, because if you had a 1x1 QR in a 2x2 space you have two choices for QR placement: in a corner, and fill the rest of the space with the base58 key, or put the QR in the middle, and have the base 58key wrapping around. Both result in the base58key being placed all willy-nilly into that space.

Approach B might work out, but it means more work for you. If we went this route, the private key would probably look best with a 2x1 with QR on top and the base58 below it wrapped in about 5 lines to fill the space.

Personally I'm fond of approach C because it gives the stub a little more purpose and leaves less visual clutter on the note. Don't want/have a QR code reader? Fine, make sure you keep the stub. If you don't mind just using the note, then don't bother with the stub.

I'm sure other people may feel otherwise. In any case, I'll put together a mockup of how approaches B and C might look, with labelling on it so we can discuss it clearly.

[aantonop]

There may be other approaches, as we were helpfully and recently reminded.

I am also leaning to (c) obviously, let's keep it at the mockup level until we get more feedback.

[acorn]

4 different layouts. Parts labeled A - G.

[aantonop]

Wow this really helps! Nice work!


My preferred choice is (1) -  modified by replacing section B, with a full-size area B, as it is in (3).


I'll call the keys L(oad) and S(pend) - easier to remember.
Suffix: q = QR, b = base58, p = prefix (only first 6 of base58)

So, I can define a layout based on this template like this:

Basic: A=Lq, B=Lb, C=Sq  (A = Loading QR, B= Loading base58, C= Spending QR).

Basic with stub: A=Lq, B=Lb, C=Sq, E=Lp, F=Lq, G=Sq
Basic with stub and human-readable: A=Lq, B=Lb, C=Sq, E=Lp, F=Sb, G=Sq
etc. etc.


Not finalized yet though, don't take my word for it....

I want to hear more comments. I think this layout would be good for an M-of-N key with it split between C, F, G... Let's see what other have to say.

[aantonop]

BOUNTY PAID

For the record:

Bounty Payment

Payment of 4BTC to acorn, in addition to the 1BTC paid earlier

Total Bounty: 10BTC
Paid so far:

- acorn: 5BTC

Remaining:

Second design/code/site bounty: 2.5BTC
Third design/code/site bounty: 2.5BTC


A

[acorn]

My preferred choice is (1) -  modified by replacing section B, with a full-size area B, as it is in (3).

I'll call the keys L(oad) and S(pend) - easier to remember.
Suffix: q = QR, b = base58, p = prefix (only first 6 of base58)

So, I can define a layout based on this template like this:

Basic: A=Lq, B=Lb, C=Sq  (A = Loading QR, B= Loading base58, C= Spending QR).

Basic with stub: A=Lq, B=Lb, C=Sq, E=Lp, F=Lq, G=Sq
Basic with stub and human-readable: A=Lq, B=Lb, C=Sq, E=Lp, F=Sb, G=Sq
etc. etc.

This would be the layout you mentioned. In the case of basic layout with human readable stub, the user would need three scratch-off stickers to cover the Sb x2 and Sq.

I like this layout as well, but I guess let's see if there are any other votes before we decide on the final layout.

BOUNTY PAID

For the record:

Bounty Payment

Payment of 4BTC to acorn, in addition to the 1BTC paid earlier

Received, thank you

[acorn]

Second design/code/site bounty: 2.5BTC
Third design/code/site bounty: 2.5BTC

Design refers to background graphics or template layout?

I believe this refers to background graphics since the template layout is something we're trying to figure out and standardize so that all the background graphics can fit in it.

[jonls]

acorn, is it possible for you to provide measurements (in mm or inches) for your templates so I can update the code that generates the overlay to fit perfectly to the new suggestions? I would need to know the width and height of the boxes (A, B, C, ..) and also the offset of the top left corner relative to the top left corner of the note.

[acorn]

acorn, is it possible for you to provide measurements (in mm or inches) for your templates so I can update the code that generates the overlay to fit perfectly to the new suggestions? I would need to know the width and height of the boxes (A, B, C, ..) and also the offset of the top left corner relative to the top left corner of the note.

Most certainly. I'm just at my office right now and will post the measurements when I get home from work. Please note though -- I'm not sure if we've all agreed that this template is the way to go. I like it, and Aantonop likes it, but I think we were waiting for some commentary from the rest of the community with any concerns or questions about the layout.

For the top-left corner offset, do you mean the offset of the top left corner of the note relative to the top left corner of the entire page?

[jonls]

For the top-left corner offset, do you mean the offset of the top left corner of the note relative to the top left corner of the entire page?

I mean the top left corner of each element relative to the note but the size of the margins would also be useful.

[TheMildChaos]

Made a little attempt at creating a design, though it did take quite a while to get it to the point where I was satisfied with how it looked.

https://i.imgur.com/HmV6Vmi.png

[Timbo925]

New Design. More color and little bit slicker and also made a back this time.  
Based on the latest template template. Printed it out on some heavy paper (300g/m²) and looks really good imo.

Back could be used to keep a ledger of how much btc is stored on the wallet.

Front:


Back:

[acorn]

For the top-left corner offset, do you mean the offset of the top left corner of the note relative to the top left corner of the entire page?

I mean the top left corner of each element relative to the note but the size of the margins would also be useful.

Sorry for the delay.

All placement coordinates refer to the position of the top left corner.

Placement of first note on page: 0.5, 0.5 inches from PAGE’S top left corner.

The following are relative to the NOTE’S PAGE'S top left corner.

A PLACEMENT: 0.75, 0.685 inches
A DIMENSION: 1 x 1 inches

B PLACEMENT: 2, 0.685 inches
B DIMENSION: 2.75 x 0.2 inches

C PLACEMENT: 5, 1.8 inches
C DIMENSION: 1 x 1 inches

E PLACEMENT: 6.437, 0.685 inches
E DIMENSION: 0.2 x 1 inches

F PLACEMENT: 6.8125, 0.685 inches
F DIMENSION: 1 x 1 inches

G PLACEMENT: 6.8125, 1.8 inches
G DIMENSION: 1 x 1 inches

This layout is repeated vertically so that four notes fill the page.

Each note is 2.5 x 7.5 inches, so the
second note would start at 0.5, 3 inches from the PAGE’S top left corner;
third at 0.5, 5.5 inches;
fourth at 0.5, 8 inches.



Hope that's what you wanted. I will upload an updated version of the template .ai file within 24 hours, though everyone who submitted a design since I last posted shouldn't have anything to worry about or change anything -- the height of area B and the width of area E changed by only a fraction of a fraction of an inch.

[aantonop]

I was away for a week on vacation. I can't express how amazed I am to see that the community work continued without even a tiny pause. This is awesome!

Given all the progress I'd like to announce the final stretch for this project:

TWO WEEKS LEFT

Next Friday (April 19th), will be the final day for the bounty. I will award any remaining funds on that day. This is because I intend to do the first PRODUCTION print run during the last week of April for shipment in May.

Here's what needs to happen next:

1) Final submission of all graphic designs based on the final template and dimensions.  (By Apr. 19)
2) Selection of the winners for the two remaining bounties (On Apr 19)
3) Finalization of the software for layout and graphic selection (jonis and I, by Apr 19)
4) Selection of the designs to include in the OpenPaperWallet repository, licensing and upload (by Apr 22)
5) Selection of the ONE design that will be printed in the first production run (by Apr. 22)
6) OpenPaperWallet site and repository launch (by Apr. 26)
7) First production run (week of Apr 29).
8 ) Free samples shipped to designers and anyone interested and contributing to this thread (me by May 15th).
9) First commercial paper wallet kit available for sale online (me by May 15th)
10) Reseller kits shipped to resellers (me by May 30th).

It's the final countdown!

[canton]

I received the security stickers today. These are the 1" x 1" security scratch-off that will be applied to protect the private key.

These look great and I think it's a superb solution to keeping the private key secure.

Have you experimented to make sure you can't use a bright laser pen or other high intensity light source to transmit enough light through the scratch-off material to see (scan) the QR code on the other side?

I've been working on a folded-style paper wallet and someone suggested this might be a problem. I was skeptical, but after some experiments I was absolutely able to reveal some details that I believed would be obfuscated behind multiple layers of paper & ink.



The thing I'm especially interested in re: the scratch-off stickers is how they might protect against water damage when the keys are printed using an inkjet printer. Have you run some tests in that regard, seeing how a scratch-off covered inkjet-printed QR code survives when wet?

Here are the fairly horrifying results from my own experiments to this end:

[aantonop]

Great test. I'll do a test on the sticker too ASAP.

The sticker itself has a transparent plastic coating under the scratch-off stuff. That covers the QR and protects it. I think it will also protect from water. The sticker material is the same used for lotto/scratchoff cards, but they are printed on thick cardboard.

We have a couple of proposed solutions for these issues:

1) A backup stub so you have two copies (one of which will survive water by being... elsewhere).
2) A human readable key - not just QR code, in the backup stub. Even severely smudged, I think you can retrieve 30 characters better than a QR code.
3) Pre-printed bills, offset printing. The QR codes will be home-printed, but the background colors will not bleed. Much of the damage in your photos seems to be from the green bleeding, rather than the black fading.
4) Heavy paper, hard to shine light through
5) Wax coated/matt paper may actively repel water but "hold" ink.
6) Acid free, archival quality paper, so it doesn't discolor with light, oxygen or age.
7) Patterned complex background behind QR codes to obscure/confuse scanners and CCD sensors.

I welcome more suggestions and will run some quality tests to see how the stickers help (or not).

great contribution!

[canton]

I have not realized this is not already case. You are right, having the full address (and key!) is a must (at least in my use case).

It's possibly too late to jump in since the template appears to be finished, but I wanted to second this opinion. I think -- as unwieldy as they are -- that the full public address and the full private WIF should be displayed in regular old human alphanumeric. One thing that's elegant about a paper wallet is that it reduces the amount of technology required to keep a balance. I don't like the idea of requiring any more technology than is absolutely necessary to recover that balance.

I even advocate multiple copies of the address/key in human readable form, like how serial numbers on US currency are repeated twice in opposite sides of the bill. Though in the case of USD I believe the reason for this is so that you can't tape the halves from two different bills together and claim it's one complete piece of currency.

[acorn]

I don't like the idea of requiring any more technology than is absolutely necessary to recover that balance.

Awesome demo photos. I'm not sure what printing process aantonop is using for the sheets but I would hope that it uses inks that won't run when wet. whoops I see he answered this as I was typing.

Using the human-readable with stub style example, both the private and public keys will be available in alphanumeric characters, for those who prefer to not deal with QR to load/redeem.