<blockquote>
  <p>What is signed in the input scripts?</p>
</blockquote>

<p>Depends. </p>

<p>The case of a P2PKH spending transaction, the <code>scriptSig</code> (input script) for each input will contain a ECDSA signature and a byte which donates what exactly was signed called the <code>SIGHASH</code> flag. In almost all cases this is <code>SIGHASH_ALL</code>, which means that the signature covers the entirety of the transaction outputs and inputs, less other signatures. If the transaction output script is modified and any input has signed it with <code>SIGHASH_ALL</code>, that signature would be invalidated and the transaction can not be included in a block. </p>

<p>Other flags can have the effect you describe, if I make a transaction which only signs a single input with <code>SIGHASH_NONE</code> (this signature only covers the input), then anybody in the network is free to modify the outputs as much as they want before it gets buried in a block. Nobody uses it like that for exactly this reason.</p>

<p>There's two other flags available today <code>SIGHASH_SINGLE</code> and <code>SIGHASH_ANYONECANPAY</code>. The former allows you to sign only one of the outputs and ignores the rest (eg vin:1 signs only vout:1), however this is buggy and not at all intuitive. The latter allows you to make transactions where the inputs are a wildcard, spend this output to this script, and make up the deficit using whatever other inputs you want. </p>

<p>In general nobody uses <code>SIGHASH</code> flags, the majority of all transactions are strictly <code>SIGHASH_ALL</code>. </p>

<blockquote>
  <p>I am not very sure what the script of the inputs contain, but I guess it should contain the public key, and a signed message.</p>
</blockquote>

<p>This depends entirely on what type of output is being spent, but we'll assume it's a very typical Pay to Pubkey Hash (address) transaction. In this case the <code>scriptSig</code> is extremely simple. </p>

<pre><code>304402204bc6ed9b0122fc145031d4d9f6a30fbb28b63d152e3848c785a65f1e0b97ea8d02205a99bc13ba9293526ed175947cb756c5e3fca0a98890b88551e3e6c4c0bb6f5601
04988b34239b2f1c2441db4d50911b0550350414ce00b88f8dd39964f1a8631824db8e78b61d0ea6f3d9fcffcf2cd20be7d88a1583854682db4d136acd08542c3d
</code></pre>

<p>We have two data items, the first is an ECDSA signature in <a href="https://en.wikipedia.org/wiki/X.690#DER_encoding" rel="noreferrer">DER</a> format, and the public points of the P2PKH output we are spending. The last byte of the signature is the <code>SIGHASH</code> flag, which in this case is <code>0x01</code> or <code>SIGHASH_ALL</code>. </p>

<p>If you want to follow along with how these structures work, webbtc.com has a great script visualization tool which will allow you to see how these go together. In particular here is a reasonable <a href="http://webbtc.com/tx/a5353b4a844d05d74a3e5987eddb290d9de8a5fb50850f19abbb8d81a03495fd" rel="noreferrer">example transaction</a> with one input and output, and here is a <a href="http://webbtc.com/script/a5353b4a844d05d74a3e5987eddb290d9de8a5fb50850f19abbb8d81a03495fd:0" rel="noreferrer">play through the script execution</a> which does a good job of explaining how and why it is valid. </p>

CC BY-SA 3.0
2015-11-02T01:47:18.420Z
2015-11-02T02:15:43.643Z
2015-11-02T02:15:43.643Z
Claris
<p>I am learning the Bitcoin protocol by reading the bitcoin developer reference documentation.</p>

<p>As far as I know, a raw transaction consists of:</p>

<ul>
<li>Version (which is always 1)</li>
<li>Inputs. Each input contains:

<ul>
<li>Hash of the transaction that contains the output that we are going to spend here</li>
<li>Index of the output in that transaction</li>
<li>Script that satisfies the conditions placed in the script of the referenced ouput.</li>
</ul></li>
<li>Outputs. Each output contains:

<ul>
<li>8 bytes for the value in satoshis</li>
<li>Script with the conditions that must be satisfied in order for this output to be spent.</li>
</ul></li>
<li>Locktime (which is usually 0)</li>
</ul>

<p>I am not very sure what the script of the inputs contain, but I guess it should contain the public key, and a signed message.</p>

