if never used it will just show no transactions linked to that address.. when checking block explorers.
to 'save' all possible addresses would require storage beyond any measure/availability today

---

there are 904625697166532776746648320380374280100293470930272690489102837043110636675 possible private keys

use this http://gobittest.appspot.com/Address
type in 1 at: '0 - Private ECDSA Key' text box
it will give you: 1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm  at: '9 - Base58 encoding of 8' text box

type in 2 at: '0 - Private ECDSA Key' text box
it will give you: 1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m  at: '9 - Base58 encoding of 8' text box

continue for as long as you like until your fingers burn out from keyboard friction.. or even make a script to automate it.
the number is so huge it wont matter.

---

you can build a new script that not only makes the keypairs for your computer to store
requiring storage way way way beyond even a yottabyte hard drive


then if checking the balance. which by the way requires much more computational power and bandwidth.

seeing as how there are 904625697166532776746648320380374280100293470930272690489102837043110636675 possibilities
and imagining you could check lets say 1000 addresses a second.

1000                     =1 sec   
60000                     =1 min   
3600000                  =1 hour   
86400000                 =1 day   
31536000000            =1 year   
788400000000           =1 family generation   
78840000000000        =100 family generation(ancestors)   

after 2500 years your ancestors would have only checked
78840000000000   possibles

in other words after 2500 years your ancestors would have
904625697166532776746648320380374280100293470930272690489102758203110636675 still to go
of
904625697166532776746648320380374280100293470930272690489102837043110636675

FTFY

Ok, I've reported all the sig ad nonsense in this thread to the moderators.  Hopefully, they'll come in and clean it up.


Those are 2 of the 4 algorithms.  There is also ECDSA and RIPEMD160.


Not as an address.

What is typically stored (for a version 0 address) is the RIPEMD160 hash.  You can retrieve the RIPEMD160 hash and convert it into a bitcoin address with Base58Check encoding if you want to.

That being said, the RIPEMD160 hash is only in the blockchain if someone has used it for a transaction output.  Other than the 80 byte block header at the top of every block, the ONLY other thing stored in the blockchain is the list of transactions.


Correct.  There are 1461501637330902918203684832716283019655932542976 valid version 0 bitcoin addresses.  Less than 0.000000000000000000000000000000000001% of them have been used yet.


That depends on the block explorer you are using, but yes most of them seem to behave that way.

There is currently no indication that there are any significant weaknesses in any of the three cryptographic algorithms (ECDSA, SHA256, RIPEMD160) used by Bitcoin.

Perhaps a mathematics researcher will discover a weakness in the future, perhaps they will not.  It is impossible to predict.

There is a known weakness in ECDSA related to quantum computing if quantum computers are ever powerful enough.  There should be plenty of time for us to switch to a different algorithm if that ever seems likely.

What exactly does SHA1 have to do with any of this? Private keys turn into addresses via EC point multiplication followed by SHA256 (which is a member of the SHA-2 family), followed by RIPEMD160.

you can check a generated address in a block explorer to make sure its 0.

but if its non zero, that means you just found a 256 bit ECDSA collision, which is astronomically unlikely. 

Yes, I am really impressed as well, thanks OP.  I had tried to do some of that arithmetic myself, so I know what a job it must have been.  Bravo.

Special thanks to DannyH, Franky1 and Coding E for their interesting observations and results.  Explaining some of the "mechanics under the hood" in English is nice to see.

I do agree with the notion that it is possible for some future smarty-pants math graduate student to find a weakness or two in the whole Bitcoin Ecosystem, unlikely as that may seem for now.

No, your mistake is treating the public key (the hex above starting with 0450...) as a String. But it is a hex.
If you perform SHA256 on it as a string you get the different result which is wrong (3251...). But when you treat it as a Hex, you get the correct result.

Here is an online tool which you can use:
http://www.fileformat.info/tool/hash.htm?hex=0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6

If you type the public key hex in the string text box on the top of that page you get the wrong result.