Skip to main content
£0.00 0

Basket

No products in the basket.

ASIC mining articles and advice

BIP 381 Non-SegWit Output Script Descriptors Guide

BIP 381 guide covering Deployed pk(), pkh() and sh() descriptors, allowed contexts, redeemScript construction, key origins, checksums, compatibility and vectors.

BIP 381 non-SegWit descriptors guide cover

This guide explains BIP 381 non-SegWit descriptors 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 381 specifies the deployed output descriptor expressions for pre-SegWit standard scripts: pk(), pkh() and sh(). They deterministically describe P2PK, P2PKH and P2SH script construction while relying on the common BIP 380 descriptor grammar and key-expression rules.
  • Why it matters: BIP 381 makes legacy script policy explicit and reproducible through pk(), pkh() and sh(). Safe use requires strict context validation, complete redeemScript recovery and separation of watch-only descriptors from secret-bearing material.
  • Current position: BIP 381 is Deployed and Informational and requires BIP 380.

BIP 381 non-SegWit descriptors in simple English

BIP 381 non-SegWit descriptors: pk(KEY) produces a pay-to-public-key script containing the key and OP_CHECKSIG. It may appear in any context, subject to restrictions imposed by outer expressions.

Simple example

A node operator is checking BIP 381 non-SegWit descriptors. Implement checksum, key origin, derivation and range rules from the shared grammar before adding expressions.

Key terms in plain English

BIP:
Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
Node:
A computer running Bitcoin software that checks data and communicates with other peers.

Status and dependency

BIP 381 is Deployed and Informational and requires BIP 380. Implement checksum, key origin, derivation and range rules from the shared grammar before adding expressions.

pk expression

pk(KEY) produces a pay-to-public-key script containing the key and OP_CHECKSIG. It may appear in any context, subject to restrictions imposed by outer expressions.

pkh expression

pkh(KEY) produces DUP HASH160 key-hash EQUALVERIFY CHECKSIG. It can be top level or inside sh() or wsh(), and accepts one key expression.

BIP 381 non-SegWit descriptors technical diagram
pkh expression: the fields, validation boundary and operational evidence that implementations need to agree.

sh expression

sh(SCRIPT) is top-level only and produces HASH160 of the nested script followed by EQUAL. Spending also requires the redeemScript generated by the inner expression.

Key material

Descriptors may contain raw or extended public keys and, in protected contexts, private keys. Store public watch policies separately from signing material and preserve origins and wildcard branches.

Compatibility

The descriptor syntax was new even though the resulting scripts were standard and familiar. Negotiate parser support; do not mistake script recognition for descriptor import capability.

Validation

Run every valid and invalid vector, reject wrong argument types and forbidden nesting, compare derived scripts at several indexes and retain the canonical checksummed descriptor. Build a revision-pinned evidence pack on an isolated node, wallet or protocol harness. Record source commit, binary hash, network, chain identity, configuration and dependencies.

Frequently asked questions

What is the main point of BIP 381 non-SegWit descriptors?

BIP 381 non-SegWit descriptors: pk(KEY) produces a pay-to-public-key script containing the key and OP_CHECKSIG.

For BIP 381 non-SegWit descriptors, what should a beginner know about status and dependency?

BIP 381 is Deployed and Informational and requires BIP 380. Implement checksum, key origin, derivation and range rules from the shared grammar before adding expressions.

For BIP 381 non-SegWit descriptors, what should a beginner know about pk expression?

pk(KEY) produces a pay-to-public-key script containing the key and OP_CHECKSIG.

For BIP 381 non-SegWit descriptors, what should a beginner know about pkh expression?

pkh(KEY) produces DUP HASH160 key-hash EQUALVERIFY CHECKSIG. It can be top level or inside sh() or wsh(), and accepts one key expression.

Conclusion

BIP 381 makes legacy script policy explicit and reproducible through pk(), pkh() and sh(). Safe use requires strict context validation, complete redeemScript recovery and separation of watch-only descriptors from secret-bearing material.

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.

ASIC MINER PICKS

Recommended ASIC Mining Hardware

Compare three of our highest ranked ASIC miners currently available, with live product details and pricing.
Browse all ASIC miners
MORE MINING ADVICE

More ASIC Mining Articles

Read practical advice about choosing hardware, calculating electricity costs, setting up miners, hosting and maintenance.
MINER COMMUNITY

Join the ASIC Mining Discussion

Ask a question or share what has worked for you. Your experience may help another miner make a better decision.

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.

Log in to read comments Register to join the discussion

Membership helps us protect the discussion from spam and keep answers useful.

ASIC MINING SUPPORT

Need Help Choosing an ASIC Miner?

Tell us what you want to mine, your electricity cost and where the machine will run. We can help you compare hardware, power requirements, hosting and repairs.
Contact our mining team
Browse ASIC miners