<p>The signature is actually valid. The sighash is <code>8cc2772af5af61583c5a7ae89f777d3173afa470ce8b1bfa5f8d4b9a54635ccb</code> and you'll find that the signature does indeed validate.</p>
<p>So the question is how is this signature valid? The trick is actually public key recovery. Given a signature and a message, it's possible to calculate a public key that makes the triplet valid.</p>
<p>You'll notice that the hash of the signature is in the redeemScript, not the public key. The public key is not committed to at all as it is not included in the sighash message. Thus the person who created this transaction was able to compute their sighash, combine it with the signature, and compute the public key that would make it valid.</p>

CC BY-SA 4.0
2023-11-10T02:40:44.820Z
It turns out I was calculating the sighash incorrectly, using the output script instead of the redeem script, it checks out now. Public key recovery didn't occur to me, as I didn't quite realize the public key wasn't committed at all and could be freely adjusted to match the signature. Thanks!
Vojtěch Strnad
CC BY-SA 4.0
2023-11-10T01:28:55.840Z
2023-11-10T01:28:55.840Z
Ava Chow
<p>Transaction in question: <a href="https://mempool.space/tx/16ac7736552c5791cff5643e6104c76c24018236b2193e014b308efea4f32f81" rel="nofollow noreferrer">16ac7736552c5791cff5643e6104c76c24018236b2193e014b308efea4f32f81</a></p>
<p>The P2SH input has a strange redeem script:</p>
<pre><code>OP_DUP
OP_HASH160
OP_PUSHBYTES_20 caaa64d70e561ca95bbb4f1220636f625494bf70
OP_EQUALVERIFY
OP_SWAP
OP_CHECKSIG
</code></pre>
<p>This is almost the same as a P2PKH script, except that the hash is checked against the <em>signature</em>, not the public key. It shouldn't be possible to satisfy this script, because the signature message commits to the script, and therefore the signature itself. Without this circular problem, we could have covenants in Bitcoin today by putting the signature (or its hash) into the script.</p>
<p>Indeed, while the hash checks out, I'm not able to verify the signature against the input's signature message. Additionally, the signature itself is strange, it's only 65 bytes and most of its bytes are <code>20</code>. So how is this transaction valid?</p>

CC BY-SA 4.0
2023-11-10T00:08:16.690Z
I'm new to Bitcoin, so I'm not sure how much I can help you, but as far as I know, the hash preimage for the P2SH goes with the redeem script on the place of ScriptSig, which in this case includes the public key hash, not the signature itself. So there will be no *circular problem*.
LeaBit
<transactions><script><signature><p2sh><validation>
How is this transaction valid?
Vojtěch Strnad
# How is this transaction valid?

(Asked by: username_0 on 2023-11-09)

Transaction in question: [16ac7736552c5791cff5643e6104c76c24018236b2193e014b308efea4f32f81](https://mempool.space/tx/16ac7736552c5791cff5643e6104c76c24018236b2193e014b308efea4f32f81)

The P2SH input has a strange redeem script:

```
OP_DUP
OP_HASH160
OP_PUSHBYTES_20 caaa64d70e561ca95bbb4f1220636f625494bf70
OP_EQUALVERIFY
OP_SWAP
OP_CHECKSIG

```

This is almost the same as a P2PKH script, except that the hash is checked against the *signature*, not the public key. It shouldn't be possible to satisfy this script, because the signature message commits to the script, and therefore the signature itself. Without this circular problem, we could have covenants in Bitcoin today by putting the signature (or its hash) into the script.

Indeed, while the hash checks out, I'm not able to verify the signature against the input's signature message. Additionally, the signature itself is strange, it's only 65 bytes and most of its bytes are `20`. So how is this transaction valid?

**Tags:** transactions, script, signature, p2sh, validation

> **Comments:**
> **username_1**: I'm new to Bitcoin, so I'm not sure how much I can help you, but as far as I know, the hash preimage for the P2SH goes with the redeem script on the place of ScriptSig, which in this case includes the public key hash, not the signature itself. So there will be no *circular problem*.  

---

## 1 answers

### Answer by username_2 on 2023-11-10. Score: 4 | Accepted answer

The signature is actually valid. The sighash is `8cc2772af5af61583c5a7ae89f777d3173afa470ce8b1bfa5f8d4b9a54635ccb` and you'll find that the signature does indeed validate.

So the question is how is this signature valid? The trick is actually public key recovery. Given a signature and a message, it's possible to calculate a public key that makes the triplet valid.

You'll notice that the hash of the signature is in the redeemScript, not the public key. The public key is not committed to at all as it is not included in the sighash message. Thus the person who created this transaction was able to compute their sighash, combine it with the signature, and compute the public key that would make it valid.

> **Comments:**
> **username_0**: It turns out I was calculating the sighash incorrectly, using the output script instead of the redeem script, it checks out now. Public key recovery didn't occur to me, as I didn't quite realize the public key wasn't committed at all and could be freely adjusted to match the signature. Thanks!  

---

