pubkey and pubkeyHash

[23g]

In pay-to-PubkeyHash:
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

what do pubkey and pubKeyHash stand for?

Since the script will check the validity of signature, I guess pubKey is the pubKey of the sender?
But is <pubKeyHash> the hash of receiver's public key?
Then what's the point of checking sender's public key with receiver's? They can't match.


Input:
Previous tx: f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
Index: 0
scriptSig: 304502206e21798a42fae0e854281abd38bacd1aeed3ee3738d9e1446618c4571d10
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501

Output:
Value: 5000000000
scriptPubKey: OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d
OP_EQUALVERIFY OP_CHECKSIG

<pubkey>90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501
<pubkeyHash>404371705fa9bd789a2fcd52d2c580b65d35549d
I just want to know the owner of these two keys. Sender or receiver?

[laurentmt]

A scriptPubKey (with pubKeyHash) is associated to the output of a transaction (let's say Tx1).
A scriptSig (with pubkey) is associated to the input of a transaction (let's say Tx2).

Pubkey is revealed when the user wants to spend an utxo previously received (example: Tx2 consumes an output of Tx1).

<pubkeyHash> (appearing in Tx1) is the hash of <pubkey> (appearing in Tx2)

To summarize: All receiver will become a sender (except hardcore hodlers )

[23g]

A scriptPubKey (with pubKeyHash) is associated to the output of a transaction (let's say Tx1).
A scriptSig (with pubkey) is associated to the input of a transaction (let's say Tx2).

Pubkey is revealed when the user wants to spend an utxo previously received (example: Tx2 consumes an output of Tx1).

<pubkeyHash> (appearing in Tx1) is the hash of <pubkey> (appearing in Tx2)

To summarize: All receiver will become a sender (except hardcore hodlers )

Thanks, but let's say Alice sends a transaction to Bob using a previous tx from Carol.
then in the example above.

who is the owner of the public key<pubkey>? (90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501)

[DeathAndTaxes]

Alice. 

When Carol sent coins to Alice it was a Pay2PubKeyHash transaction.  The address Alice gave Carol contains the PubKeyHash.  So the output of Carol's txn (called PkScript) contains only the PubKeyHash.

When Alice spends that txn she needs to include in the input (ScriptSig) the PubKey which hashes to the PubKeyHash in the prior txn.

[23g]

Alice.  

When Carol sent coins to Alice it was a Pay2PubKeyHash transaction.  The address Alice gave Carol contains the PubKeyHash.  So the output of Carol's txn (called PkScript) contains only the PubKeyHash.

When Alice spends that txn she needs to include in the input (ScriptSig) the PubKey which hashes to the PubKeyHash in the prior txn.

So in this transaction,
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 is Alice's public key.
And in the output ,
the <pubkeyhash> 404371705fa9bd789a2fcd52d2c580b65d35549d should be the receiver Bob's public key hash?

But the script will verify if <pubKeyHash> is the hash of <pubKey>. How can Alice's public key relate to Bob's, they won't match right?

[DeathAndTaxes]

But the script will verify if <pubKeyHash> is the hash of <pubKey>. How can Alice's public key relate to Bob's, they won't match right?

The script verifies the pubkey in the current txn hashes to the pubkeyhash in the output of the PRIOR txn.

[laurentmt]

@23g: For a complete overview of the mechanism, I recommend you this chapter of the excellent developer guide.

[DannyHamilton]

So in this transaction,
90db022100e2ac980643b0b82c0e88ffdfec6b64e3e6ba35e7ba5fdd7d5d6cc8d25c6b241501 is Alice's public key.
And in the output ,
the <pubkeyhash> 404371705fa9bd789a2fcd52d2c580b65d35549d should be the receiver Bob's public key hash?

But the script will verify if <pubKeyHash> is the hash of <pubKey>. How can Alice's public key relate to Bob's, they won't match right?

Tx_1 Carol to Alice

Code:

Input:
    TXID:
    VOut:
    scriptSig:
Output:
    value:
    scriptPubKey:

In the above, Carol supplies a TXID and vout where she previously received some bitcoins that she is now sending to Alice.  Carol needs to prove that she is authorized to spend the bitcoins that were assigned to the previously unspent output.  Therefore, in the ScriptSig of Tx_1, she provides her public key (proving that it is the public key that hashes to the value that was stored in that previous output's scriptPubKey). She also provides, in the ScriptSig of Tx_1, a signature of Tx_1 using the private key that is associated with the public key that she provided.  The signature can then be validated by EVERYONE to match the public key, and the pubic key can be validated by EVERYONE to match the hash in that previous transaction output.

Now that she has proven that she is authorized to spend that previously unspent output that is referenced in TXID  & vout, Carol assigns a value of bitcoins to the new output that this transaction creates.  She includes, in the scriptPubKey, the public key hash that Alice has given her (it is acquired by the wallet software from the bitcoin address).

Tx_2 Alice to Bob

Code:

Input:
    TXID:
    VOut:
    scriptSig:
Output:
    value:
    scriptPubKey:

In the above, Alice supplies the TXID of Tx_1, and a VOut of 0 (since the output that paid Alice in Tx_1 was the first output).  She needs to prove that she is authorized to spend the bitcoins that were assigned to the output in Tx_1.  Therefore, she provides her public key (proving that it is the public key that hashes to the value that was stored in the scriptPubKey of Tx_1). She provides a signature of Tx_2 using the private key that is associated with her public key. The signature can then be validated by EVERYONE to match the public key that she provided, and the pubic key can be validated by EVERYONE to match the hash in Tx_1.

Now that she has proven that she is authorized to spend the output that was created in Tx_1, Alice assigns a value of bitcoins to the new output that Tx_2 creates.  She includes, in the scriptPubKey, the public key hash that Bob has given her (it is extracted from the bitcoin address by the wallet software).




    

[loan4]

I really never heard of pubkey or pubkeyHash ? Please help me for explaination it

Sincere thanks !

[fbueller]

To me the nomenclature is a bit frustrating. I prefer the terms output script and input script. The scriptPubKey and scriptSig fields are scripts, they don't have to contain a pubkey, a signature, etc. The reason they were named this way is because normally the output script contains a public key which 'locks' the funds, and the input script contains a signature (or a signature and public key - it depends, will get to that in a sec) which verifies against the previous output scripts public key. It indicates the type of that that will be included, but it doesn't necessarily have to be that way.

I'm actually a bit confused about your example transaction, because public keys don't start with 90. What you've found is a transaction that spends newly mined coins  https://www.blocktrail.com/BTC/tx/f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6

You can see on that page, that the output script is this:

Code:

<public Key> OP_CHECKSIG

This type of output script is known as a pay-to-pubkey script - there is no pubkey hash here, and that's because addresses weren't always used on the network. Pay-to-pubkey-hash preserves the privacy of the recipient, because the public key is revealed known, and the recipient address is shorter than a public key.


So looking at the transaction you specifically refered to in your post: https://www.blocktrail.com/BTC/tx/5a4ebf66822b0b2d56bd9dc64ece0bc38ee7844a23ff1d7320a88c5fdb2ad3e2 which spends these newly mined coins:

The only input spends the mined coins. Look at the input script here - there is only one field, the signature. This is what confused me, because you said there was a public key there The client will execute [scriptSig] [scriptPubKey], so your script runs like this: [sig] [pubkey] OP_CHECKSIG - since sig and pubkey are supplied as input to OP_CHECKSIG.

Now look that your transactions output script. It's different to the that of the mined coins, it looks like:

Code:

OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d OP_EQUALVERIFY OP_CHECKSIG

That's very different to the first transaction - it's no longer pay-to-pubkey, but pay-to-pubkey-hash. There is no public key revealed, but instead the public key now needs to be included in the input script.

Code:

[scriptSig] [scriptPubKey]
[sig pubkey] [OP_DUP OP_HASH160 hash OP_EQUALVERIFY OP_CHECKSIG]
  ... several steps pass while sig, pubkey are pushed, the pubkey is duplicated, the new one converted to it's hash, confirmed to match the hash, and the hashes removed then.
sig pubkey OP_CHECKSIG

This last step is the same as a pay-to-pubkey transaction to the client, except this time the public key is provided in the scriptSig instead of the scriptPubKey. The naming gets annoying, doesn't it

Previous Tx f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6
  
  - Owners public key: 04283338ffd784c198147f99aed2cc16709c90b1522e3b3637b312a6f9130e0eda7081e373a96d3 6be319710cd5c134aaffba81ff08650d7de8af332fe4d8cde20 (located in output script)
  - Owners public key hash: not known! the public key is already known by the time the recipient has his funds.

Your Tx 5a4ebf66822b0b2d56bd9dc64ece0bc38ee7844a23ff1d7320a88c5fdb2ad3e2
  - Owners public key: 04d4fb35c2cdb822644f1057e9bd07e3d3b0a36702662327ef4eb799eb219856d0fd884fce43082 b73424a3293837c5f94a478f7bc4ec4da82bfb7e0b43fb218cc not known until the user spends from this address
  - Owners public key hash: 404371705fa9bd789a2fcd52d2c580b65d35549d