<p>The entire transaction (except for the signatures) must be signed with the appropriate key for each transaction output it claims. Tampering with any of the outputs with invalidate all the signatures.</p>

CC BY-SA 3.0
2014-12-13T00:03:34.007Z
What about just adding an OP_CODESEPARATOR right to the beginning of an output? Nothing would really change but the transaction hash, the value being signed would be the exact same.
morsecoder
CC BY-SA 3.0
2013-06-20T06:47:54.720Z
2013-06-20T06:47:54.720Z
David Schwartz
<p>Using the terminology from: <a href="https://en.bitcoin.it/wiki/Protocol_specification#tx" rel="nofollow">https://en.bitcoin.it/wiki/Protocol_specification#tx</a></p>

<p>What prevents an attacker operating a rogue client from replacing the tx_out[] of a transaction with values that assign the output of the transaction to the attacker?</p>

<p>The tx_in[] is unchanged (and presumably valid), but the outputs now benefit the attacker.</p>

<p>A new hash can then be calculated and announced by the rogue client using the inv message.</p>

<p>If nothing prevents this occurring, how does the Bitcoin network prevent this rogue transaction from being included in a block?</p>

<hr>

<p>[Not having anyway to comment at this point]</p>

<p>Thanks David, that clarified greatly my [mis]understanding of the documentation at:</p>

<p><a href="https://en.bitcoin.it/wiki/Script#Crypto" rel="nofollow">https://en.bitcoin.it/wiki/Script#Crypto</a></p>

<p>The OP_CHECKSIG description says in part:</p>

<blockquote>
  <p>The entire transaction's outputs, inputs, and script (from the most
  recently-executed OP_CODESEPARATOR to the end) are hashed.</p>
</blockquote>

<p>I'd thought "the entire transaction" was the preceding transaction, not the redeeming transaction, that was signed as you describe.</p>

<p>Thank you again for helping me out.</p>

<transactions><fraud>
How is a Transaction protected from tampering before inclusion in a Block?
John Mossen
# How is a Transaction protected from tampering before inclusion in a Block?

(Asked by: username_0 on 2013-06-20)

Using the terminology from: <https://en.bitcoin.it/wiki/Protocol_specification#tx>

What prevents an attacker operating a rogue client from replacing the tx\_out[] of a transaction with values that assign the output of the transaction to the attacker?

The tx\_in[] is unchanged (and presumably valid), but the outputs now benefit the attacker.

A new hash can then be calculated and announced by the rogue client using the inv message.

If nothing prevents this occurring, how does the Bitcoin network prevent this rogue transaction from being included in a block?

---

[Not having anyway to comment at this point]

Thanks username_1, that clarified greatly my [mis]understanding of the documentation at:

<https://en.bitcoin.it/wiki/Script#Crypto>

The OP\_CHECKSIG description says in part:

> The entire transaction's outputs, inputs, and script (from the most
> recently-executed OP\_CODESEPARATOR to the end) are hashed.

I'd thought "the entire transaction" was the preceding transaction, not the redeeming transaction, that was signed as you describe.

Thank you again for helping me out.

**Tags:** transactions, fraud


---

## 1 answers

### Answer by username_1 on 2013-06-20. Score: 4 | Accepted answer

The entire transaction (except for the signatures) must be signed with the appropriate key for each transaction output it claims. Tampering with any of the outputs with invalidate all the signatures.

> **Comments:**
> **username_2**: What about just adding an OP_CODESEPARATOR right to the beginning of an output? Nothing would really change but the transaction hash, the value being signed would be the exact same.  

---

