<p>With multiple inputs, the inputs that are not being signed simply have blank scriptSigs. The preimage must be recomputed for each signature in each input as it will depend on both the input and the sighash flags that the signature specifies.</p>

CC BY-SA 4.0
2024-09-26T18:43:19.690Z
Thanks for the response. I have one more question, I have written it as an answer to my original question.
And thanks for your codes and contributions Ava! Your codes have been crucial for building my codes!
SalvaZ
CC BY-SA 4.0
2024-09-27T18:43:15.367Z
@SalvaZ No, you would not include the scriptPubKeys for the inputs not being signed. Those fields should be a single 0x00 byte.
Ava Chow
CC BY-SA 4.0
2024-09-25T18:52:43.200Z
2024-09-25T18:52:43.200Z
Ava Chow
<p>When verifying a transaction, the Bitcoin node rebuilds the hash-preimage of it from the transaction that has received.</p>
<p>With one-input transaction, it is easy to build the hash-preimage of it:</p>
<ol>
<li>Change the scriptSig to the scriptPubKey where the funds are being spent from.</li>
<li>Change the sigHash placement.</li>
</ol>
<p>The result of the steps above is double hashed, then is verified with the public key and the &quot;r&quot; and &quot;s&quot; value of the signature.</p>
<p>But with a two-inputs transaction, which is the complete process?
To verify each input, does the hash-preimage include the other input?</p>
<p>Thanks in advance, it would be helpful if an example is provided.</p>
<p>[Context]</p>
<p>I wrote the following code that verifies using ECDSA math a one-input and one-output transaction, both P2PKH: <a href="https://github.com/SalvaZaraes/bitcoin-digital-signatures-article/blob/main/verify-p2pkh-tx.py" rel="nofollow noreferrer">https://github.com/SalvaZaraes/bitcoin-digital-signatures-article/blob/main/verify-p2pkh-tx.py</a></p>
<p>Now I having problems with building the hash-preimage of a two-input transaction, that's the reason behind asking the upper questions.</p>
<hr />
<p>So, for example, a transaction like this one:
<a href="https://mempool.space/es/tx/592ea2010ec259252959b6047e227ceac6ffd0dbbe20bad71248960c18a5d890" rel="nofollow noreferrer">https://mempool.space/es/tx/592ea2010ec259252959b6047e227ceac6ffd0dbbe20bad71248960c18a5d890</a></p>
<p>That has two P2PKH inputs and one P2PKH output.</p>
<p>The corresponding Hash-preimage for the first input would be like this?:</p>
<p>010000000219f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4000000001976a914d52c9ce97c8dea0b71df687659a847a62c37732c88acffffffff22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca000000001976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88acffffffff01c047bfe54d0000001976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac0000000001000000</p>
<p>Breakdown:</p>
<p>01000000 - Version</p>
<p>02 - Number of Inputs</p>
<p>19f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4 - Previous Tx-id</p>
<p>00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (First input in this tx)</p>
<p>1976a914d52c9ce97c8dea0b71df687659a847a62c37732c88ac - First Input Locking Script (scriptPubKey)</p>
<p>ffffffff - Sequence</p>
<p>22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca - Previous Tx-id</p>
<p>00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (Second input in this tx)</p>
<p>1976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88ac - Second Input Locking Script (scriptPubKey)</p>
<p>ffffffff - Sequence</p>
<p>01 - Number of Outputs</p>
<p>c047bfe54d000000 - Amount of Satoshis being locked in the new scriptPubKey
1976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac - new scriptPubKey</p>
<p>00000000 - Locktime</p>
<p>01000000 - SigHash ALL</p>

<transactions><transaction-verification><transaction-input><input-script><sighash>
Which is the hash-preimage of a 2-input transaction?
SalvaZ
# Which is the hash-preimage of a 2-input transaction?

(Asked by: username_0 on 2024-09-25)

When verifying a transaction, the Bitcoin node rebuilds the hash-preimage of it from the transaction that has received.

With one-input transaction, it is easy to build the hash-preimage of it:

1. Change the scriptSig to the scriptPubKey where the funds are being spent from.
2. Change the sigHash placement.

The result of the steps above is double hashed, then is verified with the public key and the "r" and "s" value of the signature.

But with a two-inputs transaction, which is the complete process?
To verify each input, does the hash-preimage include the other input?

Thanks in advance, it would be helpful if an example is provided.

[Context]

I wrote the following code that verifies using ECDSA math a one-input and one-output transaction, both P2PKH: <https://github.com/SalvaZaraes/bitcoin-digital-signatures-article/blob/main/verify-p2pkh-tx.py>

Now I having problems with building the hash-preimage of a two-input transaction, that's the reason behind asking the upper questions.

---

So, for example, a transaction like this one:
<https://mempool.space/es/tx/592ea2010ec259252959b6047e227ceac6ffd0dbbe20bad71248960c18a5d890>

That has two P2PKH inputs and one P2PKH output.

The corresponding Hash-preimage for the first input would be like this?:

010000000219f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4000000001976a914d52c9ce97c8dea0b71df687659a847a62c37732c88acffffffff22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca000000001976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88acffffffff01c047bfe54d0000001976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac0000000001000000

Breakdown:

01000000 - Version

02 - Number of Inputs

19f4d40cb4204ad8429ec3d98d240661593edcfcfb8efcb3b684141ceb0df2e4 - Previous Tx-id

00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (First input in this tx)

1976a914d52c9ce97c8dea0b71df687659a847a62c37732c88ac - First Input Locking Script (scriptPubKey)

ffffffff - Sequence

22d07db06b68e4c15154db0ce0dd9c9dcd683a60a5117490451e0b52743492ca - Previous Tx-id

00000000 - Input to be spent, in this case the Input at position 0 of the previous tx (Second input in this tx)

1976a91497ccdcca4f494b1bd652ad8f9d816b4bbb1108ac88ac - Second Input Locking Script (scriptPubKey)

ffffffff - Sequence

01 - Number of Outputs

c047bfe54d000000 - Amount of Satoshis being locked in the new scriptPubKey
1976a91492512166101806dd6a695cbe56f883c3bea2a7e488ac - new scriptPubKey

00000000 - Locktime

01000000 - SigHash ALL

**Tags:** transactions, transaction-verification, transaction-input, input-script, sighash


---

## 1 answers

### Answer by username_1 on 2024-09-25. Score: 1

With multiple inputs, the inputs that are not being signed simply have blank scriptSigs. The preimage must be recomputed for each signature in each input as it will depend on both the input and the sighash flags that the signature specifies.

> **Comments:**
> **username_0**: Thanks for the response. I have one more question, I have written it as an answer to my original question. And thanks for your codes and contributions Ava! Your codes have been crucial for building my codes!  
> **username_1**: @username_0 No, you would not include the scriptPubKeys for the inputs not being signed. Those fields should be a single 0x00 byte.  

---

