<p>Figuring out how to handle SIGHASH_SINGLE inputs in PSBTv2 was one of the major problems when designing it. Unfortunately, when this was brought up on the mailing list, there was little to no response, and so the result was that I had to try to come up with a solution myself, which may be slightly deficient.</p>
<blockquote>
<p>For example, the code that parses PSBTv2 may find that 'Has SIGHASH_SINGLE flag' is false in <code>PSBT_GLOBAL_TX_MODIFIABLE</code>, but later, when processing the input fields, finds out that one of psbt inputs has <code>SIGHASH_SINGLE</code>.</p>
</blockquote>
<p>The expectation is that such an inconsistency would not occur because it is in the Sginer's best interest to make sure that the Has SIGHASH_SINGLE flag is set when they add a SIGHASH_SINGLE signature. There is no need for anyone to be checking that no other signatures are SIGHASH_SINGLE, and so the expected action is that the inconsistency is ignored. This could result in an invalid transaction, but that is an allowed outcome.</p>
<blockquote>
<p>Likewise, if the flag is true, but there are no inputs having <code>SIGHASH_SINGLE</code> sighash types, should this be taken as an indication of inconsistent PSBT ?</p>
</blockquote>
<p>Yes, but setting when there are no SIGHASH_SINGLE signatures does not necessarily cause harm other than making adding additional inputs slower.</p>
<blockquote>
<p>Can we say &quot;this flag is always equal to <code>any(input.has_sighash_single() for input in psbt.inputs)</code>&quot; (1) ?</p>
</blockquote>
<p>That is the intention.</p>
<blockquote>
<p><code>PSBT_IN_SIGHASH_TYPE</code> is not required to be present, and if it is absent, signer &quot;may use any sighash type they wish&quot;. But let's imagine that BIP text would state that <code>PSBT_IN_SIGHASH_TYPE</code> must always be present if <code>SIGHASH_SINGLE</code> is to be used. Will (1) be true in this case ? Would we even need this flag then ?</p>
</blockquote>
<p>There is no real need for the flag other than as an optimization. It exists in order to allow Constructors to skip having to inspect every input, but if the flag did not exist, it could simply have been that Constructors must check every input for SIGHASH_SINGLE signatures. So if PSBT_IN_SIGHASH_TYPE were provided for every input, Has SIGHASH_SINGLE would still be a used.</p>
<blockquote>
<p>Should say that 'Has SIGHASH_SINGLE' flag is to be ignored if there are finalized inputs  because any adding of inputs must have been done before finalization ?</p>
</blockquote>
<p>No, it is possible that an input is finalized while additional inputs are being added. The use of SIGHASH_SINGLE &amp; SIGHASH_ANYONECANPAY allows for this.</p>
<blockquote>
<p>How would it be possible to check the finalized inputs for the use of <code>SIGHASH_SINGLE</code> signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?</p>
</blockquote>
<p>A script interpreter would be needed. The process would be to execute the finalized scriptSigs and scriptWitnesses with a signature verifier that can report whether it had to verify any SIGHASH_SINGLE inputs. Part of the reason that Has SIGHASH_SINGLE was added was because I thought it was unreasonable that Constructors had to have a script interpreter just to make sure that they weren't breaking any SIGHASH_SINGLE things.</p>
<blockquote>
<p><strong>*</strong> By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?</p>
</blockquote>
<p>Proprietary fields are generally lumped together with unknown fields because they are unknown to implementations that do not implement those specific proprietary fields. But yes, the text could be clarified.</p>

