ECDSA Input When Transferring Bitcoin From Owner A to Owner B I want to get my terms right and master how transactions work within the Bitcoin network. 

Keeping things simple, when Alice wants to transfer 1 BTC to Bob, Alice signs a message with her private key. That message is passed to an ECDSA encoding function and prepared as a Sig. Alice also has Bob's public address.

I think what happens is that a transaction (record?--can it be called that?) is prepared that consists of a back-link to Alice's Tx ID, the recipient (Bob's) Public Key, Input/Outputs for the coin, and possibly other data. A hash of all of the data for Bob's transaction record is used as the new Tx ID. This record then floats around as an unconfirmed transaction in the transaction pool.

Upon verification, the Sig in Bob's unconfirmed transaction is validated with Alice's Public Key by passing the unconfirmed transaction's Sig, message, and Alice's public key to a ECDSA verification algorithm and examining the true/false result (true meaning that the message indeed was signed by Alice). 

My Questions (all brief answers, I think):

0) Is it okay to refer to the data structure for a transaction as a "transaction record"? 

1) I don't see exactly where Bob's public address is used other than to populate the new transaction record. Does it mean that once the transaction is confirmed, Bob can just see it in his wallet and only he can spend the coin in that transaction because only he has its private key?

2) What data elements, specifically, are in the message (highlighted above)?

3) Bob's Public Address is actually Base58 encoded. Does that mean that when the new transaction for Bob is created, the Bitcoin client first decodes the Base58-encoded Public Address back to a Public Key so that it's the Public Key that gets stored in the new transaction record rather than the Public Address?

Thank you.
1) I don't see exactly where Bob's public address is used other than to populate the new transaction record. Does it mean that once the transaction is confirmed, Bob can just see it in his wallet and only he can spend the coin in that transaction because only he has its private key?


Addresses are a human abstraction and they don't appear anywhere in a transaction. Transactions are a combination of Inputs and Outputs. 

Outputs contain the amount transferred and some conditions attached to redeem the coins (known as scriptPubKey). Inputs redeem previous outputs by providing the inputs needed to validate the sender's conditions (known as scriptSig). 

The most common set of conditions are "whoever can provide a signature associated with this public key can redeem the coins".


  2) What data elements, specifically, are in the message (highlighted above)?


What exactly is being signed is a variation of the transaction itself. Which variation depends on a flag called sighash which is attached to the signature.


  3) Bob's Public Address is actually Base58 encoded. Does that mean that when the new transaction for Bob is created, the Bitcoin client first decodes the Base58-encoded Public Address back to a Public Key so that it's the Public Key that gets stored in the new transaction record rather than the Public Address?


No, the public key is hashed before being encoded into an address. Hashing is a one-way operation so you can't derive the public key by knowing the address. The client that wants to validate the transaction just runs the script with the conditions that the sender attached (public key) using the inputs that the person that is trying to redeem provided (signature). If the script evaluates to true the transaction is valid. Scripts contain public keys not addresses.