ECDSA Input When Transferring Bitcoin From Owner A to Owner B

Question

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.

Answer 1

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.

Answer 2

based on the anser/comments before, I'd like to help a bit deeper: Looking at a standard P2PKH transaction, there is a locking and unlocking mechanism. The locking mechanism is in the pubkey script (in the output section) of the previous transaction (some refer to it also as the spending condition). The unlocking is in the sigscript part of the transaction (you would find "your" sig and pubkey here). In the pubkey script the author of a previous tx defines the target (to whom the tx shall go), which is represented as the pubkey hash. When then the receiver of the tx wants to spend the tx, (s)he needs to fulfill the condition (by showing the non-hashed pubkey) and also signs the tx with his/her private key.

The link between the two is this:

The P2PKH script in the previous transaction's pubkey script section says s.th. like:

"if your pubkey hashes to the same value as I have presented here, you have met the condition to process the tx further"

Now as this hashing is a one way function, only people who have the "original" public key in hex format can create the requested hash (if you try to brute force or reverse engineer, that's as per today practically impossible). And where do you present your public key? In the sigscript section! You provide signature and public key. All in all this ends up in a stack, where in the first step the hash is compared, and if equal, also the signature is checked. Only when both conditions are met, the transaction is processed further.

More to it on script validation in the developers pages of bitcoin, and in Andreas' book "Mastering Bitcoin" in section 6 "Transactions". Highly recommended. It can be found online, also here.

Hope this helps to better understand.