<p>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) <a href="https://en.m.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm" rel="nofollow noreferrer">here</a>.</p>

<p>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 <strong>not</strong> 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. </p>

CC BY-SA 3.0
2017-08-05T04:58:34.600Z
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
CC BY-SA 3.0
2017-08-05T06:44:08.730Z
Yes in this case the message is the transaction data itself, I'll update my answer
meshcollider
CC BY-SA 3.0
2017-08-05T07:07:34.710Z
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: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
pebwindkraft
CC BY-SA 3.0
2017-11-26T22:07:24.933Z
Isn't in P2PK the address public key itself? And in P2PKH the address the hash of the public key?
croraf
CC BY-SA 3.0
2017-11-27T00:37:31.683Z
@croraf yes that's what the second paragraph of the answer says :)
meshcollider
CC BY-SA 3.0
2017-08-04T20:31:50.820Z
2017-08-05T06:46:25.003Z
2017-08-05T06:46:25.003Z
meshcollider
<p>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</p>

<p><code>&lt;Sig&gt; &lt;PubKey&gt; OP_DUP OP_HASH160 &lt;PubkeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG</code></p>

<p>When we say that the recipient must specify the <code>PubKey</code> and <code>Sig</code> in <code>scriptSig</code>, what exactly is in <code>Sig</code>? My understanding is that Bob is signing the entire transaction with his private key and then this is what <code>OP_CHECKSIG</code> verifies. In this case, the inputs to <code>OP_CHECKSIG</code> 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 <code>OP_CHECKSIG</code> requires?</p>

<p>Secondly, what is the point of the first part of the script that checks the match between <code>scriptSig</code>'s <code>PubKey</code> and <code>scriptPubKey</code>? 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</p>

<p><code>&lt;Sig&gt; &lt;PubKey&gt; OP_CHECKSIG</code>,</p>

<p>where <code>Sig</code> comes from the Bob and <code>PubKey</code> from Alice.</p>

<checksig><p2pkh>
Bitcoin P2PKH transaction - two questions
user1936752
# Bitcoin P2PKH transaction - two questions

(Asked by: username_0 on 2017-08-04)

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.

**Tags:** checksig, p2pkh


---

## 1 answers

### Answer by username_1 on 2017-08-04. Score: 2 | Accepted answer

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](https://en.m.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm).

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.

> **Comments:**
> **username_0**: 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!  
> **username_1**: Yes in this case the message is the transaction data itself, I'll update my answer  
> **username_2**: 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: http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html  
> **username_3**: Isn't in P2PK the address public key itself? And in P2PKH the address the hash of the public key?  
> **username_1**: @username_3 yes that's what the second paragraph of the answer says :)  

---

