<p>When it comes to transactions, I think that a <em>hex</em> representation can explain more unambigiously than words.<br/>
That's why my answer uses <em>hex</em> along every step of the signature.<br/></p>
<p>Given your P2PKH transaction with two inputs, here's the raw transaction that has to be signed with the private key corresponding to the <em>first</em> outpoint:<br/></p>
<pre><code>01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
19
76a914&lt;your-first-pkhash(160bit)&gt;88ac
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
00
ffffffff
02
a086010000000000
19
76a914&lt;hash-of-target-btc-pubkey1(160bit)&gt;88ac
50c3000000000000
19
76a914&lt;hash-of-target-btc-pubkey2(160bit)&gt;88ac
00000000
01000000
</code></pre>
<p>Here's the raw transaction that has to be signed with the private key corresponding to the <em>second</em> outpoint:<br/></p>
<pre><code>01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
00
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
19
76a914&lt;your-second-pkhash(160bit)&gt;88ac
ffffffff
02
a086010000000000
19
76a914&lt;hash-of-target-btc-pubkey1(160bit)&gt;88ac
50c3000000000000
19
76a914&lt;hash-of-target-btc-pubkey2(160bit)&gt;88ac
00000000
01000000
</code></pre>
<p>And here is the resulting signed transaction:<br/></p>
<pre><code>01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
6a
47
304&lt;...rest-of-signature&gt;
01
21
&lt;your-first-pk(264bit)&gt;
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
6a
47
304&lt;...rest-of-signature&gt;
01
21
&lt;your-second-pk(264bit)&gt;
ffffffff
02
a086010000000000
19
76a914&lt;hash-of-target-btc-pubkey1(160bit)&gt;88ac
50c3000000000000
19
76a914&lt;hash-of-target-btc-pubkey2(160bit)&gt;88ac
00000000
</code></pre>
<p>Assumptions: (1) You're using compressed public keys. (2) type is SIG_ALL<br/>
Note: Length of signatures can vary, and as a result the bytes that indicate script length can differ from the example above.<br/>
<br/>
Answering your 3rd question, there is a description <a href="https://en.bitcoin.it/wiki/Protocol_documentation#tx" rel="nofollow noreferrer">here</a></p>

CC BY-SA 4.0
2020-07-07T14:39:32.520Z
2020-07-14T09:27:00.137Z
2020-07-14T09:27:00.137Z
citizenfu
<blockquote>
  <p>When we have multiple inputs and multiple outputs and try to sign every input what do we fill in the output value section for each one of them: The total sum of the transaction inputs or the corresponding amount that every input that we sign has and we distribute between the outputs?</p>
</blockquote>

<p>For non-segwit inputs, the message that is hashed for you to sign is almost the entire transaction itself. You must have all of the outputs in the order that they will be in in the final transaction. You don't put one output or aggregate them - you put all of them as if it were the final transaction.</p>

<p>For segwit inputs, instead of putting all of the outputs in the message, you first hash them all together. They are serialized as if they were going to be in a transaction, then hashed all at once. The resulting SHA256 hash is what you use in the message. Read <a href="https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki" rel="nofollow noreferrer">BIP 143</a> for more information about that. The <code>value</code> field in that message is the value of just the output that is spent by that particular input.</p>

<blockquote>
  <p>In the section script in inputs, there is "Nothing", but what is the exact byte count of it - 1 byte, 4 bytes or something else?</p>
</blockquote>

<p>"Nothing" means that there is a script of length 0, so it means the single byte <code>00</code>. However, at no point in transaction signing are you ever signing an empty script. If you are, something is wrong.</p>

CC BY-SA 4.0
2019-06-11T10:01:54.013Z
So for example if I have 5 inputs, I need to sign each input individually placing the sigScript for the one that we sign and one byte 00 as you say for the others, and I repeat that step 5 times - for each input?
Dimitar Vasilev
CC BY-SA 4.0
2019-06-11T15:39:15.690Z
@DimitarVasilev Yes.
Ava Chow
CC BY-SA 4.0
2019-06-11T08:05:22.223Z
2019-06-11T08:05:22.223Z
Ava Chow
<p>I'm developing transaction constructor, but i faced several problems.  To some of which i found answer in <a href="https://bitcoin.stackexchange.com/questions/41209/how-to-sign-a-transaction-with-multiple-inputs/88281?noredirect=1#comment101253_88281">How to sign a transaction with multiple inputs?</a>, for the rest i'll try to explain:</p>

<ol>
<li>When we have multiple inputs and multiple outputs and try to sign every input what do we fill in the output value section for each one of them: The total sum of the transaction inputs or the corresponding amount that every input that we sign has and we distribute between the outputs?</li>
</ol>

<p><code>'version': 1,
'inputs': (2)
    {
    'output_tx_hash': 'aaaa',
    'output_position': 0,
    'script': the original script, like: '76a914' + hash + '88ac',
    'sequence': ffffffff,
    }, {
    'output_tx_hash': 'bbbb',
    'output_position': 1,
    'script': '', # Nothing
    'sequence': ffffffff,
    }
