Chip-2026-06: op_sighash

[bitcoincashautist]

This is a low hanging fruit which we can get nearly for free and it will be generally useful.
It has already seen some good discussion, and I think we can go ahead with it for May '27.

Summary

This proposal adds OP_SIGHASH, an opcode that computes the transaction’s signature hash (sighash) and pushes it to the stack without verifying a signature.
It completes the “checksig unbundling”: OP_CHECKSIG is functionally OP_SIGHASH followed by OP_CHECKDATASIG verifying a signature over that digest.

The opcode pops a sighash-type byte from the stack and pushes the resulting 32-byte sighash digest.
It uses the identical sighash algorithm, type flags, and scriptCode conventions as OP_CHECKSIG, so it produces byte-for-byte the same digest that a checksig verify would compare against.

No new cryptography, sighash algorithms, or flag semantics are introduced.
The opcode exposes work the VM already does internally.

---

ac-0353f40e / sighash · GitLab

[cculianu]

Except internally the sighash that is computed is the one used for the txn to sign.

This would have it so that you may have to potentially rehash – depending on the type requested.

I would cost this appropriately – consider it always to take worst-case hashing cost even if the “cached” value ended up being returned.

[jimtendo]

I would cost this appropriately – consider it always to take worst-case hashing cost even if the “cached” value ended up being returned.

Agree.

From a BCHN implementation point of view, do you think this’ll be difficult @cculianu ? In my head, I imagine it’s probably mostly a matter of spitting OP_CHECKSIG, but I haven’t actually looked at the BCHN code yet. Happy to draft a PR if you’d be willing to take a look once done?

EDIT:

Glancing at the code, I’m thinking it might not necessarily be a matter of “splitting” OP_CHECKSIG as such, but just adding the OP_SIGHASH case and invoking the SignatureHash function here: src/script/interpreter.cpp · master · Bitcoin Cash Node / Bitcoin Cash Node · GitLab ?

OP_CHECKSIG itself wraps the signature validation under checker functions

[MathieuG]

Thanks for writing this up as a CHIP!!

Script-Implemented Authentication Schemes

Several projects implement alternative signature schemes directly in Script: Quantumroot (post-quantum vaults), Lamport signatures, and secp256r1 verification. All of them must construct a sighash manually using transaction introspection opcodes. This is a big part of the cost: ~600 bytes of Script just to produce the 32-byte digest.

Sahid Miller, who implemented secp256k1 and secp256r1 verifiers in Script:

In my custom secp256k1 and p256 signature verification scripts, I use ~600 bytes to create a sighash to verify against. OP_SIGHASH would make that unnecessary.

A manual sighash implementation using loops (post-May 2026) can be compressed to ~153 bytes. OP_SIGHASH does the same work in 2 bytes (sighash byte + opcode), using the identical, audited sighash recipes that node implementations already maintain.

Standardized Sighash for Novel Signers

Every Script-based signer that constructs its own sighash must reimplement the sighash algorithm, including edge cases around SIGHASH_SINGLE , ANYONECANPAY , FORKID , UTXOS , and the scriptCode substitution rules. Errors in these reimplementations are consensus-compatible (the script simply fails to verify, or some unintetinoal malleability gap is left) but still represent wasted funds and debugging effort.

OP_SIGHASH gives every Script-based signer the same canonical sighash: the one computed by the node’s own C++ codebase, which has been battle-tested for over a decade. Implementations become simpler, auditable, and audited once.

this to me really is the most important part, these two related points make the lives of the builders and the tinkerers much easier. We want to lower the barrier to entry for people to explore novel cryptography in script. It’s a very nice way to offload unneeded complexity to the VM instead of the the contract implementation