<blockquote>
<p>The explanation at the bottom of this site says that if there is no corresponding output, then the message that gets signed is always <code>0100000000000000000000000000000000000000000000000000000000000000</code>. However, the public key fails to verify this piece of data for the signature from inputs 1 - 4.</p>
</blockquote>
<p>That's almost correct. When a legacy (pre-segwit) transaction input has a signature with SIGHASH_SINGLE, and no corresponding output at the same index, the message <em>hash</em> signed is <code>0x0100000000000000000000000000000000000000000000000000000000000000</code>. ECDSA specifies that the message is hashed before being converted to a scalar. In Bitcoin, that is usually accomplished by a double-SHA256 hash. But in the case of this SIGHASH_SINGLE mismatch condition, the signature is created as if the <code>0x0100000000000000000000000000000000000000000000000000000000000000</code> is the <em>output</em> of the double-SHA256 hash. That arguably makes it not really an ECDSA signature, and (hopefully) tools that aren't aware of Bitcoin's specific rules will not consider this a valid signature.</p>

CC BY-SA 4.0
2023-05-27T15:01:22.330Z
Hi! I have tried to verify this signature and I believe I have correctly follow the instructions. The verification still failed. Any chance someone can spot the mistake ?
https://gist.github.com/rllola/3a6be4222c7b52f934c28843e7b965aa
rllola
CC BY-SA 4.0
2023-08-25T16:01:44.737Z
My mistake was that I was using the wrong function to verify the signature in python instead of `verify` you should use `verify_digest` if you are using the ecdsa lib.

I have updated the gist : https://gist.github.com/rllola/3a6be4222c7b52f934c28843e7b965aa

I hope it will help people.
rllola
CC BY-SA 4.0
2022-08-11T21:36:04.867Z
2022-08-11T21:36:04.867Z
Pieter Wuille
<p>Transaction <a href="https://explorer.blockstream.com/tx/99fc1e5c753459808bac56435b3d45f2fcf0dd73016ea14460d63e9ddf353714?expand" rel="nofollow noreferrer">99fc1e5c753459808bac56435b3d45f2fcf0dd73016ea14460d63e9ddf353714</a> is an interesting example.</p>
<p>This transaction has 5 inputs and 1 output. All of the input scripts include 1 public key and 1 signature. They all use the same public key and all of the signatures have SIGHASH byte 03 (SIGHASH_SINGLE). Inputs 1 - 4 all have the exact same signature, which means the same piece of data was used to create the signature.</p>
<p>The public key for all inputs is:</p>
<pre><code>044edfcf9dfe6c0b5c83d1ab3f78d1b39a46ebac6798e08e19761f5ed89ec83c108172c4776865f02047b39cd704135c00c1b00085e0d1b9255405ac7079fa50a2
</code></pre>
<p>The signature for inputs 1 - 4 is:</p>
<pre><code>3045022100912f994094193109a9faedf7ef855220638f95ac51c66d4eb46740dd1c0813fa0220100bc99adb8b64fb784173ca8883a78835e156b74f143c02e071dc82695e847203
</code></pre>
<p>However, there is only one output in the transaction, so there is no corresponding output for inputs 1 - 4. When this transaction was added to the blockchain, all of those inputs had to be verified. What data was signed in order to create the signature for inputs 1 - 4?</p>
<p>The explanation at the bottom of <a href="https://reference.cash/protocol/blockchain/transaction/transaction-signing" rel="nofollow noreferrer">this site</a> says that if there is no corresponding output, then the message that gets signed is always <code>0100000000000000000000000000000000000000000000000000000000000000</code>. However, the public key fails to verify this piece of data for the signature from inputs 1 - 4.</p>
<p>What data is signed to produce a signature in a case like this?</p>

<message-signing><message-verification><sighash-flags>
SIGHASH_SINGLE with no corresponding output
Zephyrus
# SIGHASH_SINGLE with no corresponding output

(Asked by: username_0 on 2022-08-11)

Transaction [99fc1e5c753459808bac56435b3d45f2fcf0dd73016ea14460d63e9ddf353714](https://explorer.blockstream.com/tx/99fc1e5c753459808bac56435b3d45f2fcf0dd73016ea14460d63e9ddf353714?expand) is an interesting example.

This transaction has 5 inputs and 1 output. All of the input scripts include 1 public key and 1 signature. They all use the same public key and all of the signatures have SIGHASH byte 03 (SIGHASH\_SINGLE). Inputs 1 - 4 all have the exact same signature, which means the same piece of data was used to create the signature.

The public key for all inputs is:

```
044edfcf9dfe6c0b5c83d1ab3f78d1b39a46ebac6798e08e19761f5ed89ec83c108172c4776865f02047b39cd704135c00c1b00085e0d1b9255405ac7079fa50a2

```

The signature for inputs 1 - 4 is:

```
3045022100912f994094193109a9faedf7ef855220638f95ac51c66d4eb46740dd1c0813fa0220100bc99adb8b64fb784173ca8883a78835e156b74f143c02e071dc82695e847203

```

However, there is only one output in the transaction, so there is no corresponding output for inputs 1 - 4. When this transaction was added to the blockchain, all of those inputs had to be verified. What data was signed in order to create the signature for inputs 1 - 4?

The explanation at the bottom of [this site](https://reference.cash/protocol/blockchain/transaction/transaction-signing) says that if there is no corresponding output, then the message that gets signed is always `0100000000000000000000000000000000000000000000000000000000000000`. However, the public key fails to verify this piece of data for the signature from inputs 1 - 4.

What data is signed to produce a signature in a case like this?

**Tags:** message-signing, message-verification, sighash-flags


---

## 1 answers

### Answer by username_1 on 2022-08-11. Score: 3 | Accepted answer

> The explanation at the bottom of this site says that if there is no corresponding output, then the message that gets signed is always `0100000000000000000000000000000000000000000000000000000000000000`. However, the public key fails to verify this piece of data for the signature from inputs 1 - 4.

That's almost correct. When a legacy (pre-segwit) transaction input has a signature with SIGHASH\_SINGLE, and no corresponding output at the same index, the message *hash* signed is `0x0100000000000000000000000000000000000000000000000000000000000000`. ECDSA specifies that the message is hashed before being converted to a scalar. In Bitcoin, that is usually accomplished by a double-SHA256 hash. But in the case of this SIGHASH\_SINGLE mismatch condition, the signature is created as if the `0x0100000000000000000000000000000000000000000000000000000000000000` is the *output* of the double-SHA256 hash. That arguably makes it not really an ECDSA signature, and (hopefully) tools that aren't aware of Bitcoin's specific rules will not consider this a valid signature.

> **Comments:**
> **username_2**: Hi! I have tried to verify this signature and I believe I have correctly follow the instructions. The verification still failed. Any chance someone can spot the mistake ? https://gist.github.com/username_2/3a6be4222c7b52f934c28843e7b965aa  
> **username_2**: My mistake was that I was using the wrong function to verify the signature in python instead of `verify` you should use `verify_digest` if you are using the ecdsa lib.  I have updated the gist : https://gist.github.com/username_2/3a6be4222c7b52f934c28843e7b965aa  I hope it will help people.  

---

