P2SH-P2WSH

P2SH-P2WSH is a nested form of P2WSH. It puts a P2WSH lock, which holds the SHA-256 hash of a custom script, inside a legacy P2SH output. The address starts with 3, so wallets that cannot yet send to bc1 addresses can still pay it. When you spend it, the witness carries the custom script and the data it needs, so the spend keeps the SegWit discount.

The form does the same job as P2SH-P2WPKH, but for scripts rather than single keys. Its main use is multisignature setups.

Why was P2SH-P2WSH needed?

When SegWit arrived, many wallets and exchanges could pay only P2SH addresses. P2SH-P2WSH lets a sender pay a 3 address, while the receiver can still spend the coins as a native P2WSH. It is a stepping stone. If your wallet can send to a bc1 address, use P2WSH directly.

What does the P2SH lock look like?

On chain, the output looks like any other P2SH output: OP_HASH160, a 20-byte push, and OP_EQUAL. As hex, it is 23 bytes:

a914257014cec2f75c19367b2a6a0e08b9f304108e3b87

Output 0 of c57007980fabfd7c44895d8fc2c28c6ead93483b7c2bfec682ce0a3eaa4008ce carries this lock. It was confirmed in block 657,066.

The 20-byte hash is the HASH160 of a P2WSH lock, which is 0020 followed by a 32-byte SHA-256 hash:

P2WSH lock: 0020973cfd44e60501c38320ab1105fb3ee3916d2952702e3c8cb4cbb7056aa6b47f
HASH160:    257014cec2f75c19367b2a6a0e08b9f304108e3b

The P2SH layer is what makes the output payable from older wallets. A P2SH address encodes that hash with the prefix 05, which gives the 3 at the start. The address alone does not show the inner lock. You see it only when the output is spent.

What goes in the ScriptSig?

The scriptSig of a spend holds one push: the 34-byte P2WSH lock. The push adds one length byte in front, so the ScriptSig is 35 bytes:

220020973cfd44e60501c38320ab1105fb3ee3916d2952702e3c8cb4cbb7056aa6b47f

The first byte, 22, is 34 in decimal, the length of the push. Input 0 of 55c7c71c63b87478cd30d401e7ca5344a2e159dc8d6990df695c7e0cb2f82783 reveals this ScriptSig. It was confirmed in block 657,156.

The ScriptSig must hold nothing except that push. Bitcoin's BIP 141 rules reject a nested spend with anything else in the ScriptSig.

What goes in the witness?

The witness of a P2SH-P2WSH spend has the same layout as a direct P2WSH witness. The example below spends a 2-of-3 multisig, so the witness holds a dummy value, two signatures, and the witness script:

04
00
47  (a 71-byte signature)
47  (a 71-byte signature)
69  (the 105-byte witness script)

As hex, the witness is:

0400473044022047ebba593cba4048da04316b9fb6c076d95d17175d7560edc93868a7d170767502203d0ce939ae462ca685a15f5fd3a64b7a1793cb10473665d5bedd3322c55a2b1001473044022022a8a0ae1f80934abb38d4f8c3febf6f5c5c43e7e70460aa71f9a895aaea4d950220023b8f4d2fd90abdbe6f80c9bcb2b38c7326e5e9e0f3b1ea25a5499d240cacb20169522103591da02bf7c80dc5d0edee4bbbfad7e58320785e3e54d4dab117152361f7002c21027ea2bc65ce49dcd748e4e41a0c8881be388b9182ad5e47579a0de0119803827b2103c5fdaf887f76119a73a7f738d5d4a451ff07bbbc83422c529452d8a36ae59e3953ae

The witness script is the last item, and it plays the role of a P2SH redeem script. It is a 2-of-3 multisig: OP_2, three 33-byte compressed public keys, OP_3, and OP_CHECKMULTISIG. The witness totals 252 bytes. The signatures follow the BIP 143 signing rules, as in any SegWit spend.

How does Bitcoin check the spend?

A P2SH-P2WSH spend passes through two hash checks, one inside the other:

1. The outer P2SH check. Bitcoin hashes the ScriptSig push with HASH160. The result must equal the hash in the P2SH lock.
2. The inner P2WSH check. Bitcoin hashes the last witness item, the witness script, with SHA-256. The result must equal the 32-byte hash that the ScriptSig revealed. Then the witness script runs with the other witness items on the stack, as in a direct P2WSH spend.

The two hashes use different functions on purpose. The outer P2SH layer uses HASH160, as P2SH has since BIP 16. The inner P2WSH layer uses one SHA-256 pass, which gives a 256-bit hash. The P2WSH page explains why that matters.

How much does it cost?

The ScriptSig gets no discount, and the witness does. Using the 2-of-3 example, with 71-byte signatures, the three spend types compare like this:

Unlock	ScriptSig (bytes)	Witness (bytes)	Total (bytes)	Virtual bytes
P2SH	252	0	252	252
P2SH-P2WSH	35	252	287	98
P2WSH	0	252	252	63

The 252-byte witness counts as 63 virtual bytes, since each witness byte is 0.25. The nested form adds the 35-byte ScriptSig, for 98 virtual bytes. That is still much less than the 252 of a legacy P2SH spend. Fees are set per virtual byte, so the nested spend costs less than legacy P2SH and more than P2WSH. The virtual byte page explains the unit.

Sending is slightly cheaper than paying a native P2WSH lock. The nested output is 23 bytes, and a P2WSH lock is 34 bytes. The extra 11 bytes are the price of the 32-byte hash. Spending costs more, though: the 35-byte ScriptSig adds 35 virtual bytes to the spend.

How do you make a P2SH-P2WSH address?

The address is a P2SH address. You start from the P2WSH lock, then:

1. Apply HASH160 to the 34-byte P2WSH lock. You get 20 bytes.
2. Encode the 20 bytes with Base58Check, using the prefix 05 for a P2SH address. See Base58 and checksum.

The result starts with 3 and is usually 34 characters long. Nothing in the address says it is nested. The form becomes visible only when the output is spent.

Should you use it?

Use P2SH-P2WSH only when the sender can pay a 3 address and you want a multisignature or custom script. Otherwise use P2WSH. It is cheaper to spend, and the 11 extra bytes it adds to a payment are a small price.

The form is standard and valid, and older outputs of this kind are already in the chain. So it is worth knowing how to read one. Once you know how P2SH and P2WSH work separately, nested P2WSH is only the two of them combined.