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

Here is a request I'd like to make:

Currently there's a page for Vanity Wallet.

It is presently able to take two private keys in hexadecimal, and provide the EC product of the two, along with its corresponding public key and bitcoin address.  I would like this page enhanced.

Here is what I'd like changed:

1. I would like it to accept key input in any private key format the codebase recognizes (compressed private keys may either be disallowed, or simply not allowed to be combined with uncompressed keys).  Specifically that should include "minikeys" (30-characters) as well as the usual 51-character code that starts with '5'.

2. I would also like it to accept user input of up to one public key - in other words, one box can contain a public key and the other box can be a private key, and the resulting public key and bitcoin address will be shown (with the corresponding private key unavailable, of course).

The reason is that I would like to start offering 2-factor physical bitcoins (mostly my gold-plated savings bar), and have BitAddress.org be the only tool the other party needs to securely participate in this sort of offering.

The reward for completion: Five gold-plated two-factor Casascius savings bars engraved with the vanity addresses of your choice (because you will generate your addresses starting with five different public keys I give you, one for each bar.)  Shipping is included.

thanks for explaining. that is very cool. more apps need it.

@pointbiz: sorry that I could not believe it

Oops, I'm late.



I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v2.0 (54c26d38e68eb87ea5b083f07091b547e10f8eac) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
c0300a88d2de421106560185e4916f4eee6ed9df  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git pull
$ git log --pretty=oneline|grep "v2.0"
54c26d38e68eb87ea5b083f07091b547e10f8eac v2.0 Vanity Wallet, Paper Wallet updates

$ git checkout 54c26d38e68eb87ea5b083f07091b547e10f8eac
$ git rev-list --max-count=1 HEAD
54c26d38e68eb87ea5b083f07091b547e10f8eac

$ sha1sum bitaddress.org.html
c0300a88d2de421106560185e4916f4eee6ed9df  bitaddress.org.html

Using "Bitcoin by Mt. Gox Mobile", v3.2 (Dec 30, 2011) for Android here's how:

At the bottom is "Transfer", then you see a tab for "Redeem".  Then click the magnifying glass to scan the QR code.  Scan, click "Redeem coins" and you're done.  The app tells you how much coin was on the address and it will automatically sweep that amount into your Mt. Gox account.  If at a later time any more funds arrive at that address, another transaction will be made to sweep them at that time as well.

Another method to redeem these keys is with Blockchain.info/wallet.  This is only done through the web interface, and not from the Blockchain for Android (or iOS) mobile app.

I just had requested this feature from EasyWallet:

not sure if kidding...   as far as I know gox mobile is not able to import bitcoin private keys.

If it is not available maybe we should suggest it to one of the app developers (bitcoinspinner, bitcoinwallet). I think it would be relatively simple for them to add this feature.

I review pull requests sent by others. On various occasions people have reported bugs in the code and version 0.1 to 0.4 are no longer online; I made the project open source and available at github at request on this thread and started the commits with v0.5.

v0.5 to v2.0 are online and I recommend you use the last version you have reviewed yourself if you read JavaScript.

Stephen Gornick checks that the online versions checksum matches what is in github.

I would like to invite others to review the safety of the code. I have attempted to arrange the code in a way that the libraries can be reviewed separately from the ninja code. I have recently refactored the wallet code such that each wallet has separate code and does not use methods from the other wallets. So reviews can be focused on the wallet you personally use.

Mtgox mobile... but the app crashes for me on jelly bean 4.1.2 used to work great on ice cream sandwich

 Also u can use mtgox.com in Chrome for Android

Is there an Android app able to import the private key?

Interesting. Good usability idea.

I'd like to do something with split keys for the use case of savings wallets. The goal would be to have a secure paper wallet if both computers are compromised. A casual user should be able to use bitaddress.org at work and at home to print each part of the key. Keys will need to be split and matched in bulk because once you bring a key back together it is "compromised" (if you are sufficiently paranoid) and must be spent immediately to another address. Users would divide their savings up into convenient amounts so they can cash out small portions of their savings without compromising the whole amount. For example taking 1000 BTC and sending 50 BTC to 20 bitcoin addresses. You print two copies of each half key (A & B). Keep one set of copies together in a safety deposit box (A + B). Keep one half of the keys at work (A) and one half of the keys at home (B).

