Quote from: BitcoinScholar on February 06, 2013, 11:31:02 PM

I understand! So the coinbase transaction is just an output with no signatures that is rewarded to the person solves the hash which then gets transferred to the corresponding person's address in which they sign it while sending it which officially claims the reward.

You are getting close, but you aren't quite there yet.

The coinbase is just an list of outputs with no signatures. The person (or mining pool) that solves the block hash can list as many outputs as they want with what ever values they want assigned to each output in the list, as long as the total of the outputs is not greater than the sum of the allowed block subsidy value and the transaction fees of all the transactions in the block. Each of the outputs in the list is a bitcoin address and a value. By the nature of being in the list of the outputs with an associated value, the output in the unsigned coinbase transaction is recognized as having that additional value and the right to spend that output to any other address in the future by simply including a reference to the output and a signature from the private key associated with the address that is stored in the output. There is no need to "officially claim the reward", unless you mean that in spending the reward someone claims that it is theirs to spend by signing it.

Quote from: BitcoinScholar on February 06, 2013, 11:31:02 PM

When each new address is created does that create a new public and private key or is a person's private key always retained and reused no matter the change in the public key?

Each bitcoin address is associated with a separate private key (there are some technical details that make this not exactly true, but it is generally true in real world use).

Quote from: BitcoinScholar on February 06, 2013, 11:31:02 PM

the last thing is just what the creation of a new address entails.

To create a new address, you start by generating a completely random 256-bit number. This random number is the private key.

Next you use the secp256k1 curve and calculate the 512-bit ECDSA public key from this private key. For all intents and purposes, this is generally considered to be a one-to-one relationship. I'm not sure if it has ever been proven that 2 different private keys can't generate the same public key, but if they can the odds of it happening are so small that it can be realistically considered impossible.

From there you follow the directions I specified earlier SHA-256, RIPEMD-160, Version, Checksum, Base58Check.

Note that while there are 2^256 possible private keys (just a bit less than 1.58 x 10⁷⁷)
There are only 2^160 (due to the RIPEMD-160 Hash) possible bitcoin addresses (just a bit more than 1.46 x 10⁴⁸)

This would seem to suggest that it might be possible for 2 different private keys to sign transactions spending outputs assigned to the same bitcoin address.

In reality, unless a weakness is ever found in ECDSA and/or the secp256k1 curve it would be impossible to find these "other private keys". As long as the random private key is being generated from a source with sufficient entropy, the odds of someone accidentally picking a private key that matches a bitcoin address that is being used are so long that it can be considered impossible.