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

This needs to be average-user friendly, and while the average user can probably figure out how to print on both sides of the page given enough time and trial and error, it's a hassle.  There is also a risk they unknowingly get the two sides mismatched, resulting in a scenario where they have sent money into a black hole because the other half of "this" note was printed on the other side of "that" note they spent yesterday.

Actually, this isn't too crazy of an idea.

I have been wanting to draft a BIP for a while, which in a nutshell would propose the following:

• Unencrypted private keys should always start with '5', even if they refer to a "compressed" public key.  This means wasting "version bytes" if necessary (user mindspace is more valuable than numberspace in a version number)
• Private keys can be simply encrypted with a password, and should use a version byte that causes the key to start with a '6' (as seen by user).  The 6 (and/or the version byte) would cause a UI to ask for a password to spend the key.  "Decryption" is performed simply by XORing the given 32-bytes with the SHA256 of the password.  The length of the payload could be increased by one or two bytes to provide 8 to 16 bits of simple typo resistance, but still using a version byte that causes the string to start with a '6' - this would allow a basic level of typo detection for the password that would allow a redemption process to distinguish "wrong password" versus "no money".
• Bitcoin addresses should always start with 1, even if they are for "compressed" public keys unless they are distinctly different in a way that is meaningful to an average user - for example, an address starting with '2' if they are paying a multisig address.  The average user will never care if he's paying a compressed public key, but he might be interested in knowing whether he is paying an individual versus a scheme that may involve more than one individual.

Please reply in a new thread to discuss this topic if anyone feels it merits discussion.  I'd pay a bounty for this as well, only cause I don't think I'll get around to it.

Would it make sense to have 2 notes, one with just the public key and one with both?

What about the idea that the private key is more (cryptographically) protected?

What about if there were TWO QR codes, one on each side of paper? And you would need to scan both and XOR them to compose the private key? Or, on left and right part of banknote, and you will "escrow" passing just first part, then the second one?

Just thinking ...

I'm really liking the recent designs here. If I ever get a chance to break away from what I'm working on and be creative, I'd love to throw one into fray.

Good job guys, love the collaboration.

This ones looking rather nice.

These are looking really cool! I love the wisdom of the crowd :-)

One suggestion -- make the private key QR code smaller, and don't include the full text of the private key (maybe just first 12 letters or something).

It would be ideal if the private key QR were made in a standard size that could be easily covered by a cheap standard holographic sticker like these:

http://www.amazon.com/Square-Serial-Evident-Hologram-Stickers/dp/B0051CORIS/ref=pd_sbs_op_1

Agree, codes should be on opposite sides both for foldability and to avoid unknowingly scanning the wrong one.

How about it being "dollar" sized when freshly minted, but "credit card" sized when private key QR code is folded over?

Ooops..  this one is even better

Folding puts the private key in trouble... the crease will be an issue no ?

Love this one...

New version. As always I'm open to suggestions. Don't be afraid to criticise.

The privkey Qr-code was switched to the middle or else it will be seen trough the paper when folding the note to hide it. It shows backwards and one could always hide it with the thumb, but if it's in the middle, like it is, that won't be needed.

Also great.

Just tell the crazies that the number shown is in fact already encrypted *wink* and hence incorporated into the design.

This would be completely acceptable and even desirable.

svg xml code to create sideway text that can be created dynamicaly with javascript(?), thus easily auditable and can be saved for offline use(?).


Now i don't know if you'll be using js to create the svg and I really have no idea because I'm not a programmer. Just looked inside an svg with a text editor and grab the code.

Right, to generate pdf code and trigger a download the information would have to be passed to a backend server code (cgi/perl/php) which means it's now serverside and vulnerable to sniffing or capture. Which for a nondenominated page-printing site is perfectly fine to print out bills with blank white spots for qr and such, but with private and public keys, I can see why it's got to be native javascript, html, and styling. Means it can all be bundled up and saved offline or done without any worry of leaking your keys out.

As to design, I'd like to point out more of a credit card sized option would be good for notes, we don't need much space, and people are used to that size, pockets in wallets can be used to keep seperate from regular cash or needing to fold them, and also we don't want to press any more reason to have it imitating a 'real currency' as competition even in looks. The aspect ratio would leave room for QR fine at reasonable size for short distance reads, and font size isn't an issue for that size considering length of names and card numbers on the real regular cards already.

As far as sideways text goes, you're already using canvas which is a newer element anyway, I don't know how backward compatible the site is as it stands, with that modern level of tagging and functions you should have a few options to work with for rotating a canvas svg of text, or simply using some CSS3 with directional text alignment tags.

This won't be within the scope of the modifications I'm soliciting to Bitaddress.org - such PDF code would have to be auditable.  It would be much more sane to install a printer-to-PDF program assuming your browser/OS combination doesn't have that ability built-in.


Sideways auto-generated text may be problematic as generating it in a browser-independent fashion might be difficult.  Someone with more browser programming experience may be better suited to speak to this.  It may be possible to render the sideways text by embedding SVG directly into the DOM and manipulating it at runtime, but that's only a high-level hunch.

I think it should output the bit bills in pdf format, even for paper saving. 3 or 4 notes on each page would be ideal.

Also, won't it be a problem to have text sideways, like the one I included on my samples to show the address and private key?

I would be willing to offer a further reward if someone wants to take the reins and start modifying a copy of Bitaddress.org to start incorporating some of this artwork, using the following guidelines:

• Modify Bitaddress.org as little as possible - preferably add a single line somewhere that includes a single .js and/or .css file so that Bitaddress.org's code can be audited separately from code that adds the artwork to it.  Use the referenced file(s) to make all the changes.
• The modifications you make don't necessarily have to support EVERY one of these suggestions - in fact, a modification that supports even ANY ONE of these suggestions could be easily modified to support another - so pick one of your choice and run with it.
• Your modification should allow the user to choose from NON-DENOMINATED bills, or to enter a specific denomination of their choice.  This should be implemented by having the bill artwork itself not contain the denomination - rather, the resulting code should superimpose the denomination into the correct spot onto the bill.  An example of a way to make this work is to add something into .js that modifies the DOM that was begun by bitaddress.org to include an extra text input field where the denomination can be typed.
• Ideally, it should be possible for the user (or website operator) to substitute raster elements of the bill simply by swapping out a file that contains just that.  For example, whenever a bill is composed of a vector artwork with a raster (e.g. JPEG) background, the background ought to be a separate file (e.g. background.jpeg) while the vector portion be separate (e.g. artwork.svg) with transparency wherever the background should show.  The bill generator should superimpose the vector part over the raster part.  This, however, is not an absolute requirement, and won't apply to bills generated completely out of vector-based content - it is just something to keep in mind while designing this that will make a lot of non-techie users very happy.  An example of another thing that might lend well to substitution and should likewise be put in a separate file is a portrait (e.g. Leonardo da Vinci as a .png file with an alpha channel)
• Last but not least, do not add any dependencies on third party stuff (jquery etc.)... this is important for auditability of the code.