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

[casascius]

This generator should not be used until the question about Pywallet giving a different address is resolved. If the wrong address is being given, any coins sent to it will be lost forever.

[1715230595]

1715230595

[1715230595]

1715230595

[1715230595]

1715230595

[1715230595]

1715230595

[nmat]

Am I doing this right?

according to bitaddress.org, the address is:12DM8vG8pytcE8Q9CBj2LQnctiRRdoZ5aZ
with private key of: 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP

However, pywallet doesn't agree:

Code:

C:\Python27>pywallet.py --info --importprivkey=5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq1
7WZFtWcq5umQdsDtTP
'ecdsa' package is not installed, pywallet won't be able to sign/verify messages

Address (Bitcoin): 1M6dsMZUjFxjdwsyVk8nJytWcfr9tfUa9E
Privkey (Bitcoin): 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP
Hexprivkey: 6c9565b3eef4ef9e01c216e1910763a5f94cf3654c059e8c67a348d10ae39c28

edit: seems to work for further addresses. I printed the one above out, so I'm not crazy, looking at it now.

Same here. I tried a few addresses and all worked fine.

[casascius]

If a certain percentage of the bitcoin addresses are wrong, then that's no good.  Someone will trust the generator, send a big balance there, and have it disappear.  It's possible that it could be failing under some certain non-obvious condition.

I plugged that private key into my Address Utility.  Notably for that particular private key, the X-value of the public key corresponding to that key starts with a 00 byte, which is a relatively unusual circumstance that is highly likely to trigger this sort of malfunction.  The bitcoin address could be getting computed with the 00 being dropped as a "leading zero", and accordingly, it could be malfunctioning every time a public key has a leading zero byte in one of the coordinates.  My utility agrees with Pywallet as to which one's correct.

Pointbiz, once fixed, if you are able to generate a very large number of addresses to a CSV file, I can run them through my own utility and make sure that there isn't any other 1-in-100 or 1-in-1000 or similar failure mode.

[casascius]

I was sent a CSV file produced by TTBit from the output of the generator.  It is indeed flawed on any address that has coordinates starting with null bytes.  The current version is not safe to use.

The file contains one more anomaly: Sometimes it produces malformed private keys that begin with a 'y' instead of a '5'.  Not sure what the circumstances are, because the keys aren't valid, but they are occurring with approximately the same frequency as the 00 public key issue.  Maybe this happens when the private key starts with 00.  Here are some examples that appeared in the file.

429,1KuWNoUSr515WGnzSqxaYPtDXMvWZBes6i,yauqwyDTDGfjrgUDhgZdybgF1fDXDGuuV4zQTa6ra5yXEY89p
616,1FmLdqJcNxEr1RUAxsBKWn595X7bMmkfqR,yNje5oL9mB2UubMgWxzXwhhN1SANWQabgHMbD5a6LLyAFJuCc
831,1NAjZjF81YGfiJ3rTKc7jf1nmZ26KN7Gkn,yP536D6V88rqcJ3qFfBYuJ6pqdg6z2SZnm2SKDU4vRoCE9L89

[TTBit]

pywallet lets me import a key beginning with 'y', but returns a different Privkey

Code:

C:\Python27>pywallet.py --info --importprivkey yP536D6V88rqcJ3qFfBYuJ6pqdg6z2SZn
m2SKDU4vRoCE9L89
'ecdsa' package is not installed, pywallet won't be able to sign/verify messages

Address (Bitcoin): 1NAjZjF81YGfiJ3rTKc7jf1nmZ26KN7Gkn
Privkey (Bitcoin): 5HpJ4bpHFEMWYwCidjtZHwM2rsMh4PRfmZKV8Y21i7msiUkQKUW
Hexprivkey: 0004d30da67214fa65a41a6493576944c7ea86713b14db437446c7a8df8e13da

I'm interested in what is going on here.

EDIT: The hex seems to always start off 000 with the y addresses

[casascius]

