[ANN] bitaddress.org Safe JavaScript Bitcoin address/private key

[casascius]

Having a rather interesting issue.  About 3% of returned public addresses from the bulk wallet are one byte short.  Here's a few for your perusal:
...
Not sure what's causing it...

It is normal and these keys are valid.  Such addresses will be produced by all generators including the reference Bitcoin client.

Such keys represent hashes that happen to start with several zero bits.  The bitcoin address encoding scheme specifies an unusual way of encoding leading zero bits that results in a shorter address when the leading zero bits can be inferred from the other characters.

[1715456210]

1715456210

[1715456210]

1715456210

[1715456210]

1715456210

[1715456210]

1715456210

[bitpop]

1. Could you remove consecutive dashes from your comments in the html? -- is bad, - - is good.
2. Could you link to this forum on the site?

[Stephen Gornick]

1. Could you remove consecutive dashes from your comments in the html? -- is bad, - - is good.

Really?  In the comments, or where does this cause a problem?

[bitpop]

No problem, just not html valid, I think this is new.

[bitpop]

http://html5.validator.nu/?doc=https%3A%2F%2Fwww.bitaddress.org%2Fbitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html

[pointbiz]

1. Could you remove consecutive dashes from your comments in the html? -- is bad, - - is good.
2. Could you link to this forum on the site?

1) I'd rather not discuss HTML validation. I've found it rather pointless in the past.

2) The link (not hyper-link) is here:
https://www.bitaddress.org/pgpsignedmsg.txt

[dooglus]

1) I'd rather not discuss HTML validation. I've found it rather pointless in the past.

I quite agree.  Why bother adhering to standards?  So long as it works in my favourite browser, screw the rest of you.

[bitpop]

no problemo, its just your code is so perfect and amazing, theres just 1 error from ultimate perfection.

[bitpop]

bitaddress.org in a USB key guide
https://bitcointalk.org/index.php?topic=78898

[payb.tc]

can someone please explain how 'wallet details' tab can produce two different bitcoin addresses for the one private key?

if i generated one of those, and sent 1 btc to each of those addresses, what would happen when i import that private key?

would it show 2 btc? what address would it show?

 

[dooglus]

can someone please explain how 'wallet details' tab can produce two different bitcoin addresses for the one private key?

if i generated one of those, and sent 1 btc to each of those addresses, what would happen when i import that private key?

would it show 2 btc? what address would it show?

 

Do you have an example of how to get it to do that?  I've never seen it happen.

Each private key should map to exactly one bitcoin address, although two private keys can (incredibly rarely) map to the same bitcoin address.

Edit: oh, you're talking about how it shows the regular and compressed addresses?  They're equivalent.

If you sent 1 btc to each of those addresses and imported the private key, you would see 2 btc at the same address.  Which address it shows would depend on the client you used.  I'll do it now and edit this post with the results.

I used vanitygen to make a 'bita' address, put the private key into bitaddress and found the two bitcoin addresses to be:

Bitcoin Address: 1BitaU837DThJpnSY6ppU8Nu8Z9VGd49U1
Bitcoin Address (compressed): 13jETWnEo69sKwPdYQNqwcqMg9mnyapzNr

Here are the transactions at http://bitcoincharts.com/bitcoin/txlist/ awaiting confirmation:



Hmm.  It's only showing 1 BTC in the new wallet with the imported private key, even though both transactions are confirmed and in my copy of the blockchain.  I wonder if this is a bitcoin client bug.

http://blockchain.info/address/1BitaU837DThJpnSY6ppU8Nu8Z9VGd49U1 and
http://blockchain.info/address/13jETWnEo69sKwPdYQNqwcqMg9mnyapzNr are showing a balance of 1 BTC each.

This isn't safe to depend on and is unlikely to be true for very long, if it is even true at all.  The developers have proposed a private key format that includes a flag to indicate that it corresponds to a compressed public key.  For a client to always take a private key and generate TWO bitcoin addresses from it is a needless doubling of resource consumption and complexity and is unlikely to become the status quo.

Seems it wasn't true at all...  So how do I access the 1 BTC I sent to the address corresponding to the compressed address?

[casascius]

can someone please explain how 'wallet details' tab can produce two different bitcoin addresses for the one private key?

if i generated one of those, and sent 1 btc to each of those addresses, what would happen when i import that private key?

