Is this way to describe Transactions correct?

[tutak]

Hello! I have realized there is quite abit of confusion when it come to scriptSig and scriptPubKey in Transactions, i made a simple figure to show in simple terms how it works. Could somebody please check if my figure is correct? Thanks

http://img.ctrlv.in/img/527fe4d2689a6.png

[1714569927]

1714569927

[1714569927]

1714569927

[1714569927]

1714569927

[1714569927]

1714569927

[1714569927]

1714569927

[1714569927]

1714569927

[DeathAndTaxes]

No.  

ScriptSig
The ScriptSig is the digital signature created by the SENDERS private key.  In Transaction A the ScriptSig is a digital signature created by signing a hash of the simplified tx* with Alice's private key.   It also contains a copy of Alice's public key so the signature can be verified (because Satoshi likely didn't know about ECDSA public key recovery).

The ScriptSig (one per input) is used to validate the transaction.   This is how we know Alice (well someone who has access to Alice's private key), not Bob created the transaction.  In your diagram, anyone could steal Alice's coins by simply creating a tx sending them to their address (pubkeyhash).

scriptPubKey
You have it written the scriptPubKey is a hash of the ScriptPubKey.  In actuality in most tx (https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash) we are paying to the PubKeyHash so the PubKey isn't in the output.  The PubKeyHash is.  The PubKey is included in the input of a subsequent tx.

Simple version:
Input:  Contains signature created by sender's private key AND copy of sender's PubKey
Output:  Contains the hash of the public key (PubKeyHash).

Most people use addresses but when you tell your client to send x BTC to Bitcoin address 1KtshSbdFmGBaBZsYxi9ZUv4EqRnwce7tb the client reverses the address to the PubKeyHash and that is used in the tx output.  This is why we used PubKeyHash in the output not the PubKey because the PubKeyHash can be reversed from an address however the PubKey can't be derived from the PubKeyHash.  However for validating inputs we can easily hash the PubKey to get the PubKeyHash and ensure it matches the designated prior tx output.
 



* Remember a tx can have multiple inputs and each input is signed by the private key for that input so a simplified version of the tx is constructed including that input and the outputs which is hashed and signed.

[tutak]

 

ScriptSig
The ScriptSig is the digital signature created by the SENDERS private key.  In Transaction A the ScriptSig is a digital signature created by signing a hash of the simplified tx* with Alice's private key.   It also contains a copy of Alice's public key so the signature can be verified (because Satoshi likely didn't know about ECDSA public key recovery).

The ScriptSig (one per input) is used to validate the transaction.   This is how we know Alice (well someone who has access to Alice's private key), not Bob created the transaction.  In your diagram, anyone could steal Alice's coins by simply creating a tx sending them to their address (pubkeyhash).

So how does the receiver in this case Bob proves that the money is destined to him? By referring to the ScriptPubKey of the transaction A? I read that conditions could be set by the sender, and that the receiver has to fulfill before he can spend them, where are these conditions fulfilled?

scriptPubKey
You have it written the scriptPubKey is a hash of the ScriptPubKey.  In actuality in most tx (https://en.bitcoin.it/wiki/Transactions#Pay-to-PubkeyHash) we are paying to the PubKeyHash so the PubKey isn't in the output.  The PubKeyHash is.  The PubKey is included in the input of a subsequent tx.

Simple version:
Input:  Contains signature created by sender's private key AND copy of sender's PubKey
Output:  Contains the hash of the public key (PubKeyHash).

Isn't the ScriptPubKey a hash of the receiver's Public Key? If no, what is it?

[DannyHamilton]

So how does the receiver in this case Bob proves that the money is destined to him?

Why does he need to prove where it is destined?  The sender chooses where to send it, not the receiver.

I read that conditions could be set by the sender, and that the receiver has to fulfill before he can spend them, where are these conditions fulfilled?

In the ScriptSig of transaction B.  Bob fulfills the requirements in order to prove that he is authorized to spend the previous output when he sets up the requirement for the next receiver to be able to spend it.

[tutak]

I updated the diagram:
http://img.ctrlv.in/img/5280ec60cd22c.pngImage hosted for free at CtrlV.in

is it correct now?

In the ScriptSig of transaction B.  Bob fulfills the requirements in order to prove that he is authorized to spend the previous output when he sets up the requirement for the next receiver to be able to spend it.

In the above image, Bob will fulfill Alice's requirements in Transactions B's ScriptSig but if it contains only Bob's PK+signed(hash(Transaction A)), I don't understand where exactly does he put the info to prove he fulfilled them to Alice?

[DannyHamilton]

I updated the diagram:

is it correct now?

It's ok as a high level description, but it is lacking in some significant details.  Have you read Satoshi's whitepaper yet?  It has all these details and explains this stuff very simply with diagrams like these:

http://bitcoin.org/bitcoin.pdf

In the above image, Bob will fulfill Alice's requirements in Transactions B's ScriptSig but if it contains only Bob's PK+signed(hash(Transaction A)), I don't understand where exactly does he put the info to prove he fulfilled them to Alice?

He doesn't need to prove it to Alice.  Alice doesn't care.  He needs to prove it to every full node on the entire bitcoin network.  Each and every node will verify that Bob fulfilled the necessary requirements when they receive the transaction, and will refuse to relay the transaction to any peers if he didn't.  Each and every solo miner, or mining pool, will verify that Bob fulfilled the necessary requirement before they add the transaction to a block they are mining, and will refuse to add it if he didn't. Each and every node on the network will verify that Bob fulfilled the requirements when they receive the mined block and will refuse to relay the block or add the block to their own blockchain if he didn't.  If Bob doesn't fulfill the requirements (in the ScriptSig of transaction B), then Transaction B will never be able to leave Bob's wallet/client and get on to the bitcoin network.

[tutak]

He doesn't need to prove it to Alice.  Alice doesn't care.  He needs to prove it to every full node on the entire bitcoin network.  Each and every node will verify that Bob fulfilled the necessary requirements when they receive the transaction, and will refuse to relay the transaction to any peers if he didn't.  Each and every solo miner, or mining pool, will verify that Bob fulfilled the necessary requirement before they add the transaction to a block they are mining, and will refuse to add it if he didn't. Each and every node on the network will verify that Bob fulfilled the requirements when they receive the mined block and will refuse to relay the block or add the block to their own blockchain if he didn't.  If Bob doesn't fulfill the requirements (in the ScriptSig of transaction B), then Transaction B will never be able to leave Bob's wallet/client and get on to the bitcoin network.

Yes i have read it, but it's pretty high level and is honestly badly explained. Anyways I think I got it now. So basically for Bob to send some BTC to Jack he needs to have them himself first, he proves that by placing his PK in scriptSig of Transaction B, which is the same as the PK given by Alice in Transaction A,  he also provides his signature to show that it is him who want's the money sent to Jack. Thanks

[DeathAndTaxes]

One clarification.

Bob's PubKey isn't in TX A.  The Hash of Bob's PubKey is in Tx A.  PubKeyHash.  
This type of transaction is called "Pay to PubKeyHash".  Alice doesn't know Bob's PubKey and doesn't need to know.  She is paying to the hash of Bob's PubKey (which can be computed from the address Bob provided).

In the input of Tx B Bob signs the (simplified) tx with his private key and includes a copy of his PubKey.

When other nodes validate tx B they, hash Bob's PubKey and ensure it matches that of the PubKeyHash in Tx A.  They find tx A by the using the TxId and Index in the input of tx B.  The Tx Id gives the hash of the tx and the index indicates which (of many) outputs is being "spent" here.  Once a node validates the Input of Tx B is valid (corresponds to a real output which hasn't been spent) and has the correct PubKeyHash the node will verify the signature. 

[DannyHamilton]

Yes i have read it, but it's pretty high level and is honestly badly explained. Anyways I think I got it now. So basically for Bob to send some BTC to Jack he needs to have them himself first, he proves that by placing his PK in scriptSig of Transaction B, which is the same as the PK given by Alice in Transaction A,  he also provides his signature to show that it is him who want's the money sent to Jack. Thanks

At a high level, that's close enough.

In actuality, Alice doesn't have Bob's public key, she only has a hash of a hash of the key.

So Alice puts the hash of the hash of the public key in the output of her transaction.  Then Bob puts his actual public key in the ScriptSig of the input of the transaction he is creating.  All the nodes on the network can then hash the public key that Bob has provided, and then hash that hash.  If the result matches the value that Alice put in the output of her transaction, then the public key provided by Bob can be considered to be the public key that is necessary for verifying the signature.

Bob then supplies the signature to show that the spending requirements set by Alice have been met and the value can now be reassigned in a new set of outputs.

Also note that a transaction can have multiple outputs, so the "index" in Bob's transaction indicates which of Alice's possibly multiple outputs are being spent by Bob.