I am meeting with printing companies today to start conversations. I'll ask about perforation, but here's what I know already:

- These services are called "bindery", which includes cutting, folding, stitching, foil, numbering or other post-print features.

- It costs about $10-$15 per CUT LINE. So if instead of 5, we want 10 lines, it means an extra $50. Not a huge deal, on a $500-$2000 print run.

- There are different types of perforations, depending on the shape and size of the cut. Shapes like "[", "|","L" repeated.

- Micro-perforation is a marketing term for finer cuts.


The biggest thing to find out is the accuracy they can deliver.

The other thing to keep in mind is that a perforation has width. Not much, but some. So the edge will be frayed after tearing even with a micro-perforation die. If you've received a payment cheque in the mail, the type that have a printed statement stub on half the page and a cheque on the other half, you have seen what the industry calls "micro-perforation". It's not as good as an exacto knife.

Very good suggestions proff!

Indeed, it is meant for the newbie, not even the average user. Once you have more than say $500 you want to keep it offline, so that's the target customer/user.

My initial thought was to have the user download the software from openpaperwallet.com, go offline, run it and print. A key part of this project will be the user instructions, which I am writing now and will hope to get help illustrating.

Now, if people think that download-offline-print is too insecure or prone to hijacking, we could add USB keys into the retail product, but that would be up to individual resellers.

Since I hope to be the first reseller of these as kits, let me ask the community here: USB stick or download?

I will definitely need some WordPress help.

Heroku is free, so alternative would have to also be free. The whole package (WP+store+bitpay modules) will be open, so if people want to host on VPS or AWS or elsewhere, that's easy to do.

I have tested three store products now and they all work, with varying levels of success:

a) Wordpress + Wordpress E-Commerce + Bitpay (fiat prices or bitcoin prices, bitcoin payment)
b) Wordpress + Woocommerce + Bitpay (fiat prices or bitcoin prices, bitcoin payment)
c) Wordpress + ECWID + Bitpay  (fiat prices, bitcoin payment).

I have deployed a test store for emorydunn (link in private message). Anyone else want to try one of the above stores, send me a PM and I will deploy it for you. They take about 1 minute to deploy.

I don't think a professional offset printer will have any problem handling 1/8 inch accuracy on printing or the perforation die-cut. They can achieve 1/64 on the color alignment and at least 1/16 on the cut.

Users may have problems aligning printers as accurately, which is why I was planning to include a few calibration sheets.

Any changes to the template have to be weighed against:

a) The work acorn has already done and will need to re-do
b) The work the other designers have done and will need to re-do
c) The relative value of the change.

If changing the template will make this easier or better, let's do it. I cannot accurately judge how much work it will be, but you give good reasons to consider.

I think rather than making changes, we should first test out some of these issues. You see to like testing the hypotheses (which is great!).

Who is able to run a couple of tests to check if a regular home printer can align a print onto a specific area accurately enough to avoid problems with the "bleed" margins?

One last point: I personally believe there is no need or purpose for the PUBLIC key on the stub, for two reasons. Firstly, you don't need to load a wallet often, It's better to make a new one for security. Secondly, you can recreate the public key from the private key import. So having the private WIF is enough to get the receiving address back. I'd rather have two copies of the private WIF on the stub to double my chances of recovery, than waste one space for a public key I won't use. I have about 100 paper wallets right now and I have never used the public key twice. I have however, had difficulty with one QR code already from a smudge. So my personal experience says two private keys, no public on the stub.

Exactly: easy, secure and beautiful paper wallets, pre-printed so you can add the keys.

How much would you pay?

Pricing Considerations

I am putting together some price estimates for a retail paper wallet "kit", containing the following:

- Instructions
- Software for printing the keys
- 10 sheets of pre-printed, perforated notes (offset printing, heavy archival paper)
- 4 sheets of test-templates on plain laser paper for calibration
- 120 x security stickers
- 40 x plastic sleeves

The kit would allow you to print and secure 40 paper wallets. Estimated wholesale COST of the kit: ~ $10 for production runs of less than 5000 sheets.

Questions for the thread:

1) Is this the right "size" for a starter kit, or should it be smaller/bigger?
2) Would you buy such a kit, if yes, how much would you pay? (min/max range please)
3) What are the top 3 reasons you would buy rather than DIY?
4) Would you want to sell such a kit, if yes, how much would you charge retail to make it worthwhile? (range please)


