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

Maybe that's why someone was complaining their btc hadn't arrived after 8 confirms. MtGox should probably call it "Mini-Key format" as that makes more sense since it's so short.

I kind of like the mini-key format but I think the base58 is more universal. I've snapped QR codes on my notebook webcam and they converted back to text fine (using Ubuntu zbarimg tool).

I think a drop-down with key format choices would be a nice way but every option does add confusion for newbies...  If the base58 key works with MtGox then I'd think that is best when no options.

MtGox takes the 22-character mini string directly.  No conversion is needed.  If you give it hex, it probably took the sha256 of the hex you entered, resulting in no funds.

Couldn't you just make a few checkboxes or something?

Ahhh.... Brain food. I'll think about that.

I'm still thinking about the private key redeem at MtGox and how awesome that is. I can't even imagine all the possibilities

I find that Private Key formats can be a source of confusion. I found this article on the wiki:
https://en.bitcoin.it/wiki/Private_key

It does not describe the "Standard Private Key" that MtGox defines as:

Also, MtGox has a secondary private key format labelled "SHA-256 Private Key (E.g. Casascius Coins)" which appears to be the option if you want to redeem a private key in hex format (Mtgox accepted the 64 character 0-9 A-F sequence... I'm waiting to see if the deposit of BTC works). Also, Casascius Coins use a the mini-private key format. So to use this option with a mini-private key you have to first SHA256(MiniPrivateKey).

This is making me think I should create a tab to convert between different private key formats. I like just showing one private key format on bitaddress to keep things simple otherwise people might think they need both private keys and not realize the two private keys are equivalent and just being shown in a different format. Although, I'd rather contact MtGox and have them add the Sipa Wallet Import Format (WIF), I had to do some manual JavaScript work to convert from WIF to HEX to redeem at MtGox.

I have an idea for you that was prompted by the thread about printing plastic cards with QR codes on them to use in offline exchanges or promoting Bitcoin.

I think it would be pretty easy to create a tab on your site that would take the QR codes, text and some background image supplied and lay them out in a card format for saving/printing.

It would just take an SVG object element that refers to the QR codes and text with and tags. I think I could work that out and give you some sample HTML/JS code if you would be interested. I have worked with SVG before and it works quite well in browsers, though how it could be embedded with JS I'm not 100% sure.

My thought was to right click and save the SVG graphic to print out as a  4"x6" photo since this would allow nice colour graphics and design work to shine. With a background image embed option some really nice card designs could be created that allowed embedding the QR codes right on your page. I could see a user contributed library as possible. (The private key would be a separate  element so that it can be printed separately).

Another idea I had was to incorporate Shamir Secret sharing to break the private key into several QR codes for printing. You would need several QR codes to re-combine a usable private key. This might be on a "Multi-Key" tab perhaps.

Screenshot:

I see that now MtGox has a new feature allowing importing a private key into your MtGox wallet.

Sounds like this should work really nicely with bitaddress paper wallets for new users to get going without needing a client/blockchain or anything more than just printing a paper wallet. Nice!

Thanks!!

5 BTC donation sent as promised...thanks!  I now use your paper wallets.

v0.9
https://www.bitaddress.org/bitaddress.org-v0.9-SHA1-aa61ca480288e1bda00f1f042d60a057880a2321.html

-Added more entropy, all mouse movements in the window will add to the random seed pool.
-Added PaperWallet tab. You can now generate multiple QRCode pairs per page.

Cusipzzz confirmed he could sent 0.02 BTC to the address provided by jago25_98 in the other thread.
https://bitcointalksearch.org/topic/m.553869

So I consider the case closed. Looks like the issue the guy had in the other thread was that he could not send 0.0001 BTC from the v0.3.19 client and that is because the transaction fee was 0.01 BTC in that version, and he tried to send an amount less than the transaction fee and the daemon gave him an incorrect error message. He didn't have issues with the v0.4.0 version because the transaction fee is now reduced to 0.0001.

Nice work!

BlockExplorer shows that it's a valid Bitcoin Address:
http://blockexplorer.com/q/checkaddress/1PyrrD1EnHminnFPipPGyve4HiVyJPKmGy

I tried installing v0.3.19 to test but I could not get that version to run on Windows 7.

I doubt that the problem is with BitAddress.  I see it as more likely that some junk ended up on the clipboard (like a trailing space) that the old Bitcoin client didn't trim out.

I verified tons (10,000+) of addresses generated by BitAddress for validity independently using a Windows-based script I wrote.  Not once did BitAddress issue a non-well-formed Bitcoin address, even in the older versions afflicted by bugs affecting the private key.

Hm, looks like actually the problem being reported is with v0.3.19.  Would be a problem for BitAddress even if it is that older version.  Can anyone else confirm either way? 
 - https://bitcointalksearch.org/topic/m.553631

There is a forum post reporting a problem sending from a v0.3.2x client to "any address generated by BitcoinAddress".

I don't have v0.3.2x anymore to test.  Would someone be able to provide a response:
 - https://bitcointalksearch.org/topic/m.553309

I would suggest you just let someone set the number of codes and not worry about pagination.  lots of browsers, lots of page sizes, lots of ways to cause unintended side effects, it is well within right to leave page setup to the user.

Yes space to write is good. Just the format you have now is great. Six to a page is plenty.  I have already used your site to make a QR paperwallet I am actively using. (got a USB QR code scanner and am enjoying using it.)

I will take you up on that offer... I will call that feature 'Multi Wallet' or 'Paper Wallet' and it will be the next item on my TODO list.

Should the user enter the: 
1) number of QR-code-pairs ?  OR
2) number of QR-code-pairs per page and number of pages?  OR
3) number of pages ?

It looks like roughly 5 or 6 QR-code-pairs would fit on one page assuming they are the same height as used in the Single Wallet.

You mentioned previously about leaving space to write what each wallet is used for. In the Single Wallet design there is one line of space between the btc address and the private key. Lets call the QR-code-pair a 'box'. I thought it's more appropriate to write inside each box but let me know if you think the space between the btc address and private key should be reduced in favor of vertical space between the multiple 'boxes'.

Regarding, open sourcing the code... I had not really thought about it, for now I'll say no but I'll reconsider in the future if there's a compelling reason. With that being said, the most useful and reusable parts of the code ARE open source. I will provide a comment at the top of the page to help clarify the licensing situation.

Here is a summary of the JavaScript functions used in the code that have a redistributable license:
            
I don't know what the license information is for the window.Bitcoin function as that information is not available on github for bitcoinjs-lib. The only thing modified in the window.Bitcoin function is the addition of the sipa private key wallet import format which I have offered to Stephan Thomas to add into the bitcoinjs-lib.

I think that just means pywallet can't do transactions, but can still import/export addresses just fine.