pywallet lets me import a key beginning with 'y', but returns a different Privkey

C:\Python27>pywallet.py --info --importprivkey yP536D6V88rqcJ3qFfBYuJ6pqdg6z2SZn
m2SKDU4vRoCE9L89
'ecdsa' package is not installed, pywallet won't be able to sign/verify messages

Address (Bitcoin): 1NAjZjF81YGfiJ3rTKc7jf1nmZ26KN7Gkn
Privkey (Bitcoin): 5HpJ4bpHFEMWYwCidjtZHwM2rsMh4PRfmZKV8Y21i7msiUkQKUW
Hexprivkey: 0004d30da67214fa65a41a6493576944c7ea86713b14db437446c7a8df8e13da

I'm interested in what is going on here.

I figured it out.  Yes it's a private key that starts with a 00 byte, see red above.  Normally a private key is a base58+check string with 32 bytes of payload (besides the identifier byte 0x80).  The private keys starting with 'y' are well-formed base58+check strings with only 31 bytes of payload.  If the base58 is decoded and the missing byte assumed to be 00, the key decodes.  When a utility re-renders the original private key, it ends up having the full 32-bytes and will start with 5.

I made a little modification to my Bitcoin Address Utility and confirmed this behavior.

So, someone who uses a private key starting with 'y' is safe and doesn't lose their bitcoins because the original private key can be calculated.

Unfortunately, someone who gets the wrong Bitcoin address because a coordinate of the public key started with 00 will lose their bitcoins if they send to the address, because it is not the address that properly corresponds to the key pair.

[pointbiz]

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

[pointbiz]

Am I doing this right?

according to bitaddress.org, the address is:12DM8vG8pytcE8Q9CBj2LQnctiRRdoZ5aZ
with private key of: 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP

However, pywallet doesn't agree:

Code:

C:\Python27>pywallet.py --info --importprivkey=5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq1
7WZFtWcq5umQdsDtTP
'ecdsa' package is not installed, pywallet won't be able to sign/verify messages

Address (Bitcoin): 1M6dsMZUjFxjdwsyVk8nJytWcfr9tfUa9E
Privkey (Bitcoin): 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP
Hexprivkey: 6c9565b3eef4ef9e01c216e1910763a5f94cf3654c059e8c67a348d10ae39c28

edit: seems to work for further addresses. I printed the one above out, so I'm not crazy, looking at it now.

This applies to V0.1 to V0.4 of bitaddress.org and also applies to the bitcoinjs-lib open source library on github.

With regards to this private key: 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP
The JavaScript function "ECKey.prototype.getPub" in the Bitcoin object is not returning the correct public key byte array. It's returning a public key of length 63 instead of length 65. That function relies on the Elliptic Curve JavaScript library. At this moment I haven't identified where the issue is so I'm going to implement a workaround to look for the bad public key and just discard the key pair and generate another one.

In this case here is the JavaScript public key (bad):

Code:

04    76 d4 85 2e 6e 03 11 e0 80 03 6e fe c9 6a 33 95 40 17 6c f5 3e b7 18 25 80 bc 81 32 6e c9 b1    78 df 59 18 e1 8e f1 f5 7a e0 59 15 41 d2 68 de e5 28 bf 5c 29 e9 63 89 99 46 d3 00 f9 03 58

Here is Casascius public key from his C# utility (good):

Code:

04 00 76 D4 85 2E 6E 03 11 E0 80 03 6E FE C9 6A 33 95 40 17 6C F5 3E B7 18 25 80 BC 81 32 6E C9 B1 6D 78 DF 59 18 E1 8E F1 F5 7A E0 59 15 41 D2 68 DE E5 28 BF 5C 29 E9 63 89 99 46 D3 00 F9 03 58

[casascius]

The problem looks fairly straightforward, have a peek at ec.PointFp.prototype.getEncoded:

