1

I am trying to figure out how to produce a valid signed transaction to consume BTC from a multisig address.

1) First let's look into producing a signature for an UTXO associated to a regular address:

Assume we are creating a transaction to consume a single UTXO, output 0 of transaction 1111111111111111111111111111111111111111111111111111111111111111 (hex), depositing 1 BTC to address 147Us9aEq2PvBC5wobBJw1yEpQEbPKzssA, for which the HASH160 is 2222222222222222222222222222222222222222 (hex).

This would be the raw transaction before signing, formatted for readability:

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  00
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

Assume the UTXO is associated to the following key pair and regular address:

L2hYQuKeAUr4hLAdDspnwm4YCcFb222REdW34WsmonEeJP5Wp4qt
02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
15Rrie5X6VgDRVwMvB63hKf8Uk5MBZEmbC

After signing the transaction with the private key above, we obtain ECDSA signature 304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d (hex) which, appended with SIGHASH_ALL byte 01 (hex), is then embedded in it using the Pay-to-PubkeyHash scriptSig for regular addresses: <sig> <pubKey>.

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  6a
    47
      304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d
      01
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

In order to produce this signature, we had to sign the following modified transaction:

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  19
    76
    a9
    14
      3093fd17ee01616456cc3e8d792d8d03ec31e624
    88
    ac
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000

Basically we patched the raw transaction with the Pay-to-PubkeyHash scriptPubKey of the source UTXO: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG. We also appended the SIGHASH_ALL word 01000000 (hex).

Note that 3093fd17ee01616456cc3e8d792d8d03ec31e624 (hex) is the HASH160 of public key 02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972.

To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to RFC6979. Its value for this example is 11911142871849518033668783171853950819406055147191692459499720537819802969751 (dec).

2) Now, for the case where the UTXO is associated to a multisig address, we need to produce a different signed transaction:

We assume here a 1-of-2 multisig address.

The second key pair/address used is the following:

Kwc7zeCyVsemqAED2cpL138hKYRTcBQgaWYHLqAPARj3K2UwjPuK
0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
1DUDqhpJS7YHsQXuchWhPJUHr2DRnHYp6X

Therefore the derived multisig address is 35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X.

The associated raw transaction is the same. However, the signed transaction should have a different structure as we need to patch it with a Pay-to-Script-Hash scriptSig for multisig: 0 <sig1> OP_1 <pubKey1> <pubKey2> OP_2 OP_CHECKMULTISIG

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  91
    00
    47
      30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      01
    47
      51
      21
        02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
      21
        0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
      52
      ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

I am trying to obtain the ECDSA signature 30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx which must be computed using the first private key (its length here in x's is approximate).

I tried to produce such signature using the raw transaction patched with the Pay-to-Script-Hash scriptPubKey: OP_HASH160 <scriptHash> OP_EQUAL. However, the resulting signature 304402201264c3a19e805ff976241c20897a2c702a5fa9a3882524317ef1444b0bfebdf502207bc45af98867c9366368f2be2d3a7335bd2681c4ad58ad38224b982029fda8e5 (hex) seems not to be valid.

Below is the mentioned modified raw transaction. Note that 285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d (hex) is the script HASH160 associated to the multisig address 35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X:

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  17
    a9
    14
      285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d
    87
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
10000000

Again, to facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to RFC6979. Its value for this example is 52344238881233128299244703933491194256385056421257949759777810457555478930704 (dec).

TL;DR - How to patch the raw transaction of the example above in order to produce an ECDSA signature for the associated multisig UTXO? Can you also provide a sample signed transaction and the k used in the signature calculation? OR - Where can we find this signing procedure explained in detail, textually, for multisig addresses?

Improve this question

1 Answer 1

Reset to default
1

Ok, I found the answer after looking at some source code. For a multisig UTXO, the signature is computed using the redeem script and not the scriptPubKey from the Pay-to-Script-Hash.

I am not sure why this is not treated uniformly given that the scriptPubKey contains the HASH160 of the redeem script and the net effect of the signature seems would be equivalent.

(BTW, if you know where this information is documented, add the reference here; or let me know in the comments and I will do it.)

The signature for the example I provide is therefore 3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509 (hex).

And the signed transaction becomes:

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  92
    00
    48
      3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509
      01
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000

To calculate the signature we use the following modified transaction where we embed the redeem script for the multisig address: OP_1 <pubKey1> <pubKey2> OP_2 OP_CHECKMULTISIG

01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000

To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to RFC6979. Its value for this example is 9009507119619844958975765585826516989806701453903286856798625377439958995437 (dec).

Improve this answer
4
  • The demo is for a 1-of-2 multisig. When a "spending" transaction is used in a x-of-y combination, the unsigned raw tx must have several signatures in the v_in section. The spending tx would reveal the pubkeys, which have been in the redeem script. The OP_CHECKMULTISIG would need to iterate trough the many pubkeys, and see if they fit to the signatures. With a P2PKH there wouldn't be the contents of these many pubkeys. So if you would sign a tx with P2PKH, and then be able to release the funds with a different set of keys, signature was not valid for the defined spending condition.
    – pebwindkraft
    Commented Jan 8, 2018 at 8:26
  • @pebwindkraft thanks for sharing your insight, but I don't think that is the issue I am pointing out. If we kept the uniformity with the signing procedure of P2PKH, the spending transaction would still have a multisig scriptSig containing all the x signatures followed by the redeem script which has all the y public keys. What I mean is that, to compute these signatures, we could use the raw transaction furnished with the scriptPubKey of the UTXO, just like we did for P2PKH, instead of the redeem script. Why? 1) Because this would give the procedure an intuitive uniformity; and [...]
    – raugfer
    Commented Jan 9, 2018 at 12:37
  • [...] 2) I believe it would have the same net effect: to compute a cryptographic signature, first we hash the data to match the word size of the ECDSA. Therefore, the redeem script is hashed with double SHA256 to compute each one of the x signatures. But note, the scriptPubKey of the UTXO already has the HASH160 of the redeem script (that is how multisig addresses are generated). So, if we use the scriptPubKey of the UTXO instead, we would be applying the double SHA256 not to the redeem script, but to a script that contains its HASH160. Wouldn't that have the same net effect?
    – raugfer
    Commented Jan 9, 2018 at 12:45
  • 1
    You're correct that signing the p2sh scriptPubKey directly would achieve the same result wrt security, but by doing that we would lose the functionality of OP_CODESEPARATORs in the script. The script being signed is not really the input's scriptPubKey, rather it's called a scriptCode, and if the script does not contain CODESEPARATORs, then scriptCode is the same as the previous scriptPubKey. For p2sh, if we were signing the scriptPubKey, it would not be possible to manifest CODESEPARATOR's rules on the redeemScript (as all we'd be signing was the hash of the full script).
    – arubi
    Commented Dec 21, 2018 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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