1

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?

1 Answer 1

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.