P2WPKH

P2WPKH stands for pay to witness public key hash. It is a SegWit locking script that locks an output to the 20-byte hash of a public key. To spend it, you show a signature and the public key in the witness, the part of an input that holds SegWit data, instead of in the scriptSig. Its rules match the older P2PKH script, but the witness costs less in fees.

A P2WPKH lock has a fixed form. Nothing needs to be interpreted, so you can read one at a glance.

What does a P2WPKH lock look like?

A P2WPKH scriptPubKey has two parts: the OP_0 opcode, and a push of 20 bytes. Here is an example:

OP_0
OP_PUSHBYTES_20
841b80d2cc75f5345c482af96294d04fdd66b2b7

As hex, the same lock is:

0014841b80d2cc75f5345c482af96294d04fdd66b2b7

The first byte, 00, is OP_0. The second, 14, is 20 in decimal and says that 20 bytes follow. The total is 22 bytes. Output 0 of c178d8dacdfb989f9d4fa45828ed188cd54a0414d625c3e61e75c5e3ac15a83a carries this lock.

OP_0 is the witness version. A script that starts with OP_0 and then a 20-byte push is always read as P2WPKH. A 32-byte push after OP_0 means P2WSH instead, and a leading OP_1 means P2TR.

What goes in the witness?

The scriptSig of a P2WPKH input must be empty. All the unlocking data goes in the witness, which has two items:

Item	Size	Contents
0	72 bytes (48)	A DER-encoded ECDSA signature, plus one sighash byte (01 here)
1	33 bytes (21)	The compressed public key, starting with 02 or 03

The witness is serialized as a count of items, then each item with its length in front:

02
48
3045022100c7fb3bd38bdceb315a28a0793d85f31e4e1d9983122b4a5de741d6ddca5caf8202207b2821abd7a1a2157a9d5e69d2fdba3502b0a96be809c34981f8445555bdafdb01
21
03f465315805ed271eb972e43d84d2a9e19494d10151d9f6adb32b8534bfd764ab

Joined into one hex string, it is 02 48 and the 72-byte signature, then 21 and the 33-byte key. That is 108 bytes in all. The witness for this example is input 0 of 1674761a2b5cb6c7ea39ef58483433e8735e732f5d5815c9ef90523a91ed34a6.

Fields inside the witness use compact size lengths, not the OP_PUSHBYTES opcodes that a P2PKH scriptSig uses. The witness is data, not a script.

Only compressed public keys are allowed. Bitcoin Core applies this rule as a standardness check, so a P2WPKH spend with an uncompressed key is not relayed. The hash in the lock still looks the same, so the mistake only shows up when someone tries to spend.

How does Bitcoin check a P2WPKH spend?

A P2WPKH is not run as a normal script. When Bitcoin sees the lock, it uses special witness rules, then checks the spend as a P2PKH.

1. It places the two witness items on the stack: the signature, then the public key.
2. It turns the 20-byte hash into a P2PKH script: OP_DUP OP_HASH160 <hash> OP_EQUALVERIFY OP_CHECKSIG.
3. It runs that script. The public key must hash to the lock, and the signature must be valid for the transaction.

The signature for a SegWit input follows the BIP 143 signing rules. Those rules include the amount of the input in the signed data, so the signature commits to the value being spent. Legacy signatures did not commit to it.

How do you make a P2WPKH address?

The address is the bech32 encoding of the witness program, which is the version and the 20-byte hash in the lock. You start from the public key:

1. Take the compressed public key and apply HASH160 (SHA-256, then RIPEMD-160). You get 20 bytes.
2. Put OP_0 and the 20 bytes together, so the scriptPubKey is 0014 followed by the hash.
3. Encode the program with bech32, as BIP 173 defines.

The result starts with bc1q, because q is the bech32 character for version 0. The example hash above gives bc1qssdcp5kvwh6nghzg9tuk99xsflwkdv4hgvq58q. A P2WPKH address is always 42 characters long, since the hash in it is 20 bytes. The address page explains the other address formats.

Why is P2WPKH cheaper than P2PKH?

The witness is discounted in the virtual size of a transaction. Each witness byte counts as one weight unit, and other bytes count as four, so a witness byte is worth 0.25 virtual bytes.

Unlock	Where the data sits	Bytes	Virtual bytes
P2PKH	scriptSig	107	107
P2WPKH	witness	108	27

The witness figure includes the 02 item count, so the signature and key take 107 bytes. The output side has no discount. A P2PKH lock is 25 bytes, and a P2WPKH lock is 22 bytes, so a P2WPKH output is also a little smaller. Fees are paid per virtual byte, so spending a P2WPKH output costs about a quarter of the unlocking space of a P2PKH.

Where did P2WPKH come from?

P2WPKH was added with Segregated Witness (SegWit), defined in BIP 141. SegWit moved the unlocking data into the witness. That also stopped signatures from changing the txid of a transaction. SegWit rules became active at block 481,824, in August 2017. The SegWit upgrade page covers the rest of the change.

What do real P2WPKH transactions look like?

Example 1. Output 0 of dfcec48bb8491856c353306ab5febeb7e99e4d783eedf3de98f3ee0812b92bad is a P2WPKH lock. Input 0 of f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd spends it. Both transactions are confirmed in block 481,824, the first block where SegWit rules applied. Nodes did not check witness programs before that block, so this is among the earliest P2WPKH spends that the rules enforced.

Example 2. Output 0 of 7c53ba0f1fc65f021749cac6a9c163e499fcb2e539b08c040802be55c33d32fe locks coins to bc1qvugyzunmnq5y8alrmdrxnsh4gts9p9hmvhyd40. Its hash comes from an uncompressed public key. It looks valid on chain, but nodes treat a spend of it as non-standard, so it is hard to spend. Do not lock coins this way.

Use P2WPKH when your wallet supports it. Most do today. For the older nested form, see P2SH-P2WPKH.