Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 30. (Read 153371 times)

No. I was referring to being able to supply the private key as input for printing a bill. In the past it was randomly generated and so impossible to reprint a replacement bill (except of course by someone who alters the code, which is always available to a hacker).

Thanks, glad to hear it is of use for others! Always happy  to hear what others have done with it, e.g. if someone has created a Christmas gift with it or something like that...

GEOCACHING TREASURES --> THAT's indeed a very good Idea I think!!

True - should therefore never be used for higher amounts than pocket money.

Just to confirm: When you wrote this:
   "This is the side effect of it allowing a custom input key."
- you were referring to your own earlier proposal of an additional feature that enables printing notes with BTC address only and w/o public key, right? Note that this is currently not possible with the tool (but of course any hacker could add this feature to it).

PS: In fact anyone can now reproduce these bills easily. So whoever produces it should add some own issuer attributes to the note to at least make it more difficult/not worthwhile for someone to reproduce it, like e.g.:
- personalized design
- Hand-written Signature
- Personal/Company stamp
- personalized rear side
- or a combination of these

The problem with any of these printed bills with tamper proof or black overlay is that someone who compromises the bill can just use bitaddress to produce a new replacement that isn't compromised but with no balance. This is the side effect of it allowing a custom input key. (But any hacker could get around by making a hacked version, so I'm not saying it shouldn't be available.)

That issue should be considered for any usage where the overlay/tamper proof sticker is readily available. And also the issue that a recipient may not know what should be the correct tamper covering.

I like the higher resolution and the custom text option. Thanks!

Want to use bills like these when introducing people to Bitcoin and maybe as geocaching treasures.

I am thrilled to announce an update: My 2nd version is available here (now 9.3 MB zip file size):

http://dl.dropbox.com/u/18219492/Bitcoin/bitaddress-org_Michael_S_enh_v2-zip.zip

Main changes:

• Now Denominations on the bottom left / top right are supported
• added Casascius designs (5 pieces) on top of the 10 from salfter: Different color flavours, and there is the horizontal "bar" at the bottom at the "amount", which is missing in salfter's version (it depends on personal taste)
• added possibility to include own designs without the need to change one line of source code in the html file. Simply call your files "0.png" to "9.png" and you can start straight away.
• some slight fixes in the treatment of entering own addresses&keys - behaviour is more logical now in the case that some wrong addresses were entered, or if there are more items in the list than what the parameter "Addresses to generate" says. (So this is already fine-tuning of the tool, as you can see...)
• In the fields for denomination and amounts, underscores are replaced to no-break-spaces, i.e. this way you can "move" your denomination number to the right as much as you want so that it gets nicely centered to the place where you would like it to be. The default entries, if you start the tool, demonstrate what can be done, so no need for special tutorial etc. - just look at the default settings, modify and try out...

Screenshot:


PS: For the reverse side design, have a sneak here (all included in the zip file): https://bitcointalksearch.org/topic/m.1386215

Apparently Chrome is optimised for paperless work...  

Interestingly, Firefox is able to display svg files correctly when I enter its path in the URL line, but when I enter the same path as "Full path of image file" in my enhanced bitaddress.org tool, it does not get rendered on the screen (with png instead of svg it works fine in either case).

In contrast, with Opera it is rendered in all cases (on the screen) - but Opera has the printer rendering problems...

Anyway - with png files everything works perfectly fine with my Firefox Browser GUI-based open source bitcoin note printing software suite ;-) - just a little slow (but not painfully slow) with javascript.

Great idea - I did not see it that way! And in the "amount" field the printing person could put the amount that the customer has to pay. Nice use of this indeed - payslip instead of cash note.

And works without any further change, example:

Here are photos of my first self-made hologram-free DEMO bitcoin paper note (or bitcoin paper bill) (it still contains the default text of my enhanced version of the bitaddress.org tool)

Printed with my old black&white laser printer plus an orange text marker and finished acc. to my own specifications (except that I used only 4 staples instead of 8 due to lack of space):

Fully sufficient for private purposes/promotions/gifts, I would say. Click photos to enlarge.

Front side:
     

Reverse side:
     


Equipement:
- Ubuntu 8.04
- Firefox 3
- Brother MFC monochromatic laser printer
- A pair of scissors
- "tesa film" transparent adhesive tape
- stapler w/ 4 staples
- an orange text marker

