<p>I'd been wondering about this for quite a long time, since it was the reason behind the quadratic hashing problem. The best answer I found so far <a href="https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257" rel="nofollow noreferrer">is the one given</a> by Pieter Wuille in the Bitcoin talk forum. The answers is most likely not going to be satisfying though.</p>

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

CC BY-SA 3.0
2018-04-13T09:23:15.773Z
2018-04-13T09:23:15.773Z
sr_gi
<p>Varying the signature per input helps prevents some attacks during multi-party transaction construction.</p>

<p>Consider a coinjoin involving Alice and Bob.  Alice selects one of her UTXOs for the coinjoin.  Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected.  Alice does not notice that Bob selected one of her UTXOs and continues with the coinjoin protocol, signing her input.  Now Bob copies her signature, which would be valid for the UTXO of Alice's that he selected if SIGHASH_ALL were constant for all inputs.  Now Bob has procured Alice's funds for himself. </p>

<p>Technically this can be prevented if Alice checks all other inputs to the coinjoin to make sure that they are not controlled by herself, but that is a huge pain, error prone, surprising, and likely means a secure signing module needs to be aware of all UTXOs that use the same public key.</p>

CC BY-SA 4.0
2019-03-28T06:49:04.027Z
"a huge pain, error prone, surprising, and likely means a secure signing module needs to be aware of all UTXOs" because of a race with unconfirmed transactions, I argue this is actually not even possible! :)  One could require the other party to provide all the input transactions but that would be inefficient and all your error prone comments would still apply.
G. Maxwell
CC BY-SA 4.0
2019-03-27T14:19:31.220Z
2019-03-27T15:26:27.203Z
2019-03-27T15:26:27.203Z
Russell O'Connor
<p>In pre-BIP143 signature hashes, I know that the signature hash differs because you have to substitute the previous scriptPubKey for each input and thus the serialization changes.</p>

<p>The question is why? If the HASH_TYPE is SIGHASH_ALL, why does the signature hash need to change for each input? Why not sign the same "blanked" transaction or the same transaction with the scriptPubKeys?</p>

CC BY-SA 3.0
2018-04-13T09:16:43.860Z
Related to https://bitcoin.stackexchange.com/questions/54548/scriptsig-content-during-signature-quadratic-hashing and https://bitcoin.stackexchange.com/questions/63489/why-is-scriptsig-filled-with-scriptpubkey-before-signing-a-transaction
sr_gi
CC BY-SA 4.0
2019-03-27T13:15:10.437Z
From my understanding, after reading through the `p2sh-p2wpkh` test vector in bip143, you need to include the 'outpoint'. This suggests that there will also be more than one hash for a multi-input transaction. Is there a way of creating one hash that can be signed in bip143 using `SIGHASH_ALL`?
Malone
<transactions><signature><sighash><quadratic-hashing>
Why is the signature hash different for each input in a multi-input transaction?
Jimmy Song
# Why is the signature hash different for each input in a multi-input transaction?

(Asked by: username_0 on 2018-04-13)

In pre-BIP143 signature hashes, I know that the signature hash differs because you have to substitute the previous scriptPubKey for each input and thus the serialization changes.

The question is why? If the HASH\_TYPE is SIGHASH\_ALL, why does the signature hash need to change for each input? Why not sign the same "blanked" transaction or the same transaction with the scriptPubKeys?

**Tags:** transactions, signature, sighash, quadratic-hashing

> **Comments:**
> **username_1**: Related to https://bitcoin.stackexchange.com/questions/54548/scriptsig-content-during-signature-quadratic-hashing and https://bitcoin.stackexchange.com/questions/63489/why-is-scriptsig-filled-with-scriptpubkey-before-signing-a-transaction  
> **username_2**: From my understanding, after reading through the `p2sh-p2wpkh` test vector in bip143, you need to include the 'outpoint'. This suggests that there will also be more than one hash for a multi-input transaction. Is there a way of creating one hash that can be signed in bip143 using `SIGHASH_ALL`?  

---

## 2 answers

### Answer by username_3 on 2019-03-27. Score: 9 | Accepted answer

Varying the signature per input helps prevents some attacks during multi-party transaction construction.

Consider a coinjoin involving Alice and Bob. Alice selects one of her UTXOs for the coinjoin. Bob chooses a UTXO for his input, but he actually selects ones of Alice's other UTXOs that reuse the same address as the one she selected. Alice does not notice that Bob selected one of her UTXOs and continues with the coinjoin protocol, signing her input. Now Bob copies her signature, which would be valid for the UTXO of Alice's that he selected if SIGHASH\_ALL were constant for all inputs. Now Bob has procured Alice's funds for himself.

Technically this can be prevented if Alice checks all other inputs to the coinjoin to make sure that they are not controlled by herself, but that is a huge pain, error prone, surprising, and likely means a secure signing module needs to be aware of all UTXOs that use the same public key.

> **Comments:**
> **username_4**: "a huge pain, error prone, surprising, and likely means a secure signing module needs to be aware of all UTXOs" because of a race with unconfirmed transactions, I argue this is actually not even possible! :)  One could require the other party to provide all the input transactions but that would be inefficient and all your error prone comments would still apply.  

---

### Answer by username_1 on 2018-04-13. Score: 2

I'd been wondering about this for quite a long time, since it was the reason behind the quadratic hashing problem. The best answer I found so far [is the one given](https://bitcointalk.org/index.php?topic=102487.msg1123257#msg1123257) by Pieter Wuille in the Bitcoin talk forum. The answers is most likely not going to be satisfying though.

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


---