are there people scrutinizing these new releases to ensure there are no changes to the private key generation or presentment that shouldn't be there?

Another simple enhancement idea:

upon clicking the Print button, if the user has not generated new addresses since the last time he clicked it, it should tell him: "For security, new addresses will be generated before printing.  Continue?"  (OK=regenerate and print, Cancel = do nothing).

This will help avert a potential disaster if a user unknowingly prints a large batch more than once and then distributes the duplicate batches.

I realize it's of little use if the user chooses Print from his browser rather than the Print button in the page, but it's far better than nothing, and I think most users will use a Print button provided to them anyway when available, knowing it gives them the overall best chance of printing a print-friendly version.  The advanced user also maintains the option to reprint a batch if needed: he can just use the browser's Print function.

PointBiz,

What is next on your list?

Creating offline transactions from just the script hashes/indexes and private keys?
Or some multisig magic?

N1bor

Thanks pointbiz...

Incase anyone wonders what the Vanity bit is for see:
https://bitcoinvanity.appspot.com

Absolutely awesome, printed QR codes look great!  Codes in black toner are much more readable on printouts.

v2.0
https://www.bitaddress.org/bitaddress.org-v2.0-SHA1-c0300a88d2de421106560185e4916f4eee6ed9df.html
 - Added Vanity Wallet merged from n1bor
 - Paper Wallet merged high resolution QR code from ironwolf

I can verify that the BitAddress.org website has been updated and returns the same HTML from the commit with the description v1.9 (770d933029b8bbb56539d866db6b8fa37f262102) in github:
 - https://github.com/pointbiz/bitaddress.org


To confirm this I first check the sha1sum hash of the html returned by a request to http://bitaddress.org:

$ wget --quiet -O - http://bitaddress.org|sha1sum
a487b495d710d6f617d688e5f758e40c8b6c510e  -

$ GET -eSd bitaddress.org|grep -i "200 OK"
GET https://www.bitaddress.org/bitaddress.org-v1.9-SHA1-a487b495d710d6f617d688e5f758e40c8b6c510e.html --> 200 OK


Then from my bitaddress.org repo:

$ git checkout master
$ git log --pretty=oneline|grep "v1.9"
770d933029b8bbb56539d866db6b8fa37f262102 v1.9 Testnet Edition fixes

$ git checkout 770d933029b8bbb56539d866db6b8fa37f262102
$ git rev-list --max-count=1 HEAD
770d933029b8bbb56539d866db6b8fa37f262102

$ sha1sum bitaddress.org.html
a487b495d710d6f617d688e5f758e40c8b6c510e  bitaddress.org.html


[Update: Had to update the procedure since there had been commits to master since v1.9.]

I was trying to avoid using WIF for the "part-private-keys" and "part-public-keys" as then they look different from the key you have to import into the wallet. Although once you get your head round it all the fact that there are 3 private and 3 public keys washing around in the process is obvious, for the casual one off user it could get confusing. By making the keys look different they are less likely to try to import the wrong private key into the Wallet and then be disappointed!


Agreed - will do tomorrow, and update git.

v1.9
https://www.bitaddress.org/bitaddress.org-v1.9-SHA1-a487b495d710d6f617d688e5f758e40c8b6c510e.html
 - fixed Testnet Edition WIF and Compressed WIF private keys. It now prepends
   the correct byte (0xEF) for testnet when activated.

Ok, I tried it. I understand the concept and read some of the related threads.

My thoughts are that it should use the WIF private key in all cases. I had to open bitaddress in another browser tab to convert the WIF from vanitygen to HEX for the vanity tab. Is there a reason we shouldn't use just WIF? Or alternatively we could extract the private key detection used in the wallet details tab so any private key format could be used.

I like the descriptions you have for each area.

Regarding the UI we could possibly create two parts inside that tab. So it's clear there is Part/Step 1 and Part/Step 2. We can use the expand collapse UI like the FAQs on the bulk wallet tab.