CC BY-SA 4.0
2021-12-17T19:32:23.760Z
So if the Constructor that adds inputs does not have a script interpreter, and 'Has SIGHASH_SINGLE' is true, it should treat any finalized input that it cannot analyze, as having a SIGHASH_SINGLE signature.
Dmitry Petukhov
CC BY-SA 4.0
2021-12-17T20:17:57.140Z
@DmitryPetukhov Yes, that would be a reasonable thing to do (assuming it is not SIGHASH_ALL, but if it were, then the tx should not be modifiable).
Ava Chow
CC BY-SA 4.0
2021-12-17T17:41:13.073Z
2021-12-17T17:41:13.073Z
Ava Chow
<p>BIP370 specifies a bit flag (bit 2) in <code>PSBT_GLOBAL_TX_MODIFIABLE</code> field, that &quot;indicates whether the transaction has a SIGHASH_SINGLE signature who's input and output pairing must be preserved&quot; and &quot;If the Has SIGHASH_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH_SINGLE. The same number of inputs and outputs must be added before those inputs and their corresponding outputs&quot;</p>
<p>BIP370 does not specify how to handle this flag in other situations, when the inconsistency of the flag with other fields can indicate some problem and it may be best to somehow react to this problem rather than ignore it.</p>
<p>For example, the code that parses PSBTv2 may find that 'Has SIGHASH_SINGLE flag' is false in <code>PSBT_GLOBAL_TX_MODIFIABLE</code>, but later, when processing the input fields, finds out that one of psbt inputs has <code>SIGHASH_SINGLE</code>.</p>
<p>How the code should react to this ? This is obvious inconsistency, if this situation is ignored, and the 'Has SIGHASH_SINGLE flag' is considered false despite the presence of <code>SIGHASH_SIGNGLE</code> in the inputs, the signatures can be invalidated when moving inputs or outputs.</p>
<p>Likewise, if the flag is true, but there are no inputs having <code>SIGHASH_SINGLE</code> sighash types, should this be taken as an indication of inconsistent PSBT ?</p>
<p>Can we say &quot;this flag is always equal to <code>any(input.has_sighash_single() for input in psbt.inputs)</code>&quot; (1) ?</p>
<p><code>PSBT_IN_SIGHASH_TYPE</code> is not required to be present, and if it is absent, signer &quot;may use any sighash type they wish&quot;. But let's imagine that BIP text would state that <code>PSBT_IN_SIGHASH_TYPE</code> must always be present if <code>SIGHASH_SINGLE</code> is to be used. Will (1) be true in this case ? Would we even need this flag then ?</p>
<p>Should say that 'Has SIGHASH_SINGLE' flag is to be ignored if there are finalized inputs  because any adding of inputs must have been done before finalization ?</p>
<p>How would it be possible to check the finalized inputs for the use of <code>SIGHASH_SINGLE</code> signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?</p>
<p>BIP174 says that on finalization, finalized <code>scriptSig</code> and <code>scriptWitness</code> should remain, and &quot;All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT&quot;<strong>*</strong>. If <code>PSBT_IN_SIGHASH_TYPE</code> is cleared, there's no way to know in general if the witness has signatures with <code>SIGHASH_SINGLE</code>, unless the code can somehow understand the format of the witness.</p>
<p><strong>*</strong> By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?</p>

CC BY-SA 4.0
2021-12-16T18:19:15.953Z
By the way, the 'Constructor' section in BIP370 talks about looking for 'inputs that have signatures', and at the same time talks about checking timelocks and SIGHASH_SINGLE on the inputs. This seems to be a reference to BIP371 that defines special fields for signatures. But this is a forward reference that cannot be understood without reading BIP371 first, and such checks cannot be done on finalized inputs (because all those fields would be already removed on finalization)
Dmitry Petukhov
CC BY-SA 4.0
2021-12-17T20:02:28.700Z
I forgot that there's `PSBT_IN_PARTIAL_SIG` that has signatures that Constructor can look at.
Dmitry Petukhov
<development><bip174-psbt>
Handling 'Has SIGHASH_SINGLE' flag for psbt2 (BIP370)
Dmitry Petukhov
# Handling 'Has SIGHASH_SINGLE' flag for psbt2 (BIP370)

(Asked by: username_0 on 2021-12-16)

BIP370 specifies a bit flag (bit 2) in `PSBT_GLOBAL_TX_MODIFIABLE` field, that "indicates whether the transaction has a SIGHASH\_SINGLE signature who's input and output pairing must be preserved" and "If the Has SIGHASH\_SINGLE flag is True, then the Constructor must iterate through the inputs and find the inputs which have signatures that use SIGHASH\_SINGLE. The same number of inputs and outputs must be added before those inputs and their corresponding outputs"

BIP370 does not specify how to handle this flag in other situations, when the inconsistency of the flag with other fields can indicate some problem and it may be best to somehow react to this problem rather than ignore it.

For example, the code that parses PSBTv2 may find that 'Has SIGHASH\_SINGLE flag' is false in `PSBT_GLOBAL_TX_MODIFIABLE`, but later, when processing the input fields, finds out that one of psbt inputs has `SIGHASH_SINGLE`.

How the code should react to this ? This is obvious inconsistency, if this situation is ignored, and the 'Has SIGHASH\_SINGLE flag' is considered false despite the presence of `SIGHASH_SIGNGLE` in the inputs, the signatures can be invalidated when moving inputs or outputs.

Likewise, if the flag is true, but there are no inputs having `SIGHASH_SINGLE` sighash types, should this be taken as an indication of inconsistent PSBT ?

Can we say "this flag is always equal to `any(input.has_sighash_single() for input in psbt.inputs)`" (1) ?

`PSBT_IN_SIGHASH_TYPE` is not required to be present, and if it is absent, signer "may use any sighash type they wish". But let's imagine that BIP text would state that `PSBT_IN_SIGHASH_TYPE` must always be present if `SIGHASH_SINGLE` is to be used. Will (1) be true in this case ? Would we even need this flag then ?

Should say that 'Has SIGHASH\_SINGLE' flag is to be ignored if there are finalized inputs because any adding of inputs must have been done before finalization ?

How would it be possible to check the finalized inputs for the use of `SIGHASH_SINGLE` signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?

BIP174 says that on finalization, finalized `scriptSig` and `scriptWitness` should remain, and "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT"**\***. If `PSBT_IN_SIGHASH_TYPE` is cleared, there's no way to know in general if the witness has signatures with `SIGHASH_SINGLE`, unless the code can somehow understand the format of the witness.

**\*** By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?

**Tags:** development, bip174-psbt

> **Comments:**
> **username_0**: By the way, the 'Constructor' section in BIP370 talks about looking for 'inputs that have signatures', and at the same time talks about checking timelocks and SIGHASH_SINGLE on the inputs. This seems to be a reference to BIP371 that defines special fields for signatures. But this is a forward reference that cannot be understood without reading BIP371 first, and such checks cannot be done on finalized inputs (because all those fields would be already removed on finalization)  
> **username_0**: I forgot that there's `PSBT_IN_PARTIAL_SIG` that has signatures that Constructor can look at.  

---

## 1 answers

### Answer by username_1 on 2021-12-17. Score: 2 | Accepted answer

Figuring out how to handle SIGHASH\_SINGLE inputs in PSBTv2 was one of the major problems when designing it. Unfortunately, when this was brought up on the mailing list, there was little to no response, and so the result was that I had to try to come up with a solution myself, which may be slightly deficient.

> For example, the code that parses PSBTv2 may find that 'Has SIGHASH\_SINGLE flag' is false in `PSBT_GLOBAL_TX_MODIFIABLE`, but later, when processing the input fields, finds out that one of psbt inputs has `SIGHASH_SINGLE`.

The expectation is that such an inconsistency would not occur because it is in the Sginer's best interest to make sure that the Has SIGHASH\_SINGLE flag is set when they add a SIGHASH\_SINGLE signature. There is no need for anyone to be checking that no other signatures are SIGHASH\_SINGLE, and so the expected action is that the inconsistency is ignored. This could result in an invalid transaction, but that is an allowed outcome.

> Likewise, if the flag is true, but there are no inputs having `SIGHASH_SINGLE` sighash types, should this be taken as an indication of inconsistent PSBT ?

Yes, but setting when there are no SIGHASH\_SINGLE signatures does not necessarily cause harm other than making adding additional inputs slower.

> Can we say "this flag is always equal to `any(input.has_sighash_single() for input in psbt.inputs)`" (1) ?

That is the intention.

> `PSBT_IN_SIGHASH_TYPE` is not required to be present, and if it is absent, signer "may use any sighash type they wish". But let's imagine that BIP text would state that `PSBT_IN_SIGHASH_TYPE` must always be present if `SIGHASH_SINGLE` is to be used. Will (1) be true in this case ? Would we even need this flag then ?

There is no real need for the flag other than as an optimization. It exists in order to allow Constructors to skip having to inspect every input, but if the flag did not exist, it could simply have been that Constructors must check every input for SIGHASH\_SINGLE signatures. So if PSBT\_IN\_SIGHASH\_TYPE were provided for every input, Has SIGHASH\_SINGLE would still be a used.

> Should say that 'Has SIGHASH\_SINGLE' flag is to be ignored if there are finalized inputs because any adding of inputs must have been done before finalization ?

No, it is possible that an input is finalized while additional inputs are being added. The use of SIGHASH\_SINGLE & SIGHASH\_ANYONECANPAY allows for this.

> How would it be possible to check the finalized inputs for the use of `SIGHASH_SINGLE` signatures in case of finalized inputs when custom scripts are used with unknown format for the witness data ?

A script interpreter would be needed. The process would be to execute the finalized scriptSigs and scriptWitnesses with a signature verifier that can report whether it had to verify any SIGHASH\_SINGLE inputs. Part of the reason that Has SIGHASH\_SINGLE was added was because I thought it was unreasonable that Constructors had to have a script interpreter just to make sure that they weren't breaking any SIGHASH\_SINGLE things.

> **\*** By the way, this wording should include not only unknown fields, but proprietary fields, too should be preserved. Should I make PR to add this ?

Proprietary fields are generally lumped together with unknown fields because they are unknown to implementations that do not implement those specific proprietary fields. But yes, the text could be clarified.

> **Comments:**
> **username_0**: So if the Constructor that adds inputs does not have a script interpreter, and 'Has SIGHASH_SINGLE' is true, it should treat any finalized input that it cannot analyze, as having a SIGHASH_SINGLE signature.  
> **username_1**: @username_0 Yes, that would be a reasonable thing to do (assuming it is not SIGHASH_ALL, but if it were, then the tx should not be modifiable).  

---

