P2WSH

Pay to witness script hash is the SegWit version 0 output for anything more complicated than a single key, written as a 62-character bc1q address. Bitcoin Core relays a spend whose witness script reaches 3,600 bytes and whose witness holds up to 100 stack items, where a P2SH redeem script stops at 520 bytes. The extra room is why serious contracts moved here.

How it works

A P2WSH output is the byte 0x00 for witness version 0 followed by a push of 32 bytes, 34 bytes altogether. Those 32 bytes are a plain SHA-256 of the serialized witness script, not the RIPEMD-160 of a SHA-256 used elsewhere in bitcoin.

That choice is deliberate. A 160-bit commitment offers roughly 80 bits of collision resistance, which is uncomfortable when a counterparty helps choose what goes into the script and could search for two scripts sharing a hash. A 256-bit commitment removes the concern. Single-key P2WPKH keeps the shorter hash because only one party picks the key, and the address stays 20 characters shorter as a result.

Spending pushes the arguments onto the witness stack and finishes with the serialized script. A node hashes that final item, compares it to the commitment, then executes the script with what remains. Bitcoin Core's relay policy sets the boundaries in policy.h: 3,600 bytes for the script, 100 items on the stack, and 80 bytes per item.

Fees explain the migration. A 2-of-3 spend here runs about 104.5 vbytes, because both signatures and the whole 105-byte script ride in the witness at one weight unit per byte. The same policy under P2SH costs roughly 297 vbytes. The 20-key consensus ceiling on OP_CHECKMULTISIG is also reachable, since twenty keys occupy under 700 bytes.

Where you see it

Every Lightning channel is funded into a 2-of-2 P2WSH output, which makes this one of the most common script types on the chain even though few people ever type the address. Institutional custody, miniscript policies and timelocked inheritance clauses use it too.

On a block explorer an unspent P2WSH output is a 62-character bc1q string and nothing more. It looks the same whether it guards two keys or twenty, and the conditions surface only when the coins move.

Backups have to include the script. A seed phrase regenerates keys, not arbitrary scripts, so keep the descriptor or the exact script bytes alongside the seed and confirm you can restore from them before the address holds real money.

P2WSH vs Witness script

P2WSH is the output; the witness script is the content it commits to. The output holds 32 bytes of hash and nothing else, so it conveys no information about the conditions attached, and none of the script appears on chain until a spend publishes it. The obligation is lopsided as a result. A sender needs only the address and can pay without understanding anything. The recipient needs the exact script bytes forever, because losing them makes the coins unspendable no matter how many private keys survive.