SIGHASH_SINGLE with no corresponding output

Question

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?

Answer 1

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.