user41491: 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?

user41491: 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).

41491: <p>I am trying to figure out how to produce a valid signed transaction to
consume BTC from a multisig address.</p>
<p><strong>1) First let's look into producing a signature for an UTXO associated to a regular address:</strong></p>
<p>Assume we are creating a transaction to consume a single UTXO,
output 0 of transaction <code>1111111111111111111111111111111111111111111111111111111111111111</code> (hex),
depositing 1 BTC to address <code>147Us9aEq2PvBC5wobBJw1yEpQEbPKzssA</code>, for which the HASH160 is <code>2222222222222222222222222222222222222222</code> (hex).</p>
<p>This would be the raw transaction before signing, formatted for readability:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  00
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>Assume the UTXO is associated to the following key pair and regular address:</p>
<pre><code>L2hYQuKeAUr4hLAdDspnwm4YCcFb222REdW34WsmonEeJP5Wp4qt
02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
15Rrie5X6VgDRVwMvB63hKf8Uk5MBZEmbC
</code></pre>
<p>After signing the transaction with the private key above, we obtain ECDSA
signature <code>304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d</code> (hex) which, appended with SIGHASH_ALL byte <code>01</code> (hex), is then embedded in it using the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash" rel="nofollow noreferrer">Pay-to-PubkeyHash</a> scriptSig for regular addresses: &lt;sig&gt; &lt;pubKey&gt;.</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  6a
    47
      304402205c2ce1a04b7eb882cf39bfff278b59b9c90ae8c98ce3911bd63b0909bd524df3022000dd5393fa0526ed2d30eff4102c8592c0502406adb0e5a925cd299f8eeb770d
      01
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
</code></pre>
<p>In order to produce this signature, we had to sign the following modified transaction:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  19
    76
    a9
    14
      3093fd17ee01616456cc3e8d792d8d03ec31e624
    88
    ac
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000
</code></pre>
<p>Basically we patched the raw transaction with the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash" rel="nofollow noreferrer">Pay-to-PubkeyHash</a> scriptPubKey of the source UTXO: OP_DUP OP_HASH160 &lt;pubKeyHash&gt; OP_EQUALVERIFY OP_CHECKSIG. We also appended the <code>SIGHASH_ALL</code> word <code>01000000</code> (hex).</p>
<p>Note that <code>3093fd17ee01616456cc3e8d792d8d03ec31e624</code> (hex) is the HASH160 of public key <code>02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972</code>.</p>
<p>To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>.
Its value for this example is <code>11911142871849518033668783171853950819406055147191692459499720537819802969751</code> (dec).</p>
<p><strong>2) Now, for the case where the UTXO is associated to a multisig address, we need to produce a different signed transaction:</strong></p>
<p>We assume here a 1-of-2 multisig address.</p>
<p>The second key pair/address used is the following:</p>
<pre><code>Kwc7zeCyVsemqAED2cpL138hKYRTcBQgaWYHLqAPARj3K2UwjPuK
0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
1DUDqhpJS7YHsQXuchWhPJUHr2DRnHYp6X
</code></pre>
<p>Therefore the derived multisig address is <code>35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X</code>.</p>
<p>The associated raw transaction is the same. However, the signed transaction should have a different structure as we need to patch it with a <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a> scriptSig for multisig: 0 &lt;sig1&gt; OP_1 &lt;pubKey1&gt; &lt;pubKey2&gt; OP_2 OP_CHECKMULTISIG</p>
<pre><code>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
</code></pre>
<p>I am trying to obtain the ECDSA signature <code>30xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx</code> which must be computed using the first private key (its length here in <code>x</code>'s is approximate).</p>
<p>I tried to produce such signature using the raw transaction patched with the <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a> scriptPubKey: OP_HASH160 &lt;scriptHash&gt; OP_EQUAL. However, the resulting signature <code>304402201264c3a19e805ff976241c20897a2c702a5fa9a3882524317ef1444b0bfebdf502207bc45af98867c9366368f2be2d3a7335bd2681c4ad58ad38224b982029fda8e5</code> (hex) seems not to be valid.</p>
<p>Below is the mentioned modified raw transaction. Note that <code>285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d</code> (hex) is the script HASH160 associated to the multisig address <code>35NBKdnf3F9XSGqfUsNxBMWGspm4y7Yi8X</code>:</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  17
    a9
    14
      285071ecf3cce5e8eeb80aa289c3b7ba611cdd6d
    87
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
10000000
</code></pre>
<p>Again, to facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>. Its value for this example is <code>52344238881233128299244703933491194256385056421257949759777810457555478930704</code> (dec).</p>
<p><strong>TL;DR -</strong> 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? <strong>OR -</strong> Where can we find this signing procedure explained in detail, textually, for multisig addresses?</p>
 41491: <p>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 <a href="https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash" rel="nofollow noreferrer">Pay-to-Script-Hash</a>.</p>
<p>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.</p>
<p>(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.)</p>
<p>The signature for the example I provide is therefore <code>3045022100e66ce17919dd9d98dfe3e4052fa0d56f783c9a685624e062e28f5b10507f845402200cc2f377173f6c26a0c2457b8ff089f36be6c7187bbce7f7566ae31001f29509</code> (hex).</p>
<p>And the signed transaction becomes:</p>
<pre><code>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
</code></pre>
<p>To calculate the signature we use the following modified transaction where we embed the redeem script for the multisig address: OP_1 &lt;pubKey1&gt; &lt;pubKey2&gt; OP_2 OP_CHECKMULTISIG</p>
<pre><code>01000000
01
  1111111111111111111111111111111111111111111111111111111111111111
  00000000
  47
    51
    21
      02d619bbd8166614b3c6cdb2833392a71793a1f531693e3a18e7ac3ccbdd161972
    21
      0340f2f93487edb2ea49ffbdfc7de20481e54dae44420135fc6c6ea8262477fc9b
    52
    ae
  ffffffff
01
  00e1f50500000000
  19
    76
    a9
    14
      2222222222222222222222222222222222222222
    88
    ac
00000000
01000000
</code></pre>
<p>To facilitate the replay calculation of the signature, the k used in the signing procedure was obtained deterministically according to <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a>. Its value for this example is <code>9009507119619844958975765585826516989806701453903286856798625377439958995437</code> (dec).</p>
