P2WSH (Pay-to-Witness-Script-Hash)

What Is P2WSH?

P2WSH (Pay-to-Witness-Script-Hash) is a Bitcoin output type introduced by Segregated Witness (BIP141) that allows spending conditions to be defined by an arbitrary script while keeping the script data in the segregated witness field. It is the SegWit successor to P2SH (Pay-to-Script-Hash), designed for any transaction that requires more than a single signature: multisig wallets, HTLCs, timelocked contracts, and other programmable spending conditions.

Where P2WPKH is the SegWit format for simple single-key payments, P2WSH handles everything that requires a Bitcoin Script. On-chain, a P2WSH output reveals only a 32-byte hash of the spending script. The full script and its satisfaction data are provided in the witness field only when the output is spent, saving block space and reducing transaction fees.

How It Works

A P2WSH output locks funds to the SHA256 hash of a witness script. To spend the output, the spender provides the original script plus whatever data satisfies it (signatures, preimages, etc.) in the transaction's witness field. Nodes verify that the script hashes to the committed value and that execution succeeds.

Output Structure

The scriptPubKey for a P2WSH output is exactly 34 bytes:

OP_0 OP_PUSHBYTES_32 <32-byte SHA256 hash of witness script>

// In hex: 0020<64 hex characters>
// OP_0 = witness version 0
// 32 bytes = triggers P2WSH interpretation (20 bytes would be P2WPKH)

The scriptSig must be completely empty for native P2WSH. Any non-empty scriptSig causes validation to fail.

Spending a P2WSH Output

When spending, the witness field contains the stack items needed to satisfy the script, followed by the witness script itself as the final item:

// Example: spending a 2-of-3 multisig P2WSH output
witness: [
  0x00,             // dummy element (OP_CHECKMULTISIG bug)
  <signature_A>,    // first required signature
  <signature_B>,    // second required signature
  <witnessScript>   // OP_2 <pubA> <pubB> <pubC> OP_3 OP_CHECKMULTISIG
]

// Validation steps:
// 1. Pop witnessScript from the stack
// 2. SHA256(witnessScript) must equal the hash in scriptPubKey
// 3. Execute witnessScript with remaining stack items
// 4. Script must succeed with a single TRUE on the stack

SHA256 vs HASH160

P2WSH uses a single SHA256 hash (32 bytes) instead of the RIPEMD160(SHA256()) construction (20 bytes) used by P2SH. This is not just a cosmetic change: it addresses a real security concern for multisig setups.

With P2SH multisig, a malicious co-signer could theoretically search for a collision between the legitimate multisig script and a script paying only to themselves. At ~2^80 work, this is within theoretical reach. P2WSH's 256-bit hash raises the bar to ~2^128, eliminating this attack vector.

Script Size Limits

One of P2WSH's most significant improvements is the expanded script size limit. P2SH scripts are capped at 520 bytes because the redeem script must fit inside a single data push in the scriptSig. P2WSH scripts live in the witness field and are not subject to this constraint:

This expanded capacity enables larger multisig configurations (15-of-20 or beyond) and more complex contracts that simply cannot fit within P2SH's 520-byte limit. For a deeper look at what these scripts can express, see Bitcoin Script Programmability.

The Witness Discount

SegWit introduced a weight-based fee system where witness bytes count as only 1/4 of a weight unit, compared to non-witness bytes which count as 4 weight units each. Since P2WSH moves signatures and scripts into the witness field, script-heavy transactions benefit substantially:

For transactions with many signatures, such as high-threshold multisig or complex HTLC scripts, the savings grow even larger. This makes P2WSH particularly attractive in fee-sensitive environments. For more on how fees interact with transaction design, see Bitcoin Fee Market Dynamics.

Address Format

P2WSH uses Bech32 encoding (defined in BIP173) with the following characteristics:

