BIP 17 OP_CHECKHASHVERIFY explained as a closed P2SH alternative, including script hashing, activation risk and why Bitcoin adopted BIP 16.
This guide explains BIP 17 OP_CHECKHASHVERIFY (CHV) in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 17 OP_CHECKHASHVERIFY (CHV): A receiver could choose a complex spending condition while the sender paid a fixed 20-byte hash. The full policy would be supplied on spending, reducing payer complexity and fitting existing address-oriented infrastructure.
A node operator is checking BIP 17 OP_CHECKHASHVERIFY (CHV). Operational documentation should cite BIP 16 for deployed legacy P2SH and identify BIP 17 only when examining the historical alternatives.
A receiver could choose a complex spending condition while the sender paid a fixed 20-byte hash. The full policy would be supplied on spending, reducing payer complexity and fitting existing address-oriented infrastructure. This was the practical P2SH objective, not a request for miners to trust an off-chain script.
CHV would hash the end of the preceding script from the last executed CODESEPARATOR, compare that HASH160 value with the top stack item and fail on a mismatch. A match would continue without popping the hash. Those stack and separator details mattered to backwards compatibility and to every implementation reproducing the same digest.
The proposed output pushed a 20-byte hash, ran CHECKHASHVERIFY and then DROP. Redemption supplied signatures, a CODESEPARATOR and the committed script. Relay policy further constrained the appended script to a recognised standard type. Consensus validity, standard relay and wallet recognition therefore remained separate boundaries.
Old nodes would see the reassigned NOP permissively and could accept a block that upgraded nodes rejected. The document described miner signalling and a timestamp gate to limit a lasting split. Its one-confirmation attack illustrates why a nominally compatible soft fork still needs coordinated validation and cautious confirmation policy.
BIP 16 used a specific HASH160 and EQUAL output template followed by defined redeem-script evaluation. It addressed the same sender-facing need without introducing CHV semantics. Operational documentation should cite BIP 16 for deployed legacy P2SH and identify BIP 17 only when examining the historical alternatives.
The numeric slot proposed for CHV did not remain reserved for this design. BIP 65 later redefined OP_NOP2 as CHECKLOCKTIMEVERIFY under an activated consensus change. Software must interpret opcodes according to the active network rules and block context, never by copying an abandoned BIP table.
On isolated research tooling, reproduce the BIP 17 hash boundary and compare it with BIP 16 redeem-script validation. Trace the stack and CODESEPARATOR position, then show why a current node does not enable CHV. Keep experimental consensus binaries away from production datadirs and template failover.
BIP 17 OP_CHECKHASHVERIFY (CHV): A receiver could choose a complex spending condition while the sender paid a fixed 20-byte hash.
A receiver could choose a complex spending condition while the sender paid a fixed 20-byte hash.
CHV would hash the end of the preceding script from the last executed CODESEPARATOR, compare that HASH160 value with the top stack item and fail on a mismatch.
The proposed output pushed a 20-byte hash, ran CHECKHASHVERIFY and then DROP.
BIP 17 is a useful record of the contest to make script-hash payments practical, but Bitcoin adopted BIP 16 instead. CHV is closed, and its proposed opcode slot now has a different deployed meaning under CHECKLOCKTIMEVERIFY.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 128 guide to Draft timelock-recovery plan storage, presigned transaction pairs, relative delay, checksums, monitoring, cancellation and reorg safety.
BIP 433 guide to Draft keyless Pay to Anchor outputs, CPFP fee bumping, standardness, ephemeral dust, TRUC anti-pinning and wallet safety.
What is BIP-110? Learn what Bitcoin’s reduced-data soft-fork proposal restricted, why it was controversial and why it later closed.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.