Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining knowledge centre

BIP 18 hashScriptCheck Explained: A Historical P2SH Design

BIP 18 hashScriptCheck explained: review its dataSig and scriptCheck model, sigop accounting, compatibility plan and relationship to deployed P2SH.

BIP 18 hashScriptCheck guide cover

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.

BIP 18 hashScriptCheck technical diagram
Input validation steps: the fields, validation boundary and operational evidence that implementations need to agree.

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.

On this page

Search More Guides

Continue Reading

Explore more practical guidance on ASIC hardware, profitability, setup, hosting and maintenance.

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.
Contact our team
Browse ASIC miners