would it show 2 btc? what address would it show?

 

Do you have an example of how to get it to do that?  I've never seen it happen.

Each private key should map to exactly one bitcoin address, although two private keys can (incredibly rarely) map to the same bitcoin address.

Edit: oh, you're talking about how it shows the regular and compressed addresses?  They're equivalent.

If you sent 1 btc to each of those addresses and imported the private key, you would see 2 btc at the same address.  Which address it shows would depend on the client you used.  I'll do it now and edit this post with the results.

This isn't safe to depend on and is unlikely to be true for very long, if it is even true at all.  The developers have proposed a private key format that includes a flag to indicate that it corresponds to a compressed public key.  For a client to always take a private key and generate TWO bitcoin addresses from it is a needless doubling of resource consumption and complexity and is unlikely to become the status quo.

[dooglus]

Seems it wasn't true at all...  So how do I access the 1 BTC I sent to the address corresponding to the compressed address?

I had to import the compressed private key to get the compressed address in my client, then I could spend the 2 BTC back to my main wallet:

Code:

$ bitcoind importprivkey 5KVdACbmHJJLxapsSjQyavyN4LdXtWc4xz7jeowDWxwbcNMRneS bita-regular
$ bitcoind importprivkey L4dLbcCSSwMZ6LJHeaCpkmDmwjeFLMfnW76jFtAJFFuykgqR5UGo bita-compressed

Put those two private keys into bitaddress and you get the exact same output for both.

The bitaddress output shows:

Private Key WIF (51 characters base58, starts with a '5'):
5KVdACbmHJJLxapsSjQyavyN4LdXtWc4xz7jeowDWxwbcNMRneS

Private Key WIF (compressed, 52 characters base58, starts with a 'K' or 'L'):
L4dLbcCSSwMZ6LJHeaCpkmDmwjeFLMfnW76jFtAJFFuykgqR5UGo

so you just need to import both of the private keys if you want to be able to receive coins to both of the bitcoin addresses.  Then the client treats the two addresses as if they were really different addresses:

[payb.tc]

thanks for the above explanations/experiments.

my main concern is being able to access my 'brain wallet' in future.

so if i only ever send to the non-compressed bitcoin address, then i must import the non-compressed private key to spend them.

that means an important question is; will the 0.6+ standard client always be able to do this or should i just start over with the compressed types?

got a bit worried that i might lose access to it, but as long as i remember my passphrase i should be okay, right?

[dooglus]

so if i only ever send to the non-compressed bitcoin address, then i must import the non-compressed private key to spend them.

That's right.

that means an important question is; will the 0.6+ standard client always be able to do this or should i just start over with the compressed types?

got a bit worried that i might lose access to it, but as long as i remember my passphrase i should be okay, right?

There are many unclaimed outputs to uncompressed public keys, and always will be.  Since it's impossible to know by looking at just transaction outputs which of them correspond to private keys that have been lost forever, or even which are to compressed and which are to uncompressed public keys, the client will have to continue supporting uncompressed addresses forever, or risk making a significant proportion of all bitcoins unspendable.

Make sure you keep a copy of bitaddress's source code somewhere safe in case the site goes offline; then you'll always be able to recreate the private key from the passphrase in your brain.

[payb.tc]

Make sure you keep a copy of bitaddress's source code somewhere safe in case the site goes offline; then you'll always be able to recreate the private key from the passphrase in your brain.

yep got the exact version (1.5) saved and backed up, thanks.

[cbeast]

Make sure you keep a copy of bitaddress's source code somewhere safe in case the site goes offline; then you'll always be able to recreate the private key from the passphrase in your brain.

yep got the exact version (1.5) saved and backed up, thanks.

It should work with any SHA256 hashing program to create the private key.

[dooglus]

It should work with any SHA256 hashing program to create the private key.

This is true, but the satoshi client wants it in base58 with a checksum for the importprivkey command, so it's easier to use bitaddress to do that.

[payb.tc]

It should work with any SHA256 hashing program to create the private key.

This is true, but the satoshi client wants it in base58 with a checksum for the importprivkey command, so it's easier to use bitaddress to do that.

on the other hand, i think pywallet is happy with the regular hex string.

even after a year, i'm still learning new things about bitcoin

[dooglus]

Whatever works for you.