'outputs': (2)
    'value' : 100000
    'script' : '76a914' + hash of btc pub key + '88ac'
    'value' : 50000
    'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0</code></p>

<ol start="2">
<li>In the section script in inputs, there is "Nothing", but what is the exact byte count of it - 1 byte, 4 bytes or something else?</li>
<li>Is there a step-by-step guide or tutorial for manual transaction building and signing that covers multiple inputs and multiple outputs transaction. I successfully send transactions to the blockchain but only the ones with one input.</li>
</ol>

<transactions><signature><transaction-input><input-script>
How to manually sign a transaction with multiple inputs and multiple outputs?
Dimitar Vasilev
# How to manually sign a transaction with multiple inputs and multiple outputs?

(Asked by: username_0 on 2019-06-11)

I'm developing transaction constructor, but i faced several problems. To some of which i found answer in [How to sign a transaction with multiple inputs?](https://bitcoin.stackexchange.com/questions/41209/how-to-sign-a-transaction-with-multiple-inputs/88281?noredirect=1#comment101253_88281), for the rest i'll try to explain:

1. When we have multiple inputs and multiple outputs and try to sign every input what do we fill in the output value section for each one of them: The total sum of the transaction inputs or the corresponding amount that every input that we sign has and we distribute between the outputs?

`'version': 1,
'inputs': (2)
{
'output_tx_hash': 'aaaa',
'output_position': 0,
'script': the original script, like: '76a914' + hash + '88ac',
'sequence': ffffffff,
}, {
'output_tx_hash': 'bbbb',
'output_position': 1,
'script': '', # Nothing
'sequence': ffffffff,
}
'outputs': (2)
'value' : 100000
'script' : '76a914' + hash of btc pub key + '88ac'
'value' : 50000
'script' : '76a914' + hash of btc pub key + '88ac'
'locktime': 0`

2. In the section script in inputs, there is "Nothing", but what is the exact byte count of it - 1 byte, 4 bytes or something else?
3. Is there a step-by-step guide or tutorial for manual transaction building and signing that covers multiple inputs and multiple outputs transaction. I successfully send transactions to the blockchain but only the ones with one input.

**Tags:** transactions, signature, transaction-input, input-script


---

## 2 answers

### Answer by username_1 on 2020-07-07. Score: 1

When it comes to transactions, I think that a *hex* representation can explain more unambigiously than words.  
That's why my answer uses *hex* along every step of the signature.

Given your P2PKH transaction with two inputs, here's the raw transaction that has to be signed with the private key corresponding to the *first* outpoint:

```
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
19
76a914<your-first-pkhash(160bit)>88ac
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
00
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000

```

Here's the raw transaction that has to be signed with the private key corresponding to the *second* outpoint:

```
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
00
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
19
76a914<your-second-pkhash(160bit)>88ac
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000
01000000

```

And here is the resulting signed transaction:

```
01000000
02
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
00000000
6a
47
304<...rest-of-signature>
01
21
<your-first-pk(264bit)>
ffffffff
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
01000000
6a
47
304<...rest-of-signature>
01
21
<your-second-pk(264bit)>
ffffffff
02
a086010000000000
19
76a914<hash-of-target-btc-pubkey1(160bit)>88ac
50c3000000000000
19
76a914<hash-of-target-btc-pubkey2(160bit)>88ac
00000000

```

Assumptions: (1) You're using compressed public keys. (2) type is SIG\_ALL  
Note: Length of signatures can vary, and as a result the bytes that indicate script length can differ from the example above.  
  
Answering your 3rd question, there is a description [here](https://en.bitcoin.it/wiki/Protocol_documentation#tx)


---

### Answer by username_2 on 2019-06-11. Score: 0

> When we have multiple inputs and multiple outputs and try to sign every input what do we fill in the output value section for each one of them: The total sum of the transaction inputs or the corresponding amount that every input that we sign has and we distribute between the outputs?

For non-segwit inputs, the message that is hashed for you to sign is almost the entire transaction itself. You must have all of the outputs in the order that they will be in in the final transaction. You don't put one output or aggregate them - you put all of them as if it were the final transaction.

For segwit inputs, instead of putting all of the outputs in the message, you first hash them all together. They are serialized as if they were going to be in a transaction, then hashed all at once. The resulting SHA256 hash is what you use in the message. Read [BIP 143](https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki) for more information about that. The `value` field in that message is the value of just the output that is spent by that particular input.

> In the section script in inputs, there is "Nothing", but what is the exact byte count of it - 1 byte, 4 bytes or something else?

"Nothing" means that there is a script of length 0, so it means the single byte `00`. However, at no point in transaction signing are you ever signing an empty script. If you are, something is wrong.

> **Comments:**
> **username_0**: So for example if I have 5 inputs, I need to sign each input individually placing the sigScript for the one that we sign and one byte 00 as you say for the others, and I repeat that step 5 times - for each input?  
> **username_2**: @username_0 Yes.  

---