Not really a problem as with the current design the portion with key can just be cut off. The person printing would still own the funds but the customer uses it as a pay slip - simply an easy way to say "pay here" instead of needing a smart phone to present a QR code. eg. at a restaurant your bill may come with such a slip or be printed with one by enabled POS system. I just saw this tool as an existing and handy way someone could make use of. Perhaps there is other uses for a keyless bill.

Thx. for the detailed response.

I had a similar idea. Did not get yet to the point to make that work... (my lack of java script skills...)

Fortunately, I took precautions against this in the code, so that this dangerous outcome can never happen! (I should have mentioned it explicitly though such that the user is not afraid using this feature!) The script always checks the whole list for consistency before actually proceeding to generate the graphic outputs, QR codes etc. If a pair [private key ; BTC address] that was entered in the field does not match, then first a warning message will be displayed that the user has to click away, and then in the process of generating the notes/paper wallets (same also for the simple paper wallet w/o art design) each respective non-matchig pair will be replaced by a randomly generated pair instead. Just try it out by entering intentionally wrong BTC addresses or priv keys, and you'll see! :-)

Example:
List of Priv keys = A, B, C, D
List of BTC addresses = a, x, c, d (i.e. 2nd pair [x, C] is not consistent),
then the generated paper wallets/bitcoin notes will be
[a, A], [r, R], [c, C], [d, D],
with [r, R] being a new randomly generated key pair ("x" and "B" are discarded)

In general, you are right that there is probably no great need for the btc address field at all. My idea for including it anyway was the following: The user is able to make sure that he enters the right set of private keys, e.g. those that really match "his/her" list of vanity BTC addresses. Then he/she does not have to browse through the list of generated paper wallets/bitcoin notes and scan the list visually, but instead he/she knows for sure that if there is no warning message displayed, then all the private keys that were entered do match the BTC addresses entered.

Intersting idea. But this is neither a "paper wallet" nor a "bitcoin note" then, but more something like a special bank account number handed over to the client for certain purchases, if I understand this correctly. Generally I think a good idea, but I think it would also require a different design and therefore justify an extra tab in the bitaddress.org tool if this is intended to be included.

Just to get aware of the classification that we have here:

(1) paper wallets
(2) bitcoin paper notes (=bitcoin paper bills)
(3) sale slips with only BTC addresses printed on it, w/o priv keys.

Items (1) and (2) have a lot in common: Both contain public BTC address and the matching priv key on one piece. So in both cases, if you own the piece, you own everything that is sent to that BTC address. The difference is that (1) is normally intended for loading the address by the owner him/herself, while (2) is just intended for passing the piece further or spending it, although it can technically be equally well used for "purpose (1)". Also, (2) always has a denominated face value printed on it, whereas (1) typically does not (but it can say something like ">=5 BTC for example"). Also, (2) must have the private key sealed, while for (1) this is optional.

Technically, (2) is a superset of (1). If you produce a piece of type (2), it can do everything that (1) can do for you, plus something more. So I consider the amount of commonalities sufficient to justify having one common tab in the bitaddress.orrg tool for producing pieces of category (1) and (2).

On the other hand, category (3) is completely different. If I transfer BTCs to the indicated BTC address on this piece, it means that these bitcoins are NOT owned by me any more but by someone else. So type (3) kind of pieces is not a superset or subset of (1) or (2) but something completely different.

So the design should be fundamentally different to avoid confusing type (3) kind of pieces with type (1)/(2) kind of pieces:

While (1) and (2) could be designed like something that has value (like a cash note, possibly with a face value included), the design of (3) should more look like an invoice or a slip with somebody else's bank account number.

When developing my note generator, I considered using HTML and CSS to overlay text on SVG artwork. One snag I ran across was that the printed output from Chrome looked like it was rasterized at 72 dpi or thereabouts before it was sent to the printer. Printed output from Firefox was as good as the printer could manage; the output from Chrome was clearly inferior.  Rendering to PDF from both browsers exhibited the same behavior. I suspect you might run into the same print-quality issues with your generator running under Chrome, but I haven't had a chance to test it.  If my hypothesis holds, it'd be a bit of a shame...Chrome is so much faster at running JavaScript.