<p>My question is, why can't the miner modify the scripts in the outputs (replacing the address by their own), if those scripts are not part of the message that the real user had to sign?</p>

<p>Or maybe this question would be better asked like this: What is signed in the input scripts?</p>

<transactions><blockchain><security><signature>
Why can't bitcoin miners modify transaction outputs?
Nathan Parker
# Why can't bitcoin miners modify transaction outputs?

(Asked by: username_0 on 2015-11-02)

I am learning the Bitcoin protocol by reading the bitcoin developer reference documentation.

As far as I know, a raw transaction consists of:

* Version (which is always 1)
* Inputs. Each input contains:
  + Hash of the transaction that contains the output that we are going to spend here
  + Index of the output in that transaction
  + Script that satisfies the conditions placed in the script of the referenced ouput.
* Outputs. Each output contains:
  + 8 bytes for the value in satoshis
  + Script with the conditions that must be satisfied in order for this output to be spent.
* Locktime (which is usually 0)

I am not very sure what the script of the inputs contain, but I guess it should contain the public key, and a signed message.

My question is, why can't the miner modify the scripts in the outputs (replacing the address by their own), if those scripts are not part of the message that the real user had to sign?

Or maybe this question would be better asked like this: What is signed in the input scripts?

**Tags:** transactions, blockchain, security, signature


---

## 1 answers

### Answer by username_1 on 2015-11-02. Score: 9 | Accepted answer

> What is signed in the input scripts?

Depends.

The case of a P2PKH spending transaction, the `scriptSig` (input script) for each input will contain a ECDSA signature and a byte which donates what exactly was signed called the `SIGHASH` flag. In almost all cases this is `SIGHASH_ALL`, which means that the signature covers the entirety of the transaction outputs and inputs, less other signatures. If the transaction output script is modified and any input has signed it with `SIGHASH_ALL`, that signature would be invalidated and the transaction can not be included in a block.

Other flags can have the effect you describe, if I make a transaction which only signs a single input with `SIGHASH_NONE` (this signature only covers the input), then anybody in the network is free to modify the outputs as much as they want before it gets buried in a block. Nobody uses it like that for exactly this reason.

There's two other flags available today `SIGHASH_SINGLE` and `SIGHASH_ANYONECANPAY`. The former allows you to sign only one of the outputs and ignores the rest (eg vin:1 signs only vout:1), however this is buggy and not at all intuitive. The latter allows you to make transactions where the inputs are a wildcard, spend this output to this script, and make up the deficit using whatever other inputs you want.

In general nobody uses `SIGHASH` flags, the majority of all transactions are strictly `SIGHASH_ALL`.

> I am not very sure what the script of the inputs contain, but I guess it should contain the public key, and a signed message.

This depends entirely on what type of output is being spent, but we'll assume it's a very typical Pay to Pubkey Hash (address) transaction. In this case the `scriptSig` is extremely simple.

```
304402204bc6ed9b0122fc145031d4d9f6a30fbb28b63d152e3848c785a65f1e0b97ea8d02205a99bc13ba9293526ed175947cb756c5e3fca0a98890b88551e3e6c4c0bb6f5601
04988b34239b2f1c2441db4d50911b0550350414ce00b88f8dd39964f1a8631824db8e78b61d0ea6f3d9fcffcf2cd20be7d88a1583854682db4d136acd08542c3d

```

We have two data items, the first is an ECDSA signature in [DER](https://en.wikipedia.org/wiki/X.690#DER_encoding) format, and the public points of the P2PKH output we are spending. The last byte of the signature is the `SIGHASH` flag, which in this case is `0x01` or `SIGHASH_ALL`.

If you want to follow along with how these structures work, webbtc.com has a great script visualization tool which will allow you to see how these go together. In particular here is a reasonable [example transaction](http://webbtc.com/tx/a5353b4a844d05d74a3e5987eddb290d9de8a5fb50850f19abbb8d81a03495fd) with one input and output, and here is a [play through the script execution](http://webbtc.com/script/a5353b4a844d05d74a3e5987eddb290d9de8a5fb50850f19abbb8d81a03495fd:0) which does a good job of explaining how and why it is valid.


---

