61

Scenario: A is sending 1 BTC to B.

scriptSig appears in the Input Script.

scriptSig = <sig> <pubKey>
  1. Here, public key is the Public Key of the sender, A. (this is the public key corresponding to his Bitcoin Address which has some unspent transaction).

What is the sig part of scriptSig?

scriptPubKey

scriptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

pubKeyHash = Hash of the Public Key of Recipient (in our case, B).

  1. The sender (A) only has the Bitcoin Address of the recipient (B), so how does he get the pubKeyHash from his Bitcoin Address?

Now, this is my understanding so far:

  1. Input Script carries information about the "previous transaction" of the sender and points to the appropriate "output" part of "previous transaction" using an index. The output of the previous transaction is the total available balance for the sender (A) which can be claimed to send Bitcoins to the recipient (B).

  2. This Input Script is also used to verify that the sender (A) is the actual owner of the Bitcoins held in the referenced output of previous transaction.

  3. Output Script tells us, how many bitcoins the Sender wants to Transfer to the Recipient and it also mentions the Bitcoin Address of recipient.

Questions:

  1. The public Key in scriptSig is different from the public Key in scriptPubKey?

  2. How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?

  3. I have tried understanding the example given on wiki which shows how the script is executed in a stack based manner but could not understand it.

I have some more questions, but I think I will ask them in a different question instead of putting it altogether here.

Thanks.

Improve this question
1

6 Answers 6

Reset to default
48

First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend the bitcoins associated with the output if he can prove that he owns the output.

This is where Transaction B and the scriptSig comes into play. Assuming a user wants to send some funds somewhere. He creates a new transaction, and adds outputs to it until he has enough to cover the desired amount. Now he has to prove that he owns those outputs, which he does by providing the output that is needed to claim them, i.e., the public key matching the address and the signatures with the matching private key.

The sender of Transaction A does not yet know the public key, but does know a hash of the public key, because he knows the address he wants to send to. The address is nothing more than the hash of the public key. So the sender now knows all he needs to be able to send the funds to the receiver.

When the receiver wants to spend the funds again he provides the input to the scriptPubKey. As you can see the scriptPubKey consists of taking the public key that was pushed on the stack, duplicating it, hashing it and comparing it to the hash of the public key the output was destined for. If they match we still have both the signature and the public key on the stack, which are used by OP_CHECKSIG to see whether the input had a valid signature attached.

Take this transaction for example. It claims one output, by providing the public key and the matching signature. It then creates two new outputs and specifies the conditions for the next user to claim them.

Improve this answer
5
  • @cdecker Why is there even any need for the sender in Transaction B to compare the HASH160 of the pubkey to the pubKeyHash? Isn't the signature, which if correct assures that the sender has access to the private key of the address of the output she's sending from, enough to verify she can send from that output? It seems needless to supply the pubkey and verify its hash matches, since the pubkey can be quickly derived from the private key.
    – almel
    Commented Jul 22, 2014 at 18:16
  • When funding the sender of Transaction B, the issuer of Transaction A does not know the public key, only it's hash, which is encoded in the address. The creator of Transaction B needs to show the public key, show that it in fact matches the hash in the address and then provide a valid signature using it. If she were not to include the public key and show that it matches the hash, then we are missing an important piece of information, i.e., the public key, and cannot verify the signature.
    – cdecker
    Commented Jul 22, 2014 at 18:43
  • 3
    i guess in the 2nd paragraph "He creates a new transaction, and adds outputs to it ", it should be "adds inputs to it". User will add inputs to a transaction
    – lch
    Commented Oct 4, 2017 at 17:26
  • 3
    I tried to avoid introducing inputs at all since they are simply references to previously created outputs, but it might be confusing you're right.
    – cdecker
    Commented Oct 5, 2017 at 11:09
  • 1
    Might be a little late, but shouldn't the second sentence at the last paragraphe be "It claims one input, by providing .." ?
    – Arthur Attout
    Commented Nov 28, 2017 at 20:43
12

I had the same question as well and spent forever trying to understand it and finally cracked it.

"The sender (A) only has the Bitcoin Address of the recipient (B), so how does he get the pubKeyHash from his Bitcoin Address?"

The key is that sender (A) doesn't need to get the pubKeyHash from "his" Bitcoin Address because it's not relevant. (I also wondered the same thing!)

Think of scriptPubKey happening first. A creates this with B's bitcoin address in place of <pubKeyHash>. That is A's job done. What A has said is "1 BTC now belongs to B but.... only if B can prove that he is the true owner of the bitcoin address that B provided to me". Now take A out of the picture.

