0

Trying to learn the basics of the bitcoin's standard transaction script here. For a transaction where Alice has sent coins to Bob, who is now trying to redeem them, we have the concatenated scriptSig and scriptPubKey as below

<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

When we say that the recipient must specify the PubKey and Sig in scriptSig, what exactly is in Sig? My understanding is that Bob is signing the entire transaction with his private key and then this is what OP_CHECKSIG verifies. In this case, the inputs to OP_CHECKSIG are the transaction data and the public key. Please let me know if this is correct and if not, then what exactly are the inputs that OP_CHECKSIG requires?

Secondly, what is the point of the first part of the script that checks the match between scriptSig's PubKey and scriptPubKey? Could we not instead get a simpler script where the outputs of a transaction specify the public key itself instead of the hash of the public key? In this case, we would simply have

<Sig> <PubKey> OP_CHECKSIG,

where Sig comes from the Bob and PubKey from Alice.

3

The signature is mathematically generated using the private key and the message, but is not the message itself (it uses the hash of the message during the signing process, the message is not recoverable from just the signature). It's just a value (specifically, it is 2 numbers, called r and s) which can be verified against the public key and the message to see if it's a valid signature. In this case the message is the transaction data, which also protects the transaction from being modified because if it was modified, the signature would become invalid. If you're interested, you can read about the Elliptic Curve Digital Signature Algorithm (ECDSA) here.

Indeed it would be possible to use just the public key without the hashing steps, this is known as Pay to Public Key, P2PK and is also an acceptable output type. Please note, though, that a bitcoin address is not the public key itself. To create this type of output, the sender would have to know the public key, to put it in the output. It is not possible to obtain the public key from a bitcoin address because the address is a hash of that public key, to make it shorter and easier for common use, and is thus a non-injective trapdoor function.

  • So just to clarify, the message you speak of is something that has transaction information in it, yes? I had this slight misunderstanding that the message was Bob's public key hash itself (which would be dangerous, since anyone can replicate it after he signs it one time). Therefore the <sig> is different for each transaction, Please let me know if my understanding is correct - Thank you! – user1936752 Aug 5 '17 at 4:58
  • 1
    Yes in this case the message is the transaction data itself, I'll update my answer – MeshCollider Aug 5 '17 at 6:44
  • 1
    I think MeshCollider has answered already, just wanted to point out to Ken Shirriff's document. He gives a good step by step overview how a transaction is constructed, and then signed: righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html – pebwindkraft Aug 5 '17 at 7:07
  • Isn't in P2PK the address public key itself? And in P2PKH the address the hash of the public key? – croraf Nov 26 '17 at 22:07
  • @croraf yes that's what the second paragraph of the answer says :) – MeshCollider Nov 27 '17 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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