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?
Topic: [ANN] bitaddress.org Safe JavaScript Bitcoin address/private key - page 37. (Read 153479 times)
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?
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?
bitaddress.org in a USB key guide
https://bitcointalksearch.org/topic/guide-bitaddressorg-usb-key-78898
https://bitcointalksearch.org/topic/guide-bitaddressorg-usb-key-78898
no problemo, its just your code is so perfect and amazing, theres just 1 error from ultimate perfection.
April 30, 2012, 08:41:04 PM
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.
April 30, 2012, 08:29:23 PM
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?
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
April 30, 2012, 05:00:59 PM
No problem, just not html valid, I think this is new.
April 30, 2012, 04:59:44 PM
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?
April 30, 2012, 08:05:58 AM
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?
2. Could you link to this forum on the site?
March 27, 2012, 11:21:10 PM
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...
...
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.
March 27, 2012, 08:35:58 PM
Thanks, I was about to manually remove the "offenders!"
X-treme OCD, baby! They are all valid btw. Also, don't use the ones you posted since you were kind enough to post the private keys. 
March 27, 2012, 08:32:30 PM
Thanks, I was about to manually remove the "offenders!"
March 27, 2012, 07:41:24 PM
The bulk wallet page says "daeman", when it should say "daemon". See http://en.wikipedia.org/wiki/Daemon_(computing).
Also, step 5 of "How do I use a Bulk Wallet to accept Bitcoins on my website?" says "Use the original wallet file you generated in step 1", but step 1 doesn't involve making a wallet file, just a list of keys:
Also, step 5 of "How do I use a Bulk Wallet to accept Bitcoins on my website?" says "Use the original wallet file you generated in step 1", but step 1 doesn't involve making a wallet file, just a list of keys:
Quote
"Use the Bulk Wallet tab to pre-generate a large number of bitcoin addresses (10,000+). Copy and paste the generated comma separated values (CSV) list to a secure text file on your computer. Backup the file you just created to a secure location."
March 27, 2012, 06:55:24 PM
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:
Some addresses are bigger than others. It's perfectly natural, and nothing to worry about.
See https://en.bitcoin.it/wiki/Base58Check_encoding#Creating_a_Base58Check_string (particularly step 5) for the technical details as to why the length isn't fixed.
March 27, 2012, 04:46:03 PM
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:
10056,"1rbHDjLZhk6TMpqEvWnAxBKhZphKG3CMk","5KMpUJ5BNX6iLign2NLZxRBmjQ59PRdtkWYzF5PTU9aPgZsa34a"
10071,"1b7pujCEMpkti7am7Y6Pg5f3RxGyxVN1E","5KhQv5XrFwJBoJto2LXMhLzyRjSwuJv35kXukcNEbMcD4rfRFrG"
10072,"1PHS83TkNLF2GZdDTCZp8oy91sy9i7RTL","5JakWEJ7n6pHDdCzknJbbV5Tc57abxTfAFbZkCC6iVwcrcD6jry"
10085,"1fRgmWE6g1UUYRnrfzmJ8EpnEYWGgHT9Y","5KEsH9rxEdk5DEg4zgsaTYfs3QnRRsWhZ6rQoW1riB4NHwZPcnM"
10088,"1aCtNvJwetWzceqe3PmAWifGNvEorkX5K","5KCP8JQHeTHcGxvyEWwe6pLdRgBHt5dLfa13X4evUYKdgS4UCWY"
10101,"1a1iaJc6XTnJPBaDLoda2uaa2mHvsiKxU","5JfJxsKGZMuXozKnSL7BiJmqqubGym4LbdpMUx3uJZ5E7fsZNE2"
10102,"1R38v2G5wWry6mBQ3VAKVAMn9b2nqoyUu","5JYB9naYToA7c2frKNYNV1gSMAJA8UQqb7sNdasjt1no8xGVKtd"
Not sure what's causing it...
10056,"1rbHDjLZhk6TMpqEvWnAxBKhZphKG3CMk","5KMpUJ5BNX6iLign2NLZxRBmjQ59PRdtkWYzF5PTU9aPgZsa34a"
10071,"1b7pujCEMpkti7am7Y6Pg5f3RxGyxVN1E","5KhQv5XrFwJBoJto2LXMhLzyRjSwuJv35kXukcNEbMcD4rfRFrG"
10072,"1PHS83TkNLF2GZdDTCZp8oy91sy9i7RTL","5JakWEJ7n6pHDdCzknJbbV5Tc57abxTfAFbZkCC6iVwcrcD6jry"
10085,"1fRgmWE6g1UUYRnrfzmJ8EpnEYWGgHT9Y","5KEsH9rxEdk5DEg4zgsaTYfs3QnRRsWhZ6rQoW1riB4NHwZPcnM"
10088,"1aCtNvJwetWzceqe3PmAWifGNvEorkX5K","5KCP8JQHeTHcGxvyEWwe6pLdRgBHt5dLfa13X4evUYKdgS4UCWY"
10101,"1a1iaJc6XTnJPBaDLoda2uaa2mHvsiKxU","5JfJxsKGZMuXozKnSL7BiJmqqubGym4LbdpMUx3uJZ5E7fsZNE2"
10102,"1R38v2G5wWry6mBQ3VAKVAMn9b2nqoyUu","5JYB9naYToA7c2frKNYNV1gSMAJA8UQqb7sNdasjt1no8xGVKtd"
Not sure what's causing it...
March 23, 2012, 02:46:19 AM
I can verify that the site has been updated and returns the same HTML from the latest commit (e58a86a2fad0e9ac4c9530abd1035a71abbbcce7) in github.
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
f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b -
Then from my bitaddress.org repo:
$ git rev-list --max-count=1 HEAD
e58a86a2fad0e9ac4c9530abd1035a71abbbcce7
$ sha1sum bitaddress.org.html
f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b bitaddress.org.html
March 22, 2012, 08:53:19 PM
v1.5
https://www.bitaddress.org/bitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html
Wallet Details Tab:
- coretechs fixed a bug with the display of the base64 private key
- coretechs added support for compressed public/private keys
Thanks again to coretechs for the contribution!!
https://www.bitaddress.org/bitaddress.org-v1.5-SHA1-f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b.html
Wallet Details Tab:
- coretechs fixed a bug with the display of the base64 private key
- coretechs added support for compressed public/private keys
Thanks again to coretechs for the contribution!!
March 12, 2012, 10:31:44 PM
Great work! Thank you for the contribution. I reviewed the code looks good. I have to catch up a bit on the compressed keys stuff to be 100% sure.
Thank you for the bug fix on the zero padding of base64 keys.
I will get this merged to the master branch and posted on bitaddress.org
I will post here when it's live.
Thank you for the bug fix on the zero padding of base64 keys.
I will get this merged to the master branch and posted on bitaddress.org
I will post here when it's live.
March 11, 2012, 01:59:34 AM
Nice catch!
It looks like that bug is present in the master as well. It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.
I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.
New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b
It looks like that bug is present in the master as well. It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.
I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.
New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b
Yes, I didn't actually try your version. Your post just reminded me that there was a thread about this and prompted me to report the bug.
March 11, 2012, 01:57:22 AM
Nice catch!
It looks like that bug is present in the master as well. It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.
I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.
New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b
It looks like that bug is present in the master as well. It's the same bug that Casascius pointed out earlier in this thread, looks like it was missed for the base64 conversion.
I added the padding to the byte array before it gets passed to bytesToBase64() and it appears to be working correctly now.
New commit: 0ebfba0b
https://github.com/coretechs/bitaddress.org/commit/0ebfba0b37d84ec5b9401df7e8f1be5c9ea4ad4b
Jump to: