<p>This boils down to how to treat invalid signatures provided in a PSBT. I believe there is some room for implementation-defined behaviour with regard to the finalizer role. For instance if it can get around the invalid signatures by satisfying another spending path.</p>
<p>However the <a href="https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#transaction-extractor" rel="nofollow noreferrer">specification for the extractor role</a> is pretty clear:</p>
<blockquote>
<p>The Extractor should produce a fully valid, network serialized transaction if all inputs are complete.</p>
</blockquote>
<p>Since the input finalizer and transaction extractor roles are often combined, and since explicit is better than implicit, i believe it would make sense to explicitly raise an error on an invalid signature. But nothing prescribes it in the specification itself.</p>

CC BY-SA 4.0
2023-11-17T15:33:40.640Z
Spec is not clear. But the case you made makes sense. Thanks.
solar
CC BY-SA 4.0
2023-11-17T14:16:38.777Z
2023-11-17T14:16:38.777Z
Antoine Poinsot
<p>Should PSBT finalizers/extractors and deserialization functions enforce the rule that a taproot schnorr signature should only append a SIGHASH_* unless it is SIGHASH_DEFAULT (0), or is it left to the implementer's discretion?</p>
<p>Ref: <a href="https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-21" rel="nofollow noreferrer">https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-21</a></p>

CC BY-SA 4.0
2023-11-17T12:56:36.763Z
Are you asking whether the finalizer should append a sighash byte for SIGHASH_DEFAULT signatures? Well, no, since it would make it invalid?
Antoine Poinsot
CC BY-SA 4.0
2023-11-17T13:14:17.273Z
No, i am asking this - should a finalizer check the signature (PSBT_IN_TAP_KEY_SIG/PSBT_IN_TAP_SCRIPT_SIG) and remove SIGHASH_DEFAULT and if it exist and then use the 64 byte signature? Or throw error?
solar
CC BY-SA 4.0
2023-11-17T13:27:19.300Z
Currently, bitcoinjs-lib finalizer blindly adds the 65 byte signature to the witness even if the sighash is SIGHASH_DEFAULT.
solar
CC BY-SA 4.0
2023-11-17T14:10:16.757Z
I believe the extractor role should check the validity of the transaction it produces, therefore it should explicitly error. Let me post a proper answer.
Antoine Poinsot
<taproot><bip174-psbt><p2tr>
Enforcing PSBT Signature Rules: Finalizer/Extractor and Deserialization Implementation
solar
# Enforcing PSBT Signature Rules: Finalizer/Extractor and Deserialization Implementation

(Asked by: username_0 on 2023-11-17)

Should PSBT finalizers/extractors and deserialization functions enforce the rule that a taproot schnorr signature should only append a SIGHASH\_\* unless it is SIGHASH\_DEFAULT (0), or is it left to the implementer's discretion?

Ref: <https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-21>

**Tags:** taproot, bip174-psbt, p2tr

> **Comments:**
> **username_1**: Are you asking whether the finalizer should append a sighash byte for SIGHASH_DEFAULT signatures? Well, no, since it would make it invalid?  
> **username_0**: No, i am asking this - should a finalizer check the signature (PSBT_IN_TAP_KEY_SIG/PSBT_IN_TAP_SCRIPT_SIG) and remove SIGHASH_DEFAULT and if it exist and then use the 64 byte signature? Or throw error?  
> **username_0**: Currently, bitcoinjs-lib finalizer blindly adds the 65 byte signature to the witness even if the sighash is SIGHASH_DEFAULT.  
> **username_1**: I believe the extractor role should check the validity of the transaction it produces, therefore it should explicitly error. Let me post a proper answer.  

---

## 1 answers

### Answer by username_1 on 2023-11-17. Score: 1

This boils down to how to treat invalid signatures provided in a PSBT. I believe there is some room for implementation-defined behaviour with regard to the finalizer role. For instance if it can get around the invalid signatures by satisfying another spending path.

However the [specification for the extractor role](https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki#transaction-extractor) is pretty clear:

> The Extractor should produce a fully valid, network serialized transaction if all inputs are complete.

Since the input finalizer and transaction extractor roles are often combined, and since explicit is better than implicit, i believe it would make sense to explicitly raise an error on an invalid signature. But nothing prescribes it in the specification itself.

> **Comments:**
> **username_0**: Spec is not clear. But the case you made makes sense. Thanks.  

---

