This guide explains BIP 18 hashScriptCheck 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 18 hashScriptCheck documented an alternative way to formalise pay-to-script-hash by naming three transaction elements: dataSig, scriptCheck and hashScriptCheck. Its status is Complete as a historical specification, but the Bitcoin network deployed the closely related BIP 16 rules.
- Why it matters: BIP 18 offers a precise historical vocabulary for the P2SH transition, including resource accounting and compatibility. Current operations should validate the deployed BIP 16 behaviour and use BIP 18 only to understand the design record.
- Current position: Its status is Complete as a historical specification, but the Bitcoin network deployed the closely related BIP 16 rules.
What this means 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 proposal as giving each transaction a limited allowance of computer work. Simple operations use a little of that allowance and expensive operations use more. If a script uses the whole allowance, validation stops.
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.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
The proposed three-part model
dataSig replaced scriptSig with push-only data, its final element was the scriptCheck, and hashScriptCheck replaced scriptPubKey with a commitment to that script. The model attempted to describe data and executable policy more explicitly while remaining interpretable by legacy software through the familiar HASH160 template.
Exact output encoding
The committed output was required to match OP_HASH160, a 20-byte hash push and OP_EQUAL exactly. A near match or a block before activation would use legacy script processing. Exact template recognition is consensus-sensitive: accepting extra opcodes or non-minimal lengths would change which validation branch runs.
Input validation steps
The dataSig had to contain pushes only, the final scriptCheck had to hash to the output commitment, and execution with the earlier data elements preloaded had to finish successfully with true on top. Each step creates a distinct rejection reason useful for test vectors and incident diagnosis.
Static sigop accounting
CHECKSIG operations counted individually, small preceded CHECKMULTISIG constructions counted by their explicit key number, and other CHECKMULTISIG cases counted as twenty. Static counting bounded block verification cost even when branches were not executed. Template and pool software needed the same conservative interpretation.
Compatibility and signalling
The proposal described non-standard behaviour for old relay nodes, permissive old-node block interpretation, coinbase signalling and a coordinated activation threshold. That history shows why a hash-equality outer script did not by itself make the inner spending rule active for all validators.
Relationship to deployed P2SH
BIP 18 stated that it was protocol-identical to BIP 16 while framing and deprecating the legacy fields differently. Production Bitcoin documentation normally uses BIP 16 terminology: scriptSig, redeem script and P2SH scriptPubKey. Mixing the alternate names into current runbooks can obscure what deployed software actually exposes.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is BIP 18 hashScriptCheck?
BIP 18 hashScriptCheck documented an alternative way to formalise pay-to-script-hash by naming three transaction elements: dataSig, scriptCheck and hashScriptCheck. Its status is Complete as a historical specification, but the Bitcoin network deployed the closely related BIP 16 rules.
Is BIP 18 hashScriptCheck active or supported today?
Its status is Complete as a historical specification, but the Bitcoin network deployed the closely related BIP 16 rules.
Why does BIP 18 hashScriptCheck matter?
BIP 18 offers a precise historical vocabulary for the P2SH transition, including resource accounting and compatibility. Current operations should validate the deployed BIP 16 behaviour and use BIP 18 only to understand the design record.
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 18 offers a precise historical vocabulary for the P2SH transition, including resource accounting and compatibility. Current operations should validate the deployed BIP 16 behaviour and use BIP 18 only to understand the design record.
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.