Code:

            ec.PointFp.prototype.getEncoded = function (compressed) {
                var x = this.getX().toBigInteger();
                var y = this.getY().toBigInteger();

                if (compressed) {
                    var PC;
                }

                var len = this.getX().getByteLength();

                var enc = ec.integerToBytes(x, len);

                if (compressed) {
                    if (y.testBit(0)) {
                        enc.unshift(0x02);
                    } else {
                        enc.unshift(0x03);
                    }
                } else {
                    enc.unshift(0x04);
                    enc = enc.concat(ec.integerToBytes(y, len));
                }
                return enc;
            };

Note the code is pulling len from X, and using that length for both X and Y.  This is definitely going to be the problem.  The length needs to be tested for each coordinate separately (Y should not be using X's length), and zero-padded if it's less than 32.  (Will integerToBytes behave properly if you just throw 32 as the second parameter, rather than len?)  (Also the possibility of having more than one zero byte needs to be considered.  Rare, but the consequences are disastrous if it happens, so it must be handled properly... if throwing 32 in there works, then that should do it, but if not... needs to be checked)

The part that tests compressed can be chucked - Bitcoin doesn't support compressed encoding.

[pointbiz]

The problem looks fairly straightforward, have a peek at ec.PointFp.prototype.getEncoded:

Code:

            ec.PointFp.prototype.getEncoded = function (compressed) {
                var x = this.getX().toBigInteger();
                var y = this.getY().toBigInteger();

                if (compressed) {
                    var PC;
                }

                var len = this.getX().getByteLength();

                var enc = ec.integerToBytes(x, len);

                if (compressed) {
                    if (y.testBit(0)) {
                        enc.unshift(0x02);
                    } else {
                        enc.unshift(0x03);
                    }
                } else {
                    enc.unshift(0x04);
                    enc = enc.concat(ec.integerToBytes(y, len));
                }
                return enc;
            };

Note the code is pulling len from X, and using that length for both X and Y.  This is definitely going to be the problem.  The length needs to be tested for each coordinate separately (Y should not be using X's length), and zero-padded if it's less than 32.  (Will integerToBytes behave properly if you just throw 32 as the second parameter, rather than len?)  (Also the possibility of having more than one zero byte needs to be considered.  Rare, but the consequences are disastrous if it happens, so it must be handled properly... if throwing 32 in there works, then that should do it, but if not... needs to be checked)

The part that tests compressed can be chucked - Bitcoin doesn't support compressed encoding.

Thank you SO much for this analysis! Thanks to TTBit as well for discovering these two issues.

I can confirm that passing 32 as the length for X and Y will give the proper public key for this private key: 5Je7CkWTzgdo1RpwjYhwnVKxQXt8EPRq17WZFtWcq5umQdsDtTP
It also is working for other private keys who's two points are 32 bytes in length (obviously).

So, seems we have solved one nasty bug. I will do some more testing and investigation of the private key issue where the WIF starts with a 'y'.

[casascius]

This might be the answer to your other issue:

See current code:

Code:

            // Sipa Private Key Wallet Import Format
            ECKey.prototype.getBitcoinWalletImportFormat = function () {
                // Get a copy of private key as a byte array
                var bytes = this.priv.toByteArrayUnsigned();
      ////////////// right here ////////////////
                bytes.unshift(0x80); // prepend 0x80 byte
                var checksum = Crypto.SHA256(Crypto.SHA256(bytes, { asBytes: true }), { asBytes: true });
                bytes = bytes.concat(checksum.slice(0, 4));
                return Bitcoin.Base58.encode(bytes);
            };

Where I have marked "right here", I think the problem would be solved if you added this line:

while (bytes.Length < 32) bytes.unshift(0x00);

(assuming bytes.Length is how you get the number of bytes in the array?  I don't do much javascript)

When done, if you (or TTBit, thanks) can send me a large CSV file full of private keys with bitcoin addresses generated by this updated code, I already have some test code ready to verify them.  Send me 10,000 or more if possible.

[pointbiz]

Preview of patched function:

Code:

// patched by bitaddress.org and Casascius for use with Bitcoin.ECKey
ec.PointFp.prototype.getEncoded = function () {
	var x = this.getX().toBigInteger();
        var y = this.getY().toBigInteger();
        var len = 32; // integerToBytes will zero pad if integer is less than 32 bytes. 32 bytes length is required by the Bitcoin protocol.
        var enc = ec.integerToBytes(x, len);
        enc.unshift(0x04);
        enc = enc.concat(ec.integerToBytes(y, len));
        return enc;
};

The integerToBytes function has a while loop to pad the zeros, so we should be okay if there needs to be more than 1 leading zero byte.

Code:

ec.integerToBytes = function (i, len) {
        var bytes = i.toByteArrayUnsigned();
        if (len < bytes.length) {
        	bytes = bytes.slice(bytes.length - len);
        } else [b]while (len > bytes.length)[/b] {
        	bytes.unshift(0);
        }
        return bytes;
};

Thank you for the fix for the private key as well!! I will work on getting this patched up and send you a PM with a big CSV.

[dooglus]

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that.  I had to get to page 3 before seeing any kind of a warning.

[nmat]

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that.  I had to get to page 3 before seeing any kind of a warning.

Or put it offline for the time being.

[pointbiz]

Thanks for the bug find... I'm working on it.
Please don't use v0.1 to V0.4

Perhaps you should edit your first post in this thread to say that.  I had to get to page 3 before seeing any kind of a warning.

Or put it offline for the time being.

Sorry guys, I goxed on that. The site is down until the fixed version is live. V0.1 to V0.4 are permanently down. Please don't send BTC to addresses you generated with those versions unless you've double checked the private key and bitcoin address with pywallet or something else. Only a tiny percentage of addresses were bad. However, only zero percent is acceptable. My apologies.

[casascius]

I tested the CSV file of 10,000 addresses you sent me (pointbiz) and all of them passed.  Woo hoo!

[pointbiz]

v0.5

http://www.bitaddress.org/bitaddress.org-v0.5-SHA1-7ea8d0e32c3583d369dc4079443e0d6e215ac216.html

2011-09-19: status ACTIVE
bitaddress.org-v0.5-SHA1-7ea8d0e32c3583d369dc4079443e0d6e215ac216.html
 -DO NOT USE VERSION 0.1 TO 0.4! They infrequently could generate bad keys.
 -Bug Fixed: v0.1 to v0.4 included a bug in the Elliptic Curve function:
   ec.PointFp.prototype.getEncoded
   The X and Y integers that were less than 32 bytes were not being zero padded.
   They are now zero padded which fixes the bug in generating public keys.
 -Bug Fixed: v0.3 and v0.4 had a bug in the Wallet Import Format function:
   ECKey.prototype.getBitcoinWalletImportFormat
   Private keys there were less than 32 bytes were not being zero padded.
   They are now zero padded which fixes the bug in generating private keys.
 -Requires IE8+, Firefox, Chrome or sufficient JavaScript support.
 -Added function to build a CSV list of addresses and keys.
   Not supported in the GUI yet.
 -Added a timeout to override the mouse move detection. Therefore, if the user
   has not moved his mouse before a certain random expiry the address and key
   will then be generated. This helps for mobile devices.

[casascius]

Random suggestion: Your donation address shouldn't be a QR code.  You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

[pointbiz]

Random suggestion: Your donation address shouldn't be a QR code.  You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

v0.6
http://www.bitaddress.org/bitaddress.org-v0.6-SHA1-1cea2d8c437d49c550b9ec1cfc5d02ac85e8199e.html
 -Removed QRCode donation address

[nhodges]

Random suggestion: Your donation address shouldn't be a QR code.  You might get random donations if someone's scanner accidentally picks it up, but the problem is that those donations would be unintended and undesirable.

Android wallets autosend? There's no, "Hey, you're about to send 5 BTC to x" feature? I thought instapay was what NFC was for, not QR codes.