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

Exciting! and very cool.

If you view source on the page, you'll find that adding other color palettes and changing the colors is relatively easy.

Possibly others can do a better job of picking colors than I can, especially for example those in Europe who want their notes' color scheme to resemble the series of Euro notes.  Maybe when I get a moment I'll make it into a color picker so you can experiment and post your results.

FYI this works on my iPhone too. Not that we would be printing from that, but just a good tech tool.

That's really very nice. Great stuff. And not so big as before either.

I really like the purple but the green one looks more grayish on my screen.
I'm sure now it would be easy to have a few color tiles to choose color, or even a #hex field for total custom values.

I also tried gzip on it to see how it may compress when supported by browsers and it drops down to 67K. Now if there were some JS compression code that could do that it would be pretty sweet and small.

wow howd you make that

Now I have the note CSS-ified and have provided four color palettes that can be applied to the note in javascript.  Just click the name of the color, and the svg transforms.

https://casascius.com/colornote.htm

Casascius you rock!

I just about have that whole SVG CSS-ified so the elements can be addressed by class and manipulated in script! (For customizing colors of course)

I think the only thing standing between bitcoind accepting the minikey is just simply that it hasn't been done.  Devs have no objection to the 30-character minikey, just the 22 character one, for having less than 128 bit entropy, but may not consider it a priority unless presented as a polished pull.

I am ultimately looking for laypeople to use bitcoins as gift cards, and redeem them at merchants like gift cards.  These are people who are not going to download bitcoind, wait to download the block chain, manually create a bitcoin.conf file, learn how to use the RPC interface, and import private keys through it.  The fact that they're redeemable at MtGox and BlockChain.info makes them perfectly good today.

Ideally, I want them to be able to buy bitcoins in person like gift cards and redeem them on Silk Road just like redeeming an iTunes gift card (not because I like or condone drugs, but because it's possibly easier to understand the simplicity I'm seeking by picturing people who have fried their own brains successfully managing it without a need or an ability to understand how it works).

Maybe printed in addition to the 51-char key would be good, but unless that minikey is accepted (e.g., can be imported into the BItcoin.org client), then it shouldn't exist in place of the 51-char key.

Meanwhile, here is just a brainstorming of my wishes for the next eventual iteration, whether or not they're realistic or possible.

1. choice of multiple art files, while still having art built-in to the single html file.  (multiple art just wouldn't work if you scraped the html without scraping the art, but the default base64-encoded art would still work, despite being low print resolution).  Choices of multiple art could be hardcoded and limited to "art1.png" thru "art9.png" in the same directory as the html file.  The main purpose would be so people can print bills in multiple colors as different denominations.

2. If using my redone SVG solves the performance problem that came along with having a 4 MB SVG last time, then it would be preferable instead of encoding a PNG.  (this also enables the possibility of using SVG+CSS so that the bill color can be set programmatically)

3. I think the bitcoin address and private key should be black.  This is so it will be printed with the black toner/ink, rather than a mashup of color ink, which decreases readability.

4. the QR code as presently rendered looks great on screen but prints with major scaling artifacts (I printed with Chrome, issue could be browser specific).  They are still readable, but the quality could be better.  (If SVG+Javascript is used, then perhaps rendering the QR code by creating black squares would offer really good quality).

5. The 30-character minikey would probably be a better private key than a full 51-character code, simply for user convenience.  Many of them will end up typing them.

6. Some sort of instructions on bitaddress.org for WEB VISITORS (css @screen), explaining to them that by printing the page, they are creating their very own bitcoin address and wallet.

7. The optional choice of some instructions for those receiving PRINTED NOTES (css @print), explaining to them that by receiving the note, they have just received bitcoins and/or a bitcoin wallet, and that they can print unlimited new wallets at bitaddress.org, and that they should be aware that any bitcoins on the note are good until first redeemed by anyone, and that if they didn't print the note themselves, they should promptly move their funds elsewhere just so they can be sure they can't disappear.

I'm pleased to be able to present the following that I've done some work on.

I have pretty much copied the design but re-rendered everything myself, from scratch, in SVG format.  That is - natively - without converting a raster image.  As a result, the whole thing as SVG weighs in at under 250 KB.  I did this in Adobe Illustrator.



.ai, .png, .svg -> https://casascius.com/graphnote.zip

EDIT followup: updated the image to thicken the lines so they moire less on printers. made the right hand ones whiter

The hex for the first one, and then these five, is

Based on what I know of other private keys, I'm going to guess that EF is always the prefix, and the extra 01 byte means compressed (which lengthens the code to 52).

It looks like uncompressed will always start with 9 (range: 91-93) and the compressed ones always start with c (range cM-cW)

Ah, that's an uncompressed key.  Those will begin with character code 8, which is '9', and will be only 51 characters long.

>>> (239*256**(32+4)) / 58**50
8L
>>> (240*256**(32+4)-1) / 58**50
8L

Here's reasoning to show why the testnet privkey will start with 'c':

The privkey is 33 bytes (if it's compressed, which it is by default?), and the checksum is 4 bytes.  That means the number we convert to base58 is between
  239*256**(33+4)
and
  240*256**(33+4)-1.

When we divide either of these numbers by 58**51 to get the 1st base58 character code, we get 35, which is the code for 'c':

>>> (239*256**(33+4)) / 58**51
35L
>>> (240*256**(33+4)-1) / 58**51
35L

I think that was my fault - sorry about that.  I calculated the leading symbol given the 'version' byte for 160 bit hashes, and then forgot that the testnet private key wasn't a 160 bit hash...  I just updated the wiki page.

Anyway, if you look at src/base58.h in the bitcoin source tree you'll see the version bytes for private keys are defined:


ie. the version byte is 239 for testnet, and 128 otherwise.

I just made 5 new testnet addresses in a new wallet and dumped their private keys:


Looks like the private key begins with a 'c'.  I also dumped the private keys of the 17 old addresses in my 'real' testnet wallet.  They all begin with 'c' too.  You'll notice too that testnet privkeys are 52 characters long, whereas realnet (?) ones are 51 characters long.

Here's one I had vanitygen create a couple of minutes ago:

The correlation to prefix depends on the length.  Different length, different set of prefixes.

If someone wants to post any testnet key, I can decode it and tell what bytes are in it.

https://en.bitcoin.it/wiki/List_of_address_prefixes

The wiki says the prefix should be 2 not 9 but it doesn't show an example.

Huh I thought only the Bitcoin address was different for testnet. Thanks for letting me know.

Do you know what byte should be used for test net?