<p>Well, based on <a href="https://medium.com/@bitaps.com/exploring-bitcoin-signature-hash-types-15427766f0a9" rel="nofollow noreferrer">this article</a>, the principle I already described is followed with some additions (only those additions are written below):</p>
<p><strong>(if you want to check for yourself, please note that the preimage on the web page is presented in reverse - at the beginning is the mark of the signature type , while at the end is the transaction version)</strong></p>
<ol>
<li><p>NONE (0x02)</p>
<ul>
<li>value of <code>sequence</code> field of inputs that are not the input for which we are making signature is set to <code>0x00000000</code></li>
<li>value of <code>tx_out count</code> field is set to <code>0x00</code></li>
</ul>
</li>
<li><p>SIGNLE (0x03)</p>
<ul>
<li>value of <code>sequence</code> field of inputs that are not the input for which we are making signature is set to <code>0x00000000</code></li>
<li>the value of the <code>tx_out count</code> field depends on the input/output index (<strong>index_s</strong>) we are signing; for example, if the <strong>index_s</strong> = 2, we put the value for count field tx_out_count = <strong>index_s</strong> + 1, which is 3 in this case</li>
<li>outputs to <strong>index_s</strong>  (let's say <strong>index_s</strong> = 2), so outputs 0 and 1, will have the <code>value</code> field set to <code>0xffffffffffffffff</code>, and the <code>script length</code> field to <code>0x00</code>, while the <code>script</code> will not exist at all</li>
<li><strong>index_s</strong> output we are signing in &quot;standard way&quot; (we just take its entire content)</li>
<li>outputs after <strong>index_s</strong> we don't take into account</li>
</ul>
</li>
<li><p>ALL|ANYONECANPAY (0x81)</p>
<ul>
<li>we only take into account the input we are signing and we do it in a standard way; other inputs are not taken into account at all (this is different from outputs)</li>
<li>all outputs are signed in the manner described for SIGNHASH_ALL (0x01)</li>
</ul>
</li>
<li><p>NONE|ANYONECANPAY (0x82)</p>
<ul>
<li>for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies</li>
</ul>
</li>
<li><p>SINGLE|ANYONECANPAY (0x83)</p>
<ul>
<li>for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies</li>
<li>for output, absolutely the same story that I described above for 0x03</li>
</ul>
</li>
</ol>
<p>The strange is that when only one output is signing, then the outputs up to it (up to its index) are taken into account (value at <code>0xffffffffffffffff</code> and script length at <code>0x00</code>), while this does not apply to inputs. What confuses me is that on the website, for 0x81, 0x82 and 0x83 it says that the input with index 0 is signed, although actually in the example the input with index 1 is signed. Therefore, I do not know if the inputs up to the one that is signed are also taken into account (as in the case of output), because maybe the writer thought that he is really signing the input with index 0, not 1. So there are no inputs up to it, since it is the first in sequence. Another possibility is that he really wanted to sign the input with index 1 (so the inputs up to it are not really taken into account), but writer did not put a good title of the given section.</p>
<p><strong>Does anyone have any more information, or maybe can confirm this?</strong></p>

CC BY-SA 4.0
2023-07-28T09:58:05.673Z
2023-07-28T09:58:05.673Z
dassd
<p>I have a few questions regarding the transaction hash preimage when signing with different values of the SIGHASH flag in the case of the <strong>P2PKH</strong> script.</p>
<p>I know what the transaction hash preimage looks like in case of SIGHASH_ALL, but what does it look like for other values of this flag.</p>
<p>So let's say our transaction has 3 inputs and 4 outputs and we can denote it as T(I1, I2, I3; O1, O2, O3, O4), the preimage in the case of SIGHASH_ALL will be as follows.</p>
<p>Let's start with the input. We take all inputs as they are (its full content). After that, we clear the scriptSig field of all inputs and set the length of the scriptSig field in all inputs to zero (0x00). Then, just for the input we're signing, we  set its scriptSig field to the scriptPubKey from the output (UTXO) that this input points to. Also, we will set the length of the scriptSig field in this input to the length of this newly added script scriptPubKey. The length of the scriptSig field in other inputs remains zero (0x00), and the scriptSig field remains empty. When it comes to the outputs, we copy their complete contents and add them to the previously described slightly modified contents of the inputs. Finally, we additionally append 0x01000000, which indicates that it is a SIGHASH_ALL type of signature.</p>
<p>This is how it works in the case of SIGHASH_ALL, but how does it work for other values of this flag.</p>
<p>My assumption is that it is exactly the same process, <strong>the only question is which inputs and outputs are taken into account</strong>. Therefore, the transaction hash preimages for the different values of the SIGHASH flag are as follows (I took into account the values defined in the Master Bitcoin book):</p>
<ol>
<li><p>NONE (0x02) - Signature applies to all inputs, none of the outputs</p>
<ul>
<li>for inputs, absolutely the same story that I described for SIGHASH_ALL applies</li>
<li>outputs are not taken into account (they are not part of the transaction hash preimage, similar as scriptSig field of other inputs is also not a part)</li>
<li>append 0x02000000 to the end</li>
</ul>
</li>
<li><p>SIGNLE (0x03) - Signature applies to all inputs but only the one output with the same index number as the signed input</p>
<ul>
<li>for inputs, absolutely the same story that I described for SIGHASH_ALL applies</li>
<li>only the content of the output whose index corresponds to the input index is taken into account (eg if we want to sign I2, we will take inputs I1, I2 and I3, but only output O2)</li>
<li>append 0x02000000 to the end</li>
</ul>
</li>
<li><p>ALL|ANYONECANPAY (0x81) - Signature applies to one input and all outputs</p>
<ul>
<li>only the input that we sign is included in the transaction hash preimage, the other inputs, i.e. their content, are not part of the transaction hash preimage in any form (we just ignore the other inputs, a similar scenario that we would have if the transaction had only one input and the SIGHASH_ALL)</li>
<li>for outputs, absolutely the same story that I described for SIGHASH_ALL applies (we take the entire content of all outputs)</li>
<li>append 0x81000000 to the end</li>
</ul>
</li>
<li><p>NONE|ANYONECANPAY (0x82) - Signature applies to one input, none of the outputs</p>
<ul>
<li>for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies</li>
<li>outputs are not taken into account (they are not part of the transaction hash preimage)</li>
<li>append 0x82000000 to the end</li>
</ul>
</li>
<li><p>SINGLE|ANYONECANPAY (0x83) - Signature applies to one input and the output with the same index number</p>
<ul>
<li>for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies</li>
<li>for outputs, absolutely the same story that I described for 0x03 (SIGNLE) applies</li>
<li>append 0x83000000 to the end</li>
</ul>
</li>
</ol>
<p>So my questions are:</p>
<p><strong>1. Is this how it works?</strong></p>
<p><strong>2. Are there any other values for the SIGHASH flag that I should cover?</strong></p>
<p><strong>3. Is there some related work/paper/standard that explains this (perhaps for other scripts, like P2WPKH etc.)?</strong></p>

CC BY-SA 4.0
2023-07-27T13:53:57.673Z
Not a full answer, but for P2WPKH/P2WSH this is described in BIP143 (the entire document is about just the sighash construction). For P2TR key path spends this is described in BIP341 (see "Common signature message", plus "Taproot key path spending signature validation"). For P2TR tapscript spends this is described in BIP342 (reusing BIP341's "Common signature message", plus its own "Signature validation").
Pieter Wuille
CC BY-SA 4.0
2023-07-27T13:58:59.043Z
@PieterWuille Thanks for the reply Pieter. I will look at the standards you wrote. Do you perhaps know the answers to the other questions (especially the first). I would say that is the logic to follow.
dassd
CC BY-SA 4.0
2023-07-27T14:02:26.757Z
I don't have the time to go over that in detail now. There are several answers on this site on the topic of sighash computation, though I'm not sure if any cover sighash flags other than ALL.
Pieter Wuille
CC BY-SA 4.0
2023-07-27T17:23:28.320Z
Check out https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash
Murch
<transactions><signature><sighash-flags>
What is the transaction hash preimage for different values of SIGHASH (not SIGHASH_ALL) in P2PKH?
dassd
# What is the transaction hash preimage for different values of SIGHASH (not SIGHASH_ALL) in P2PKH?

(Asked by: username_0 on 2023-07-27)

I have a few questions regarding the transaction hash preimage when signing with different values of the SIGHASH flag in the case of the **P2PKH** script.

I know what the transaction hash preimage looks like in case of SIGHASH\_ALL, but what does it look like for other values of this flag.

So let's say our transaction has 3 inputs and 4 outputs and we can denote it as T(I1, I2, I3; O1, O2, O3, O4), the preimage in the case of SIGHASH\_ALL will be as follows.

Let's start with the input. We take all inputs as they are (its full content). After that, we clear the scriptSig field of all inputs and set the length of the scriptSig field in all inputs to zero (0x00). Then, just for the input we're signing, we set its scriptSig field to the scriptPubKey from the output (UTXO) that this input points to. Also, we will set the length of the scriptSig field in this input to the length of this newly added script scriptPubKey. The length of the scriptSig field in other inputs remains zero (0x00), and the scriptSig field remains empty. When it comes to the outputs, we copy their complete contents and add them to the previously described slightly modified contents of the inputs. Finally, we additionally append 0x01000000, which indicates that it is a SIGHASH\_ALL type of signature.

This is how it works in the case of SIGHASH\_ALL, but how does it work for other values of this flag.

My assumption is that it is exactly the same process, **the only question is which inputs and outputs are taken into account**. Therefore, the transaction hash preimages for the different values of the SIGHASH flag are as follows (I took into account the values defined in the Master Bitcoin book):

1. NONE (0x02) - Signature applies to all inputs, none of the outputs

   * for inputs, absolutely the same story that I described for SIGHASH\_ALL applies
   * outputs are not taken into account (they are not part of the transaction hash preimage, similar as scriptSig field of other inputs is also not a part)
   * append 0x02000000 to the end
2. SIGNLE (0x03) - Signature applies to all inputs but only the one output with the same index number as the signed input

   * for inputs, absolutely the same story that I described for SIGHASH\_ALL applies
   * only the content of the output whose index corresponds to the input index is taken into account (eg if we want to sign I2, we will take inputs I1, I2 and I3, but only output O2)
   * append 0x02000000 to the end
3. ALL|ANYONECANPAY (0x81) - Signature applies to one input and all outputs

   * only the input that we sign is included in the transaction hash preimage, the other inputs, i.e. their content, are not part of the transaction hash preimage in any form (we just ignore the other inputs, a similar scenario that we would have if the transaction had only one input and the SIGHASH\_ALL)
   * for outputs, absolutely the same story that I described for SIGHASH\_ALL applies (we take the entire content of all outputs)
   * append 0x81000000 to the end
4. NONE|ANYONECANPAY (0x82) - Signature applies to one input, none of the outputs

   * for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies
   * outputs are not taken into account (they are not part of the transaction hash preimage)
   * append 0x82000000 to the end
5. SINGLE|ANYONECANPAY (0x83) - Signature applies to one input and the output with the same index number

   * for inputs, absolutely the same story that I described for 0x81 (ALL|ANYONECANPAY) applies
   * for outputs, absolutely the same story that I described for 0x03 (SIGNLE) applies
   * append 0x83000000 to the end

So my questions are:

**1. Is this how it works?**

**2. Are there any other values for the SIGHASH flag that I should cover?**

**3. Is there some related work/paper/standard that explains this (perhaps for other scripts, like P2WPKH etc.)?**

**Tags:** transactions, signature, sighash-flags

> **Comments:**
> **username_1**: Not a full answer, but for P2WPKH/P2WSH this is described in BIP143 (the entire document is about just the sighash construction). For P2TR key path spends this is described in BIP341 (see "Common signature message", plus "Taproot key path spending signature validation"). For P2TR tapscript spends this is described in BIP342 (reusing BIP341's "Common signature message", plus its own "Signature validation").  
> **username_0**: @username_1 Thanks for the reply username_1. I will look at the standards you wrote. Do you perhaps know the answers to the other questions (especially the first). I would say that is the logic to follow.  
> **username_1**: I don't have the time to go over that in detail now. There are several answers on this site on the topic of sighash computation, though I'm not sure if any cover sighash flags other than ALL.  
> **username_2**: Check out https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash  

---

## 1 answers

### Answer by username_0 on 2023-07-28. Score: 1

Well, based on [this article](https://medium.com/@bitaps.com/exploring-bitcoin-signature-hash-types-15427766f0a9), the principle I already described is followed with some additions (only those additions are written below):

**(if you want to check for yourself, please note that the preimage on the web page is presented in reverse - at the beginning is the mark of the signature type , while at the end is the transaction version)**

1. NONE (0x02)

   * value of `sequence` field of inputs that are not the input for which we are making signature is set to `0x00000000`
   * value of `tx_out count` field is set to `0x00`
2. SIGNLE (0x03)

   * value of `sequence` field of inputs that are not the input for which we are making signature is set to `0x00000000`
   * the value of the `tx_out count` field depends on the input/output index (**index\_s**) we are signing; for example, if the **index\_s** = 2, we put the value for count field tx\_out\_count = **index\_s** + 1, which is 3 in this case
   * outputs to **index\_s** (let's say **index\_s** = 2), so outputs 0 and 1, will have the `value` field set to `0xffffffffffffffff`, and the `script length` field to `0x00`, while the `script` will not exist at all
   * **index\_s** output we are signing in "standard way" (we just take its entire content)
   * outputs after **index\_s** we don't take into account
3. ALL|ANYONECANPAY (0x81)

   * we only take into account the input we are signing and we do it in a standard way; other inputs are not taken into account at all (this is different from outputs)
   * all outputs are signed in the manner described for SIGNHASH\_ALL (0x01)
4. NONE|ANYONECANPAY (0x82)

   * for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies
5. SINGLE|ANYONECANPAY (0x83)

   * for inputs, absolutely the same story that I described above for 0x81 (ALL|ANYONECANPAY) applies
   * for output, absolutely the same story that I described above for 0x03

The strange is that when only one output is signing, then the outputs up to it (up to its index) are taken into account (value at `0xffffffffffffffff` and script length at `0x00`), while this does not apply to inputs. What confuses me is that on the website, for 0x81, 0x82 and 0x83 it says that the input with index 0 is signed, although actually in the example the input with index 1 is signed. Therefore, I do not know if the inputs up to the one that is signed are also taken into account (as in the case of output), because maybe the writer thought that he is really signing the input with index 0, not 1. So there are no inputs up to it, since it is the first in sequence. Another possibility is that he really wanted to sign the input with index 1 (so the inputs up to it are not really taken into account), but writer did not put a good title of the given section.

**Does anyone have any more information, or maybe can confirm this?**


---

