Solo Mining Calculator: Estimate Odds and Timeframes
Use a solo mining calculator correctly: enter productive hashrate, network conditions, uptime and time horizon, then read expected time and probability without.
Read article
ASIC mining knowledge centre
BIP 17 OP_CHECKHASHVERIFY Explained: The Closed P2SH Alternative
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.
TL;DR
- What it is: BIP 17 OP_CHECKHASHVERIFY, abbreviated CHV, proposed reassigning OP_NOP2 so a compact output could commit to a script supplied by the spender. It pursued the same payment-to-script-hash goal as BIP 16 through different execution semantics.
- Why it matters: 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.
- Current position: The proposal is closed and OP_NOP2 later became CHECKLOCKTIMEVERIFY, so BIP 17 must be treated as historical design evidence rather than a usable Bitcoin feature.
BIP 17 OP_CHECKHASHVERIFY (CHV) in simple English
A BIP is a document that proposes or explains a Bitcoin idea, standard or rule. A BIP number does not mean the idea is active. Some BIPs are widely used, while others are drafts or historical proposals.
You do not need to read code to understand the main point. Start with the status, the problem being addressed and the practical effect on ordinary users, wallets, miners or node operators.
Simple example
Think of the transaction as a form passed between several authorised signers. Each person or device checks the same payment details before adding approval. Passing the form around does not make the payment safe unless every signer checks what it contains.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Consensus:
- The shared rules full nodes use to decide whether blocks and transactions are valid.
- Soft fork:
- A proposed tightening of Bitcoin rules that old nodes may not enforce themselves.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
What CHV tried to achieve
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.
Proposed opcode behaviour
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.
Standard output and redemption
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.
Activation and old-node risk
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.
Why BIP 16 won
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.
Opcode history matters
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.
Safe reconstruction exercise
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 demonstrate why a current node does not enable CHV. Keep experimental consensus binaries away from production datadirs and template failover.
Frequently asked questions
What is BIP 17 OP_CHECKHASHVERIFY?
BIP 17 OP_CHECKHASHVERIFY, abbreviated CHV, proposed reassigning OP_NOP2 so a compact output could commit to a script supplied by the spender. It pursued the same payment-to-script-hash goal as BIP 16 through different execution semantics.
Is BIP 17 OP_CHECKHASHVERIFY active or supported today?
The proposal is closed and OP_NOP2 later became CHECKLOCKTIMEVERIFY, so BIP 17 must be treated as historical design evidence rather than a usable Bitcoin feature.
Why does BIP 17 OP_CHECKHASHVERIFY matter?
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.
Do beginners need to use the technical details?
No. Most readers only need to understand the idea and its current status. Developers and node operators can use the primary sources when they need the exact technical rules.
Conclusion
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.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
On this page
Search More Guides
BIP-110 Explained: Rules, Signalling and Why It Closed
BIP-110 Explained made simple. See the main facts, costs, risks and practical checks before you make a decision.
Read article
Bitcoin Core 29.4 Release: Chainstate Disk I/O Guide
Bitcoin Core 29.4 guide covering repeated chainstate rewrites, regular compaction, LevelDB seek compaction, transaction-data lifetime and wallet sizing fixes.
Read article
Need Advice for Your Mining Setup?
Use our guidance to build your shortlist, then speak to our team when you want help comparing hardware, power, hosting or repairs.