What goes in to the message of a transaction signature?-优快云博客

本文详细介绍了如何为比特币交易创建签名。通过逐步解析未签名交易，解释了如何构造用于签名的消息，包括移除所有脚本签名、插入相应的脚本公钥等步骤，并最终生成用于ECDSA签名的大整数。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

I'm trying to create my own transaction from scratch, just to see how it works.

I'm currently working backwards, and I'm stuck on the signature of a transaction...

Here's my unsigned transaction:

0100000001ff8ddda903d6e76b6c6211e1b8f3b4eaaa8d080aaa008d4b05ca01ea39116cbf0000000000ffffffff0170c9fa02000000001976a9147865b0b301119fc3eadc7f3406ff1339908e46d488ac00000000

I like to think I understand each segment of this serialized transaction. However, I don't know how to recreate the signature. I know I need to create a message and send it through an ECDSA signing function, but I do not know how to construct the message.

So basically, what goes in to the message to create a signature for this transaction?

The message whose numerically interpreted hash, z, is used to construct the ECDSA signature (r,s) is constructed as follows:

Start with your unsigned transaction.
Remove all scriptSigs (for example, if you have multiple txins, some of which may already be signed, remove those signatures). For your example this step has no effect since there's only one txin.
For the txin you're about to sign, find the corresponding UTXO's scriptPubKey, and set the current txin's scriptSig to be the value of the UTXO's scriptPubKey.
Serialize the transaction.
Append the SIGHASH type, serialized as a 32-bit little-endian integer (the default SIGHASH_ALL has a value of 1).

The resulting byte stream is double SHA-256 hashed and interpreted as a big-endian integer (and used for ECDSA's z parameter).

For your example, the scriptPubKey to insert comes from the UTXO at txid bf6c1139ea01ca054b8d00aa0a088daaeab4f3b8e111626c6be7d603a9dd8dff index 0, specifically it is OP_DUP OP_HASH160 d951eb562f1ff26b6cbe89f04eda365ea6bd95ce OP_EQUALVERIFY OP_CHECKSIG. Serialized, this is 76a914d951eb562f1ff26b6cbe89f04eda365ea6bd95ce88ac. The transaction constructed after completing step 3 is:

"txid" : "a80d616ca30a003448157b92df511ad5294e225fd77fc3f2d5dc367a4d27f375",
"version" : 1,
"locktime" : 0,
"vin" : [
    {
        "txid" : "bf6c1139ea01ca054b8d00aa0a088daaeab4f3b8e111626c6be7d603a9dd8dff",
        "vout" : 0,
        "scriptSig" : {
            "asm" : "OP_DUP OP_HASH160 d951eb562f1ff26b6cbe89f04eda365ea6bd95ce OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a914d951eb562f1ff26b6cbe89f04eda365ea6bd95ce88ac"
        },
        "sequence" : 4294967295
    }
],
"vout" : [
    {
        "value" : 0.49990000,
        "n" : 0,
        "scriptPubKey" : {
            "asm" : "OP_DUP OP_HASH160 7865b0b301119fc3eadc7f3406ff1339908e46d4 OP_EQUALVERIFY OP_CHECKSIG",
            "hex" : "76a9147865b0b301119fc3eadc7f3406ff1339908e46d488ac",
            "reqSigs" : 1,
            "type" : "pubkeyhash",
            "addresses" : [
                "1Bybuago2EGrB7Z6jJG2GAFDojp6Njr8fa"
            ]
        }
    }
]

It may look strange to have a scriptPubKey-style script in the scriptSig field, but that's the way it is. Once serialized, this becomes:

1: 0100000001ff8ddda903d6e76b6c6211e1b8f3b4eaaa8d080aaa008d4b05ca01ea39116cbf0000000019
2: 76a914d951eb562f1ff26b6cbe89f04eda365ea6bd95ce88ac
3: ffffffff0170c9fa02000000001976a9147865b0b301119fc3eadc7f3406ff1339908e46d488ac00000000
4: 01000000

Above, line 2 is the serialized scriptPubKey, and line 4 is the appended SIGHASH_ALL. This full message is then hashed and interpreted as an int, resulting in z=78289050778760245857840977078575435990304898491073736369300700378208907476567 , which along with the private key is used to finally create the ECDSA signature.

Note that step 2 above assumes a SIGHASH_ALL signature. Other signature types remove additional parts of the transaction before signing, please see the SIGHASH types link for more details.