4
1
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:


2I would note this is true for SIGHASH_ALL, but not the others. – Jimmy Song – 2016-06-06T19:25:24.250
1Thank 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 – 2016-06-06T22:13:47.667
@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 – 2016-06-06T22:16:48.573
2Yes, 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 – 2016-06-06T23:19:12.233
I other words: it is not just signing to prove ownership, but it proves agreement with the transaction. – Pieter Wuille – 2016-06-07T00:22:21.980
@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 – 2016-06-07T07:20:50.153
2Every 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 – 2016-06-07T08:07:18.657