Any and all feedback welcome!

Great suggestion for plastic sleeves.

A bit of googling and I found several collector's sites selling archival sleeves to keep currency:

http://www.jpscorner.com/currency-sleeves.html

I am thinking of including a ring-binder and 3-note plastic holders (Pro Kit), or a pack of single note sleeves (Basic Kit).

I can add them to the basic kit for about USD0.05 (5 cents) each, or $2 for 40. Would you pay $2 to have 40 special sleeves included in a paper wallet kit?

If Adobe Illustrator does Measurement Guides, we should use them for the template. If not, I can do it in AutoCAD. They look like this, showing the exact position from which you are measuring.

|<---- 5 3/8 in ---->|

There are special holographic stickers that project a woven image over barcodes if photographed or scanned, making them impossible to read. I plan to include some in the "Pro" kit I will sell.

Overall, the security of paper wallets is as much a matter of process as it is a matter of technology. A big part of this project will be the instructions for users that will help them implement the process of paper wallets securely. These instructions should address issues of off-line software, printer "memory", suitable ink, storage options (wall-safe etc), considerations for fire/water, suggestions for backup storage etc. These instructions are what will take the security technology provided and elevate it to a secure process.

By the way, the more bitcoin rises, the worse this problem gets... I need more paper wallets to spread the value, so as to spread the risk of loss. I can't have a 10BTC wallet - that's insane ($2000 on one piece of paper? No thanks). I need 100 x 0.1 BTC instead. A year from now, I will need to spread the same risk to 1000 x 0.01 BTC. More notes means more opportunities for errors and accidental disclosure or loss, which in turn makes the process itself more important.

The final agreed template has two blocks in the backup stub so that it can be printed in the "Basic with Human-Readable Backup Stub" layout.

All the designs will accommodate printing that mode.

My personal preference is that be the default layout - the backup stub has no public key (you can generate it from the private if you need), but has TWO versions of the private key - one as a QR and one as human-readable. That offers the greatest recoverability, with three possible places to recover: the main note QR, the backup QR and the backup-backup human readable.


The final template is the one that supports what you ask for, I think we're good!

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!

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!

There's a project to build better open paper wallets. It includes a backup key stub for secondary storage and will be printed commercially on durable, acid free archival quality paper. Security stickers will protect the code and human-readable keys from water damage, light and prying eyes.

The project is moving quite fast - I estimate the first production run in less than one month.

What is a gethub?

bitaddress.org runs offline. Does it have a variable error rate QR coder (it has a coder capable of different size code, that's for sure).

This is a great idea. There's a URI scheme.

How is semantic web implemented? Is it RDF? It's been a while since I looked at it.

Exactly as r.willis said.

Ideally, we would also implement a very small and lightweight protocol validation engine in Lisp and use that as reference implementation the for the protocol, and for interoperability, quality and eventually security certification.

At some point, "Talks Bitcoin Protocol" needs to be a verifiable statement, as with other protocol implementations. That way, a developer can test and validate that their client implementation passes all interop tests and speaks official "bitcoin".

Just like you can do W3C validation, or test an SSL client for protocol completeness, we should be able to test a bitcoin protocol node against something.

Instead of having people manage bitcoind better, we need more full-node clients that adhere to a reference protocol.

So that people can swap in other node clients to server JSON/RPC to GUI clients.

A single reference implementation for the node, without a standardized protocol, means there is no reference. It's just "whetever the current bitcoind speaks, is the protocol". That's a terrible recipe for stability. Assuming that every peer is a bitcoind, because of course it almost always is, only helps to ensure that you can never develop a non-bitcoind node. It's like trying to hack FAT or Windows SMB networking and build a compatible client.

We need a Gnutella like protocol group. The reference standard should be the protocol, not a lump of C++ code.

Check out the Open Bitcoin Store initiative I started.

It is building a complete turnkey bitcoin store for merchants - open source, free and free to host.

I am using a combination of WordPress + ecwid cart + bitpay merchant gateway + Heroku or other WP hosting.

It is very easy to setup, free for up to 10 products and I'm building a store-wizard that will take a store name and launch it all for you

The goal: Non-technical user => mini bitcoin store in less than an hour, for free.