B comes along and in his wallet, he sees this 1 BTC amount show up. So technically B "owns" it. But in order for B to spend it, that is send to someone else, B needs to prove that the bitcoin address he gave to A was indeed his. This is where scriptSig comes in. So the <sig> <pubKey> is B's responsibility and B knows all this info anyway.

After reading lots of articles on this, the developer's documentation explains it the best hands down. https://bitcoin.org/en/developer-guide#transactions You just have to read it slowly a few times.

The dev docs also answers your other question of "What is the sig part of scriptSig?"

... data Bob signs includes the txid and output index of the previous transaction, the previous output’s pubkey script, the pubkey script Bob creates which will let the next recipient spend this transaction’s output, and the amount of satoshis to spend to the next recipient.

Improve this answer
1
  • This answer is less confusing then accepted answer..
    – Vijay Chavda
    Commented Oct 3, 2018 at 9:01
3

Please look at the developer's document. It's much clearer. https://bitcoin.org/en/developer-guide#transactions

Improve this answer
1
  • 1
    I agree, developer document has a clearer explanation.
    – Vignesh Chandramohan
    Commented Dec 14, 2016 at 6:01
1 
scriptSig = <sig> <pubKey>

What is the sig part of scriptSig?

It is the signature, made by A with his private key, of the content of the transaction he is creating, except for the scriptSig part (to not be recursive). It is made of <hash of the transaction from which an output is being used> <the index of this output in that transaction> <pubKey> <the current transaction output = <scriptPubKey> <1 BTC> >.

sciptPubKey = OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  1. The sender (A) only has the Bitcoin Address of the recipient (B), so how does he get the pubKeyHash from his Bitcoin Address?

You can find the <pubKeyHash> from the address because the final operations of the address creation do not obfuscate the input. It is merely a base58 encoding of the pubKeyHash padded with some data, i.e. address = base58_encode(<pubKeyHash> || <padding>), thus pubKeyHash = base58_decode(address) ^^ <padding>.

Your understanding is on point except for part:

  1. Input Script carries information about the "previous transaction" of the sender and points to the appropriate "output" part of "previous transaction" using an index. The output of the previous transaction is the total available balance for the sender (A) which can be claimed to send Bitcoins to the recipient (B).

The input script is scriptSig and does not carry the reference to the output being spent. This information is in the input of the current transaction but not formally in the unlocking script.

Questions:

  1. The public Key in scriptSig is different from the public Key in scriptPubKey?

Yes they are different, pubKeyHash = ripemd160(sha256(pubKey)).

  1. How can the signed information of the Sender be verified by the recipient, if they don't share the same Public Key?

scriptSig is included in the input of the transaction (along with the hash of the previous transaction and the index of the ouput being spent) so that everyone has access to pubKey in order to verify that <sig> is valid against <pubKey>.

  1. I have tried to understand the example given on wiki which shows how the script is executed in a stack based manner, but haven't managed.

Well there is not much I could explain differently than any other documentation if you don't provide specifics here.

Improve this answer
-1

Let there be 2 transactions, Transaction A(coinbase) & Transaction B. ScriptPubkey - To lock Transaction A to a Public Key. ScriptSig - Used in Transaction B to unlock Transaction A

Since Transaction A is coinbase (mined by a miner), there will be no ScriptSig. ScriptPubkey of Transaction A is the miner's Public Key script( ie locked to miner's Public Key, so in future he can unlock using his Private Key[ie ScriptSig])

The miner can spend this Bitcoin Transaction to Alice by providing ScriptSig(signed with the miner's Private Key) in the input of Transaction B. Remember Public Key of the miner is generated from his Private Key, it is possible for the Bitcoin program to verify ScriptPubkey of Transaction A from ScriptSig of Transaction B, then if valid the Transaction B will be added to the Blockchain.

The ScriptPubkey of the Transaction B will be the Alice's Public Key, so in future only Alice can spend this Bitcoin using ScriptSig in Transaction C.

Improve this answer
-1

Simple and less technical explanation for newbies: Let Alice be the sender and Bob be the receiver. Alice creates ScriptPubKey corresponding to private keys of Bob's wallet. She then transmits this ScriptPubKey along with satoshis in the bitcoin network and the satoshis start appearing in the Bob's wallet as balance. So, ScriptPubKey acts like a 'lock'.

Now for Bob to spend those satoshis he must satisfy the conditions Alice placed in the ScriptPubKey. So he creates scriptSig (or signature script) as the solution that satisfies the conditions of ScriptPubKey in order to spend those satoshis. Here, scriptSig acts like keys to ScriptPubKey lock.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.