4

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 David, 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.

4

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.

  • 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 Dec 13 '14 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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