Topic: [BOUNTY CLOSED] Open Source (CC) Paper Wallet Kit for safe offline coin storage - page 8. (Read 27656 times)

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.

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.

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.


Received, thank you

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

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.

4 different layouts. Parts labeled A - G.

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.

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.

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 !

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

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 think we are simply trying to address different market needs.

The defined purpose of this project is to create beautiful, pre-printed wallets on nice quality paper, which can be sold to new users. They are meant to be pretty and look valuable, because they are meant to be stored in safes or deposit boxes.

Not to say that your approach is not the right one, just that it is in a different direction from the goals of this project. I think bitaddress.org code could be easily modified (like jonis did) to print wallets using a template like yours.

Ah, thanks. I did not know that. Ok.

EVERYONE: We are printing the key PREFIX on the note. Not firstbits, that was a misunderstood term. Ju.st the first 6 characters



Well, I needed to understand the assumption behind it. At first, I did not understand the issue with "firstbits" because I was using the term incorrectly.


I was hoping to have one standardized template, multiple designs, since the template is affected by the code.

If people think we need a second, more compact template, one that has lees space for design graphics, and is more utilitarian, then we should add another template. We'll have an option in the code to pick layouts and designs.

I would like to think that the template I suggested could be used for a variety of designs, some a lot less like "money". The shape and size however are a matter of convenience for physical wallets, envelopes etc, not just copying money.


Yes, it is exactly like a ticket receipt/stub. It is intended to offer a smaller, compact backup copy of the keys. In a way, the stub is very much like your layout: compact and utilitarian. The template I proposed essentially prints a wide note and a compact copy of it on one row. The stub is to be kept in a different location.

As for the "print 2", it is possible, but more expensive than a smaller backup stub. I think people want nice graphic designs, so they want something a bit larger than your template for the main design, but also want a compact backup. That's why the template has two sizes on it.

I could be wrong of course. I really am open to suggestions, so I want to hear from more people on this!

Thanks for your feedback!

here's an example of the output from jonis' tool:

Thanks, I can reply now. The code is also available in this fork https://github.com/jonls/openpaperwallet . There are still some bugs to be sorted out but I hope this provides a good foundation. The layout is done using a style sheet that only applies when printing, therefore it will look more or less like bitaddress.org on the screen. However, when printing the layout changes to comply with whatever scheme that is decided upon (currently it is set up to the scheme proposed by acorn). When printing it is important that the browser does not add any margins to the printed page otherwise it won't fit correctly to the scheme. This can for example be accomplished in Chrome by setting "margins" to "none" in the print dialog.

We have a code contribution from a new user (jonis) who has not even been able to exit the Newbie section, but has been following with interest.

The code prints onto acorn's template. It is a great start for the code that will be part of openpaperwallet

Many thanks to jonis. If an admin can make the whitelisting happen, please do!

Code: http://jonls.dk/wallet-kit-addresses/

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

The image below shows one, used on the traditional paper wallet design. Since the private key space is a bit bigger than 1" x 1", I applied it to the public key (yes, I know there's no point in protecting it, it's just for visual demo)



As you can see, the bottom of the sticker is plastic coated so that when you scratch it off, you don't damage the print underneath. In fact, it keeps the key protected from water and other damage too. They cost only $0.05 if bought in a 1,000 roll, less for bigger orders.

I have to admit I did not understand the post above.

When I was referring to first bits, I was simply referring to showing the first few characters of the PUBLIC key in a slightly larger font, so that the note can be identified at a glance when held in a stack of similar notes.

So if the public key for the bill is: 1GE6KGzNwrh9tasmA4x15orsGr6eojh3dX, we print a QR code and this text in the blank space. Then we print the first few characters of the same text in a larger font on the front, like GE6KGz (6 characters).

There is never any IP connection or anything like that.

I may be missing something.

I've prepared some reverse-side patterns for anyone who wishes to mangle the backside of their notes.



Illustrator Swatch Files (save to your Swatches folder): Plain Version, Monogram Version

So, aantonop, Firstbits: y/n?

In a very strange turn of events, I've just returned from being locked outside on my own balcony for several hours.   I will work on making space for the public and private keys for templates tomorrow morning! Thanks for explaining, I see what you mean now.

Cheers