Understanding elementary bitcoin signature scripts

[sdp]

I was reading the wiki https://en.bitcoin.it/wiki/Script and came across this example.

Now the first operation is OP_DUP but there is nothing explicitly put on the stack.  It seems that <sig> and <PubKey> which is mentioned in the later prose, need to be pushed first and that has been omitted from the diagram below.  

When the transaction is spent it is provided <sig> <PubKey>.

Suppose Alice is sending to Bob.  Whose <PubKey> is used and what is this sig derived from?

Code:

  76       A9             14
OP_DUP OP_HASH160    Bytes to push

89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA   88         AC
                      Data to push                     OP_EQUALVERIFY OP_CHECKSIG

Thanks in advance...

[gmaxwell]

Now the first operation is OP_DUP

The results from the scriptSig are already on the stack when the scriptPubKey executes. So the signing party is providing the pubkey, and thats whats getting duplicated by that OP_DUP.

[etotheipi]

More specifically, you can think of TxOut scripts as a puzzle that needs to be solved in order to move the coins.  Anyone can spend the coins if they can put the correct data on the stack that causes the TxOut script to evaluate to true.  It just so happens that the most common TxOut script type is one that requires the TxInScript to contain a public key that hashes to the hash160 value and valid signature from the associated private key "to solve the puzzle."

[sdp]

That's fine, and I guess this hashed public key is an encoded bitcoin address.  The question is when is this script made.

For example, Alice has 1 BTC, and sells it to Bob.  In order to transfer to Bob she uses her public key to sign the transaction over to Bob.  But does that mean that Alice' s client creates a new script with Bob' s encoded bitcoin address (the 14 byte blob there) but what is actually used for allowing the transaction to Bob is the script that was there when Alice received them?

sdp

[etotheipi]

All 21 million coins that will ever exist, are floating in the Bitcoin aether, protected by one of these TxOut scripts.  When your wallet says that you "own" X coins, it's because it has identified that there is a set of TxOuts totaling X coins, with scripts that you know you can "solve" (because they have your public key encoded in them).   The process of "sending" coins to someone is producing TxIn scripts in a new transaction that cause those old TxOut scripts to evaluate to true, and creating new TxOut scripts that can only be spent by the new owner's private key.

You can think of all the coins on the network as a set of floating, unspent TxOuts, waiting for someone to provide a TxIn that causes its script to evaluate to true (because it essentially executes {TxInScript | TxOutScript}).  Every transaction eats/destroys a number of TxOuts, and creates a set of new TxOuts with values adding up to the same amount (or close to the same amount; any leftover is claimed by the miner who mines the transaction, as a fee)

[sdp]

Okay, I think I am only looking at TxOut scripts.  How are TxIn scripts different?  What are they for?

Here is the example in the wiki:

Code:

Inputs:
 01                                                - number of transaction inputs

Input 1:
 6D BD DB 08 5B 1D 8A F7  51 84 F0 BC 01 FA D5 8D  - previous output (outpoint)
 12 66 E9 B6 3B 50 88 19  90 E4 B4 0D 6A EE 36 29
 00 00 00 00

 8B                                                - script is 139 bytes long

 48 30 45 02 21 00 F3 58  1E 19 72 AE 8A C7 C7 36  - signature script (scriptSig)
 7A 7A 25 3B C1 13 52 23  AD B9 A4 68 BB 3A 59 23
 3F 45 BC 57 83 80 02 20  59 AF 01 CA 17 D0 0E 41
 83 7A 1D 58 E9 7A A3 1B  AE 58 4E DE C2 8D 35 BD
 96 92 36 90 91 3B AE 9A  01 41 04 9C 02 BF C9 7E
 F2 36 CE 6D 8F E5 D9 40  13 C7 21 E9 15 98 2A CD
 2B 12 B6 5D 9B 7D 59 E2  0A 84 20 05 F8 FC 4E 02
 53 2E 87 3D 37 B9 6F 09  D6 D4 51 1A DA 8F 14 04
 2F 46 61 4A 4C 70 C0 F1  4B EF F5

 FF FF FF FF 

I don't know of any standard transactions that end in F5.  It is quite different from those of txOut. 

Thanks for your answers etotheipi.

[etotheipi]

Okay, I think I am only looking at TxOut scripts.  How are TxIn scripts different?  What are they for?

All transactions have inputs (TxIns) and outputs (TxOuts). 

The TxOuts are where the coins are going, identified by the TxOut script (which is the "puzzle" I was speaking about). 

In order to spend coins that you "own", you create a transaction and make one TxIn for each TxOut you want to spend.  So the new transaction references a bunch of TxOuts from previous transactions in the global history.  The TxIn simultaneously identifies what TxOuts you are spending and supplies the data to prove that you are authorized to spend them (public key and a signature over the entire transaction).

The TxOut script is the "puzzle" that needs to be solved, and your wallet app tells you that you "own" coins because it has identified that it knows how to spend them.  When you do spend them, you put your sig and pubkey into a TxIn script, and those will be on the stack when the TxOut script is executed.

Let me reiterate:  each TxIn corresponds to a single previous-TxOut being spent.  And that TxOut is fully spent and not needed anymore (this would be pruning:  right now all nodes remember all TxOuts, even the ones that are already spent, but you really only need to remember/store the TxOuts that haven't been spent).  Therefore, a transaction "eats" a certain number of TxOuts, and then creates a bunch of new TxOuts that can later be spent the same way.

[michagogo]

The way the validation works is simple -- the scriptSig is executed, and then the scriptPubKey is executed against the same stack. The scriptSig for a standard pay-to-pubkey-hash transaction simply pushes 2 pieces of data -- first the signature, and then the pubkey that made that signature, leaving those 2 items on the stack. At that point, the scriptPubKey takes over. The pubkey is duplicated (OP_DUP), the copy hashed (OP_HASH160) and compared to the pubkey hash in the scriptPubKey, aborting if the hashes don't match (OP_EQUALVERIFY), leaving only the signature and the pubkey on the stack, at which point OP_CHECKSIG, well, checks the signature.