user129189: Transaction 99fc1e5c753459808bac56435b3d45f2fcf0dd73016ea14460d63e9ddf353714 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 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?

user208: 
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.

129189: <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>
 208: <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>
