<p>The signature also signs the Pubkey Script and Amount (which together would represent what you reference as &quot;output of <code>Tx</code>&quot;).</p>
<p>Quoting the <a href="https://bitcoin.org/en/developer-guide#transactions" rel="nofollow noreferrer">Transaction section of the Developer's guide</a>:</p>
<blockquote>
<p>Bob’s secp256k1 signature doesn’t just prove Bob controls his private
key; it also makes the non-signature-script parts of his transaction
tamper-proof so Bob can safely broadcast them over the peer-to-peer
network.</p>
</blockquote>
<p><a href="https://i.sstatic.net/iLlQ2.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/iLlQ2.png" alt="enter image description here" /></a><br />
<sub>Image Source: <a href="https://bitcoin.org/en/developer-guide#transactions" rel="nofollow noreferrer">Developer Guide: Transactions</a></sub></p>
<blockquote>
<p>As illustrated in the figure above, the data Bob signs includes the
txid and output index of the previous transaction, the previous
output’s pubkey script, the pubkey script Bob creates which will let
the next recipient spend this transaction’s output, and the amount of
satoshis to spend to the next recipient. In essence, the entire
transaction is signed except for any signature scripts, which hold the
full public keys and secp256k1 signatures.</p>
</blockquote>

CC BY-SA 3.0
2016-06-06T19:25:24.250Z
I would note this is true for SIGHASH_ALL, but not the others.
Jimmy Song
CC BY-SA 3.0
2016-06-06T22:13:47.667Z
Thank you very much; but I am not sure I fully understand. Indeed, I saw this picture before but I am not sure what its message is. Would someone be so kind as to explain it once more plz?
hartmut
CC BY-SA 3.0
2016-06-06T22:16:48.573Z
@Murch Considering the picture I originally posted, do you mean that each of the scriptSig in Tx not only certifies the ownership of TxE's outputs, but also confirms Tx' s output?
hartmut
CC BY-SA 3.0
2016-06-06T23:19:12.233Z
Yes, typically every input contains signatures that cover both the outputs of the previous transaction being spent, AND the outputs where the transaction containing the signatures sends them to.
Pieter Wuille
CC BY-SA 3.0
2016-06-07T00:22:21.980Z
I  other words: it is not just signing to prove ownership, but it proves agreement with the transaction.
Pieter Wuille
CC BY-SA 3.0
2016-06-07T07:20:50.153Z
@Pieter Wuille. Thanks for this explanation. Apologies for being a nit-picky but: which signature covers what? Or is it that a same signature covers outputs and inputs?
hartmut
CC BY-SA 3.0
2016-06-07T08:07:18.657Z
Every signature covers both inputs and outputs. The diagram and the linked Developer Guide explain that in much more detail than I can put in a comment.
Pieter Wuille
CC BY-SA 4.0
2021-11-10T20:06:55.707Z
The figure does not make sense because it suggests that the signed data covers everything from left to right including the private key. Furthermore the link needs to be updated.
phinz
CC BY-SA 3.0
2016-06-06T19:09:07.360Z
2016-06-07T08:55:29.003Z
2020-06-16T11:10:03.350Z
Murch
<p>In a transaction <code>Tx</code>, the hash pointer of the earlier transaction (say <code>TxE</code>) that serves as input to <code>Tx</code> must be signed by the sender <code>S</code> of <code>Tx</code>. This is to show that <code>S</code> was the recipient of <code>TxE</code>.
It remains to show that <code>S</code> agrees with the output of <code>Tx</code>. At which stage does <code>S</code> sign the output of <code>Tx</code>? 
I assume (s)he does so. Else, what would prevent an attacker from looking at <code>Tx</code> just after <code>S</code> broadcasted it, and modify the output (so that he is the recipient) before rebroadcast? </p>

<p>In other words:
<strong>The scriptSig proves the sender owns the input of Tx. What proves that the sender approves the output of the Tx?</strong></p>

<p>rgds</p>

<p>P.S: the transaction I am considering atm is: </p>

<p><a href="https://i.sstatic.net/pp80y.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/pp80y.png" alt="enter image description here"></a></p>

<transactions><bitcoind><signature>
How is a transaction's output signed?
hartmut
# How is a transaction's output signed?

(Asked by: username_0 on 2016-06-06)

In a transaction `Tx`, the hash pointer of the earlier transaction (say `TxE`) that serves as input to `Tx` must be signed by the sender `S` of `Tx`. This is to show that `S` was the recipient of `TxE`.
It remains to show that `S` agrees with the output of `Tx`. At which stage does `S` sign the output of `Tx`?
I assume (s)he does so. Else, what would prevent an attacker from looking at `Tx` just after `S` broadcasted it, and modify the output (so that he is the recipient) before rebroadcast?

In other words:
**The scriptSig proves the sender owns the input of Tx. What proves that the sender approves the output of the Tx?**

rgds

P.S: the transaction I am considering atm is:

[![enter image description here](https://i.sstatic.net/pp80y.png)](https://i.sstatic.net/pp80y.png)

**Tags:** transactions, bitcoind, signature


---

## 1 answers

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

The signature also signs the Pubkey Script and Amount (which together would represent what you reference as "output of `Tx`").

Quoting the [Transaction section of the Developer's guide](https://bitcoin.org/en/developer-guide#transactions):

> Bob’s secp256k1 signature doesn’t just prove Bob controls his private
> key; it also makes the non-signature-script parts of his transaction
> tamper-proof so Bob can safely broadcast them over the peer-to-peer
> network.

[![enter image description here](https://i.sstatic.net/iLlQ2.png)](https://i.sstatic.net/iLlQ2.png)  
Image Source: [Developer Guide: Transactions](https://bitcoin.org/en/developer-guide#transactions)

> As illustrated in the figure above, the data Bob signs includes the
> txid and output index of the previous transaction, the previous
> output’s pubkey script, the pubkey script Bob creates which will let
> the next recipient spend this transaction’s output, and the amount of
> satoshis to spend to the next recipient. In essence, the entire
> transaction is signed except for any signature scripts, which hold the
> full public keys and secp256k1 signatures.

> **Comments:**
> **username_2**: I would note this is true for SIGHASH_ALL, but not the others.  
> **username_0**: Thank you very much; but I am not sure I fully understand. Indeed, I saw this picture before but I am not sure what its message is. Would someone be so kind as to explain it once more plz?  
> **username_0**: @username_1 Considering the picture I originally posted, do you mean that each of the scriptSig in Tx not only certifies the ownership of TxE's outputs, but also confirms Tx' s output?  
> **username_3**: Yes, typically every input contains signatures that cover both the outputs of the previous transaction being spent, AND the outputs where the transaction containing the signatures sends them to.  
> **username_3**: I  other words: it is not just signing to prove ownership, but it proves agreement with the transaction.  
> **username_0**: @username_3. Thanks for this explanation. Apologies for being a nit-picky but: which signature covers what? Or is it that a same signature covers outputs and inputs?  
> **username_3**: Every signature covers both inputs and outputs. The diagram and the linked Developer Guide explain that in much more detail than I can put in a comment.  
> **username_4**: The figure does not make sense because it suggests that the signed data covers everything from left to right including the private key. Furthermore the link needs to be updated.  

---

