<p>The sig part signs the entire transaction, not just the input part. So if someone intercepting the transaction replaced the transaction output part, the sig would no longer be valid. In fact, changing other inputs or outputs or amounts would also render the sig and thus the transaction invalid.</p>

<p>When you sign away an input, you are essentially saying "only this very specific transaction may spend this input". </p>

CC BY-SA 3.0
2015-01-29T15:07:10.773Z
Unless you sign with SIGHASH_NONE, but nobody does that, because of the attack Luke mentions.
Nick ODell
CC BY-SA 3.0
2015-01-29T13:59:54.470Z
2015-01-29T13:59:54.470Z
Jimmy Song
<p>Your assumption in the following equation </p>

<p><code>transaction = transaction input(UTXO+sig) + transaction output</code> is wrong. </p>

<p>Correct would be</p>

<p><code>transaction = UTXO + sig[tx data + hash(UTXO)] + output</code></p>

<ul>
<li><code>UTXO + sig[tx data + hash(UTXO)</code> is added for each input</li>
<li><code>output</code> is added for each output</li>
</ul>

<p>This is JSON format of transaction that I have recently created and <code>not yet broadcasted</code>. You may notice that it has 1 input and 1 output. </p>

<pre><code>{
    "hash": "7decf07997e58980b666e3cda17d4a930a21c8e99cad84c587a0e59d06b2dc86",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "size": 191,
    "in": [
        {
            "prev_out": {
                "hash": "5cbbbb09f4323badb86d32ef4b8929ce757c078bc399c2ec499daaf8f51c455e",
                "n": 1
            },
            "scriptSig": "304402203a0a2a31e906997d8beed8ca5a81bd303f9fff2475cb0400983eef0fb718a573022069103db03857fb8c7b204e3ed3706ea6fa729708bc85492a7783ca11760a672101 02856209e1b0dfd542898c8a8c58da4a91f9f6a82cddb4157117fe18157fc28c94",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00010000",
            "scriptPubKey": "OP_DUP OP_HASH160 c74eb0fc16d79cbf4399c80e7ec07162a41f30c6 OP_EQUALVERIFY OP_CHECKSIG"
        }
    ]
}
</code></pre>

<p>As you may know, to prove that you are allowed to spend input of tx you need to provide <code>Digital signature</code> - that is the <code>scriptSig</code> element inside <code>in</code> array. </p>

<p><code>scriptSig</code> are digitally signed following data:</p>

<ul>
<li>ID (hash) of particular input (prev_out) </li>
<li>double SHA of new transaction data</li>
</ul>

<p>Signing transaction data prevents anyone from executing so called <code>Man-in-the-middle attack</code> and intercept and direct <code>out</code> to their wallet, since they cannot provide correct digital signature for the malformed transaction.</p>

<p>Why not try yourself? Here is the hex of above tx:</p>

<pre><code>01000000015e451cf5f8aa9d49ecc299c38b077c75ce29894bef326db8ad3b32f409bbbb5c010000006a47304402203a0a2a31e906997d8beed8ca5a81bd303f9fff2475cb0400983eef0fb718a573022069103db03857fb8c7b204e3ed3706ea6fa729708bc85492a7783ca11760a6721012102856209e1b0dfd542898c8a8c58da4a91f9f6a82cddb4157117fe18157fc28c94ffffffff0110270000000000001976a914c74eb0fc16d79cbf4399c80e7ec07162a41f30c688ac00000000
</code></pre>

<p>You can replace output address <code>c74eb0fc16d79cbf4399c80e7ec07162a41f30c6</code> with double hash (RIPEDM160(SHA256(K)) of your public key. </p>

<p>Then try to broadcast the malformed tx with <a href="http://btc.blockr.io/tx/push" rel="noreferrer">http://btc.blockr.io/tx/push</a> to see it is impossible. Or if you are skilled you may use <code>sendrawtransaction &lt;tx hex here&gt;</code> command in <code>bitcoind</code>.</p>

CC BY-SA 3.0
2015-01-29T15:30:28.097Z
I see, so using:

UTXO + sig[tx data + hash(UTXO) is added for each input
output is added for each output

Say that I have two UTXO in an address. one has 3btc which we'll call UTXO_a, the other has 1btc (UTXO_b). so the total in the address is 4btc.

Now I want to send 4 btc to a friend's address (ignoring fees).

Would that come out as:

UTXO_a + sig[tx data + hash(UTXO_a)]
UTXO_b + sig[tx data + hash(UTXO_b)]
+ output(4btc to friend's address)

Where the tx data would be the same for both UTXO_a and UTXO_b? and only 1 output is required?

Thanks for clearing up the previous misconception :)
Luke
CC BY-SA 3.0
2015-01-29T15:38:11.523Z
@Luke - Yes, you are correct. Tx data for signing are the same for each scriptSig. Moreover, fee is calculated as a difference between sum(in) and sum(out) thus additional parameters are not required.
Marek
CC BY-SA 3.0
2017-11-26T12:02:23.637Z
Do I understand right, each input has a signature of the whole transaction, including outputs? Why not to use single signature as a separate fields for transaction instead of making a signature of whole transaction on each input?
Vedmant
CC BY-SA 3.0
2015-01-29T14:00:29.303Z
2015-01-29T14:52:19.430Z
2015-01-29T14:52:19.430Z
Marek
<p>When a P2PKH transaction is created there are two main parts: the transaction input and the transaction output. I understand that the transaction input requires a signature that unlocks a previous UTXO for that specific address.</p>

<p>So in simple terms we have </p>

<pre><code>transaction = transaction input(UTXO+sig) + transaction output(destination address and amount)
</code></pre>

<p>What prevents someone from intercepting the transaction and replacing the 'transaction output' with their own address?</p>

<transactions><security>
Intercept and edit transaction output
Luke
# Intercept and edit transaction output

(Asked by: username_0 on 2015-01-29)

When a P2PKH transaction is created there are two main parts: the transaction input and the transaction output. I understand that the transaction input requires a signature that unlocks a previous UTXO for that specific address.
So in simple terms we have 
transaction = transaction input(UTXO+sig) + transaction output(destination address and amount)

What prevents someone from intercepting the transaction and replacing the 'transaction output' with their own address?

**Tags:** transactions, security


---

## 2 answers

### Answer by username_3 on 2015-01-29. Score: 5 | Accepted answer

Your assumption in the following equation 
transaction = transaction input(UTXO+sig) + transaction output is wrong. 
Correct would be
transaction = UTXO + sig[tx data + hash(UTXO)] + output

UTXO + sig[tx data + hash(UTXO) is added for each input
output is added for each output

This is JSON format of transaction that I have recently created and not yet broadcasted. You may notice that it has 1 input and 1 output. 
{
    "hash": "7decf07997e58980b666e3cda17d4a930a21c8e99cad84c587a0e59d06b2dc86",
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 1,
    "lock_time": 0,
    "size": 191,
    "in": [
        {
            "prev_out": {
                "hash": "5cbbbb09f4323badb86d32ef4b8929ce757c078bc399c2ec499daaf8f51c455e",
                "n": 1
            },
            "scriptSig": "304402203a0a2a31e906997d8beed8ca5a81bd303f9fff2475cb0400983eef0fb718a573022069103db03857fb8c7b204e3ed3706ea6fa729708bc85492a7783ca11760a672101 02856209e1b0dfd542898c8a8c58da4a91f9f6a82cddb4157117fe18157fc28c94",
            "sequence": 4294967295
        }
    ],
    "out": [
        {
            "value": "0.00010000",
            "scriptPubKey": "OP_DUP OP_HASH160 c74eb0fc16d79cbf4399c80e7ec07162a41f30c6 OP_EQUALVERIFY OP_CHECKSIG"
        }
    ]
}

As you may know, to prove that you are allowed to spend input of tx you need to provide Digital signature - that is the scriptSig element inside in array. 
scriptSig are digitally signed following data:

ID (hash) of particular input (prev_out) 
double SHA of new transaction data

Signing transaction data prevents anyone from executing so called Man-in-the-middle attack and intercept and direct out to their wallet, since they cannot provide correct digital signature for the malformed transaction.
Why not try yourself? Here is the hex of above tx:
01000000015e451cf5f8aa9d49ecc299c38b077c75ce29894bef326db8ad3b32f409bbbb5c010000006a47304402203a0a2a31e906997d8beed8ca5a81bd303f9fff2475cb0400983eef0fb718a573022069103db03857fb8c7b204e3ed3706ea6fa729708bc85492a7783ca11760a6721012102856209e1b0dfd542898c8a8c58da4a91f9f6a82cddb4157117fe18157fc28c94ffffffff0110270000000000001976a914c74eb0fc16d79cbf4399c80e7ec07162a41f30c688ac00000000

You can replace output address c74eb0fc16d79cbf4399c80e7ec07162a41f30c6 with double hash (RIPEDM160(SHA256(K)) of your public key. 
Then try to broadcast the malformed tx with http://btc.blockr.io/tx/push to see it is impossible. Or if you are skilled you may use sendrawtransaction  command in bitcoind.

> **Comments:**
> **username_0**: I see, so using:  UTXO + sig[tx data + hash(UTXO) is added for each input output is added for each output  Say that I have two UTXO in an address. one has 3btc which we'll call UTXO_a, the other has 1btc (UTXO_b). so the total in the address is 4btc.  Now I want to send 4 btc to a friend's address (ignoring fees).  Would that come out as:  UTXO_a + sig[tx data + hash(UTXO_a)] UTXO_b + sig[tx data + hash(UTXO_b)] + output(4btc to friend's address)  Where the tx data would be the same for both UTXO_a and UTXO_b? and only 1 output is required?  Thanks for clearing up the previous misconception :)  
> **username_3**: @username_0 - Yes, you are correct. Tx data for signing are the same for each scriptSig. Moreover, fee is calculated as a difference between sum(in) and sum(out) thus additional parameters are not required.  
> **username_4**: Do I understand right, each input has a signature of the whole transaction, including outputs? Why not to use single signature as a separate fields for transaction instead of making a signature of whole transaction on each input?  

---

### Answer by username_1 on 2015-01-29. Score: 4

The sig part signs the entire transaction, not just the input part. So if someone intercepting the transaction replaced the transaction output part, the sig would no longer be valid. In fact, changing other inputs or outputs or amounts would also render the sig and thus the transaction invalid.

When you sign away an input, you are essentially saying "only this very specific transaction may spend this input".

> **Comments:**
> **username_2**: Unless you sign with SIGHASH_NONE, but nobody does that, because of the attack username_0 mentions.  

---