(As an aside, these issues are part of what led me to shift from HTML & CSS to PostScript for layout...that, and that I'm a little bit more proficient at bending PostScript to my will. It takes browser print-quality issues out of the equation.)

Wow. That's an amazing amount of goodies. I've downloaded and will give it a try. The only thing I would suggest as an improvement (I think it's a bit overwhelming for newbies), is perhaps making all the new stuff initially hidden in a fold with an "Advanced" button at top. So they can use it as before, or click "Advanced" and see all the cool things you can do.

I also suspect that having the address field may lead to serious mistakes if not used carefully. ie. people don't get the key-address alignment right and bills get printed with mismatch. Given that a key should never print with the wrong address I'm not sure that being able to paste the addresses has any benefit.

I can also see a use case for printing without private key. Retail store loads their cash register with sale slips that have addresses from the store wallet. Then during a sale the clerk can hand the slip to the customer to scan, note the sale details and place it in the register with cash as a sale, ready for end-of-day processing. So maybe an option for no key would be useful.

I'll give this a test.

Well, I did it! I acquired some JavaScript skills - sufficient to do the necessary changes. And I did all the features that I was mentioning a few days ago, plus more! It works very neatly, and the interface is still readable. Also thoroughly tested, works with Windows and Linux versions of FIREFOX.

All changes only affect the tab "Paper Wallet" in bitaddress.org! Here a visual impression first (screesnshot):


Main changes for the "Paper Wallet" tab in very view few words:

• Optional print of smaller priv key QR code to allow applying tamper-evident labels/holograms, plus supporting print of squares next to the bitcoin note (compare screenshot above).
• Supports own private keys entered into the interface (compare screenshot above)
• Better quality of art design embedded in the html file (96 dpi --> 192 dpi) - I took it from casascius
• Support of 10 pre-defined other designs from external *.png files (600 dpi) (=included in my package) - the designs from salfter (compare screenshot above)
• Support of specifying ANY arbitrary image on the user's PC as the art background (will be forced to a fixed aspect ratio of 1.862:1 though)
• Can enter free text for "amount" and for the center area of the bitcoin note (compare screenshot above).
• Vanity-Address generation supported (but very very slow)

--> My enhanced html file (it's basis is the bitaddress.org html file as downloaded from their website on 2 Dec 2012) can be downloaded here, and you can run it offline in standalone-mode on any suitable browser (for sure Firefox works fine while Opera runs faster as long as I keep working on the PC/browser, but Opera fails rendering correctly for the actual printouts. Other browsers not tested.).

--> My complete package (5.7 MB zip file) includes the 10 external HigRes PNG files, a 7-page illustrated documentation/tutorial, the readme and everything digitally signed.

@pointbiz: I would be happy if these changes went inside the official version of bitaddress.org! It is very nice because now everybody can plot his/her own bitcoin notes fully securely (=offline) without any need for IT expert knowledge for setting up a webserver (like printcoins.com'2 solution) or configuring scripts and working on the console (like salfter's solution), and still the notes have very good print quality (600 dpi)!

More info in the documentation or in my readme file, both of which are included in the full zip package.

UPDATE 30 Nov 2013: Get Version 10 (GPG signed zip file) of my tool with mBTC denomination support and some cleanups! (11.8 MByte)

Cheers & Enjoy printing nice Christmas presents
Michael

PS: Thanks to pointbiz (=bitaddress.org), salfter, casascius, printcoins.com and the other "printed bitcoin paper note activists and visionaries" that have inspired me and provided me with material (source code and designs) that I could build on for making this happen. What a great community!

PPS: My donation address is still unknown in the blockchain - I am wondering if and when this is going to change...  

I think support for custom private keys is a great idea and I have an idea how it could be handled without much change to layout and interface.

There is already a bulk wallet tab. So when you choose the paper wallet maybe it can check here first and deposit the keys in that tab after completion. That also provides a way for the creator to back them up in bulk with a simple copy/paste. A slight alteration of the paper wallet code could check that tab before generating and if a series of keys/addresses is already present then it could use them to create the bills instead of generating new ones.

This way you could mix random keys, replace some with vanity keys, or take the ones from your existing wallet and paste them in to make paper bill backups. It would also possible to use a seed and have all your bills generated sequentially from the seed (eg. using an Electrum temporary wallet listing and pasting it here).

I could also see the ability to use vanity addresses useful as custom "gift certificates" for various businesses. Using this method above avoids re-designing layout and perhaps only a simple help text would let people know this is an option.

@Michael_S - I have javascript skills and can code this if you like this idea. I'd prefer to do it if it were to be accepted into the main version but I guess it's also possible as a custom version.

Of course, manually patching the bill together with a graphics program is always possible. However, the idea of solutions like bitaddress.org or printcoins.com is to simplify the job and be able to print it with little efforts and no special skills.

Moreover, I do not agree at all with the statement that this feature is for a "very small niche" only - at least not less of a "niche" than what "printcoins.com" is made for. Or one could define the Bitcoin community as a whole as a "very small niche" today, which is probably true compared to the number of people paying with EUR and USD today, so with the same argument one could justify that any development in the Bitcoin world is just useless. Similarly, any special developments within the Bitcoin world could be considered niches by themselves, since each such development may be of interest only for a subset of all Bitcoin users - So with the same argument all these things are unnecessary either. So where do you draw the line for what is a "niche" and what is not, and who decides it?

--> Instead, let's wait for an open discussion and let's not have the idea killed in advance by classifying it as a "very small niche" by some individuals who are not interested in the respective development/feature - maybe other individuals are very well interested.


I think anybody skilled in javascript can add such feature to bitaddress.org's html file - I may try to also hack this into the code myself, but I have never programmed javascript, so not sure if I can do it...

All we need is to identify the point in the javascript code where the size of the QR code is defined, and to identify the place where the random addresses are generated for the paper wallet and replace it by an interface where it is read in from a list of copy-pasted public-private-key pairs.

PS: One motivation for using non-random addresses for such paper bitcoin bills is to use vanity addresses for personalized gifts, e.g. like 1TomXjk4d93jfZT45RZEtcEtcEtcEtcEtc or whatever.


Cool ! Unfortunately I don't speak Finnish

I think this feature is kind of for very small niche... Just take the graphic from elsewhere and create the note yourself.

Spotted from the web: Finland-themed bitaddress.org, translated to finnish.
https://cdn.anonfiles.com/1354187274492.html

Hi pointbiz,

I have a request for two slight (?) (but very useful) enhancements to the javascript html file on bitaddress.org:

Both are for the "Paper Wallet" tab:

1) To offer the option of using my own private keys instead of new random ones.
2) To offer an option for reducing the size of the secret key QR code such that it can be covered by a 2.5 cm (1 inch) square hologram sticker. For this the secret QR code size should be only 1.5 cm in size, such that 0.5 cm border is left on each side where the hologram sticker can be attached to. The size of the white square surrounding the QR code could be reduced from 3 cm to 2.5 cm to match the size of the hologram sticker.
Also, when this option is checked, the private key should not be printed in plain text on the bill, and instead a place holder text could be printed, reading for example:
[For the private key see QR code in the square field labeled "Spend"]
Alternatively (if there are worries that the QR code might not be readable anymore if this small), there could be another checkbox opting for printing the plain text secret key instead of a QR code within this 1.5 cm x 1.5 cm area.


You may ask why I do not use http://print.printcoins.com/ instead of requesting this feature from bitaddress.org.
The reason is quite simple: printcoins.com uses server-side php scripts etc. to generate the printed bills, so the private keys are sent to the server (and this even unencrpted via http right now). To generated 100% safe printed bills with the "printcoins.com method" I would need to download the various source files, set up my local web server and run this code on that server on an offline PC. On the other hand, for bitaddress.org I just need to view the HTML source, copy-paste it to a single new txt (or "html") file on my PC and can run it immediately in any browser on any offline PC.

Translating all the printcoins.com stuff to javascript is probably much more work than adding the two features above to bitaddress.org's javascript html file, that's why I assume I have higher chances to get this done at this place.

With this feature, everyone would ultimately have a really easy method for generating bitcoin bills absolutely securely for purposes of private promotion/gifts/etc.

----------
Here is an illustration of how I think it should look (smaller QR code (or alternatively plain text)) and changed text next to the square:


And here is my idea how I would create a gift/promotion bitcoin paper bill, if I do not have any holograms at hand:
I use a solid-black printed square of paper (here indicated in red for illustration purposes) and attach it with 4 stripes of transparent tape (here indicated as transparent cyan coloured lines):


If I use a paper material that has a coarse surface, it shall not be possible to remove the transparent tape (and therefore view the private key) without trace.
The hand-written message/greeting/hand-written signature serves as a "pragmatic" kind of counterfeit protection.

I think this is an easy to use do-it-yourself gift/promotion bitcoin paper bill.

I forked the bitaddress.org github repo to translate it to spanish and placed the result here. My fork lives at https://github.com/dserrano5/bitaddress.org and the SHA1 of the page is 291366b7fd6f76c4242b430d8a7cb7d34079aa9a.

This would be awesome.  That's a great bounty, too!