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?

Zephyrus
  • 536
  • 2
  • 10

1 Answers1

3

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.

Pieter Wuille
  • 98,249
  • 9
  • 183
  • 287
  • 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 May 27 '23 at 15:01
  • 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 Aug 25 '23 at 16:01