Got it... thanks.  I guess a subquestion of my prior question is would the private key always be the same if the two addresses are the same?  In other words, what if I used the bitaddress.org script to randomly generate a public address and private key, and the public address I got was the same as your public address,  would I then also get your private key or could our keys be different?

Kevin

OP good job  

You've almost answered your own questions correctly. Let me fill in the details a bit more. First I'd recommend using Armory for offline/cold storage. It makes the process more intuitive and probably less susceptible for anything going wrong IMO.

It's not necessary to use bitaddress.org offline with linux etc. This is recommended because you're dealing with manually generating/handling private keys. Anyone with access to this has access to all the coins. If your computer has spyware or bitaddress.org is compromised then private keys you thought were safe could actually lose all your coins. By taking the key generating Javascript offline and encapsulating it you cut down the risk of exposure. Of course if the Javascript was compromised then those extra steps wouldn't help. That's why I recommend Armory which can put everything in a context users are familiar with.

Regarding generating keys offline you're basically correct. The only thing Bitcoin checks for is that a public key it is aware of (some coins went there) is accessed with a corresponding private key. However this is done with ECDSA (here is a great video explaining it) not SHA-256 which is the hashing algorithm used to mine blocks for Bitcoin.

Last regarding the possibility of generating a private key someone else has both you and DeathAndTaxes explain it correctly.

Well Bitcoin is "complicated" so this isn't exactly correct.  

Most payments on the Bitcoin network are "PayToPubKeyHash" so the network is unaware of what the PubKey is, it only knows the hash of the pubkey being paid received an output.  The sender's client takes the address and reverses it to the PubKeyHash.  The PubKeyHash is actually what goes in the output of the tx.   Until that output is spent the network doesn't know what the correct pubkey is.

So to validate a spend the network needs to validate three things:
a) that the transaction is signed by the private key which corresponds to the public key (signature is valid).
b) that the PubKey when hashed (SHA-256) produces the PubKeyHash in the output of the prior tx (this pubkey corresponds to the address paid).
c) that this output has not already been spent (it is not a double spend).

An example might help.  Lets take this random tx:
https://blockchain.info/tx/83d51f7c87f275867288958d4f01afbde346370dedd3723cfe1c89ef3ba94012

Now to make it "simple" for end users Blockchain.info displays the Bitcoin address (i.e. 0.51 BTC was transferred to 162r6LJBJPhFQ3A9DjTKiww9sahzYWi1sV).  However the actual transaction doesn't include the address.  It includes the PubKeyHash.  The sender's client took the address 162r6LJBJPhFQ3A9DjTKiww9sahzYWi1sV and reversed it back to the pubkeyhash 373206576366c5c4cbd43e0e127262ce57bfe19d

If you look at the bottom of the page (you may need to enable showing scripts) you will see this:


In crude simplification it is saying this output (0.51 BTC) is locked and can only be spent by a tx signed by a private key which corresponds to a public key, that when hashed (SHA-256 & RIPEMD-160) produces this exact hash 373206576366c5c4cbd43e0e127262ce57bfe19d .  The Bitcoin network has no idea what pubkey hashes to that value (because hashes are one way functions) but it will instantly know it when it sees it.

If you attempted to spend this output with an incorrect pubkey which you could complete check "a" above, when your pubkey was hashed it would produce a different output.  Say it produced 966ca2c8a091088b8129ee3b053c51d799261eac .  Since 966ca2c8a091088b8129ee3b053c51d799261eac does NOT EQUAL 373206576366c5c4cbd43e0e127262ce57bfe19d the transaction is invalid (doesn't validate rule "b" above) and all nodes simply simply discard the transaction.