• Mainnet prefix: bc1q (the q encodes witness version 0)
• Testnet prefix: tb1q
• Address length: exactly 62 characters (compared to P2WPKH's 42)
• Character set: lowercase alphanumeric, excluding 1, b, i, and o to reduce visual ambiguity

// P2WSH address (62 characters, bc1q prefix)
bc1qwqdg6squsna38e46795at95yu9atm8azzmyvckulcc7kytlcckxswvvzej

// P2WPKH address for comparison (42 characters, bc1q prefix)
bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

BIP143 Sighash Improvements

P2WSH uses the BIP143 sighash algorithm, which solves two critical problems with legacy transaction signing:

• Quadratic hashing: legacy sighash re-serialized the entire transaction for each input, causing O(n^2) computation. BIP143 precomputes shared hash components, achieving O(n) performance.
• Input value commitment: the sighash now includes the value of the output being spent. This allows hardware wallets and offline signers to verify exact amounts without fetching previous transactions, preventing fee-manipulation attacks.

Native P2WSH vs P2SH-P2WSH

During the SegWit rollout, P2SH-P2WSH (nested or wrapped SegWit) was introduced as a compatibility bridge. It wraps a P2WSH witness program inside a P2SH output, so wallets that only support sending to 3... addresses can still fund SegWit scripts:

• P2SH-P2WSH uses a standard P2SH address (3...) and places the witness program in the scriptSig
• Native P2WSH uses a Bech32 address (bc1q...) with an empty scriptSig
• Native P2WSH is more efficient: smaller scriptPubKey (34 vs 23 bytes) and no scriptSig overhead

Since all modern wallets and exchanges now support Bech32 addresses, native P2WSH should always be preferred over P2SH-P2WSH. The nested format exists solely for backward compatibility and is declining in usage.

Use Cases

Multisig Wallets

The most common use of P2WSH is multisig (multi-signature) wallets. An m-of-n multisig script requires m signatures from a set of n public keys to authorize spending. P2WSH's expanded script capacity supports larger key sets than P2SH, and the witness discount dramatically reduces fees for signature-heavy transactions. For a comprehensive look at multisig architectures, see Bitcoin Multisig Wallets Explained.

Lightning Network Channels

Lightning Network funding transactions create P2WSH outputs with 2-of-2 multisig scripts. Both channel participants must sign to close the channel cooperatively. On-chain, the funding output reveals only a P2WSH hash, keeping the channel structure private until the channel closes. HTLCs routed through channels also rely on P2WSH scripts that combine hash locks with timelocks.

Hash Time-Locked Contracts

HTLCs are P2WSH scripts that combine a hash lock with a timelock: one party can claim funds by revealing a preimage before a deadline, or the other party reclaims the funds after the timeout. This pattern underpins Lightning routing, atomic swaps, and submarine swaps.

Complex Contracts

The 10,000-byte consensus limit enables contracts that are impossible under P2SH's 520-byte cap: large escrow arrangements, vault constructs using OP_CHECKSEQUENCEVERIFY, and spending policies defined with Miniscript. For developers building complex spending policies, see Miniscript: Bitcoin Spending Policies.

The Transition to Taproot

Taproot (P2TR), activated in November 2021, offers significant advantages over P2WSH for most script use cases:

• Privacy: all P2TR outputs look identical on-chain regardless of complexity. P2WSH reveals the full witness script when spent, exposing the contract structure.
• Key-path spending: when all parties agree, a P2TR output can be spent with a single Schnorr signature, appearing indistinguishable from a simple payment.
• MAST (Merkelized Alternative Script Trees): P2TR encodes multiple spending paths in a Merkle tree. Only the executed branch is revealed, hiding unused conditions and saving space.
• Efficient multisig: MuSig2 aggregates multiple signatures into a single 64-byte Schnorr signature, dramatically reducing the on-chain footprint compared to P2WSH's individual-signature approach using OP_CHECKMULTISIG.

For a detailed comparison of address types across Bitcoin's history, see Bitcoin Address Types: P2PKH to Taproot. For more on Taproot's cryptographic foundations, see Taproot and Schnorr Signatures Explained.

When P2WSH Is Still Used

Despite Taproot's advantages, P2WSH remains relevant in several contexts:

• Existing Lightning channels that were opened before Taproot adoption
• Multisig setups using OP_CHECKMULTISIG that have not migrated to MuSig2 or FROST
• Protocols and wallets that have not yet implemented BIP341/BIP342 support
• Applications requiring PSBT workflows with broad hardware wallet compatibility

Why It Matters

P2WSH was a foundational upgrade that made script-based Bitcoin transactions practical for everyday use. By reducing multisig fees by up to 65%, expanding script capacity, and improving signing security, it enabled the growth of Lightning Network channels, multisig custody solutions, and complex on-chain contracts. Layer 2 protocols like Spark build on these primitives: the efficient, script-capable UTXO model that P2WSH helped establish is central to how off-chain systems anchor trust back to the Bitcoin base layer.

Risks and Considerations

Script Visibility on Spend

When a P2WSH output is spent, the full witness script is revealed on-chain. For multisig wallets, this exposes the number of signers, the threshold, and all public keys. This is a privacy concern that Taproot addresses through key-path spending and MAST.

Fee Overhead for Complex Scripts

While the witness discount reduces fees, P2WSH scripts with many spending conditions still carry all conditions in a single script. Every condition is revealed when spending, even if only one path is used. This is inefficient compared to Taproot's MAST approach, where unused branches remain hidden and unpaid for.

Policy vs Consensus Limits

The 10,000-byte consensus limit and the 3,600-byte policy (relay) limit can cause confusion. A witness script between 3,600 and 10,000 bytes is valid if mined but will not be relayed by default Bitcoin Core nodes. Developers building large scripts must coordinate directly with miners or use custom relay policies, adding operational complexity.

Backward Compatibility

While Bech32 adoption is now nearly universal, some older systems and exchanges still struggle with bc1q addresses. Users interacting with legacy platforms may need to use P2SH-P2WSH as a fallback, which sacrifices some of the fee savings.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.