P2WPKH (Pay-to-Witness-Public-Key-Hash)

What Is P2WPKH?

P2WPKH (Pay-to-Witness-Public-Key-Hash) is a Bitcoin transaction output type introduced by Segregated Witness (BIP 141) in August 2017. It is the SegWit-native equivalent of the original P2PKH format: a single compressed public key controls the funds, but the signature and key are moved out of the transaction's scriptSig and into a separate witness structure. This separation is what "segregated witness" means, and it unlocks significant fee savings.

On the network, P2WPKH outputs are identified by a scriptPubKey that starts with witness version 0 followed by a 20-byte public key hash. When encoded as a user-facing address, this becomes the familiar "bc1q" string produced by Bech32 encoding. The lowercase, alphanumeric format eliminates mixed-case confusion and provides built-in error detection that can catch up to 4 character errors in any address.

Defined across BIP 141 (consensus rules), BIP 143 (signature hashing), and BIP 173 (address encoding), P2WPKH became the recommended default address type for most wallets after 2017. It remains the most common output type on Bitcoin, used in roughly 70-80% of all transactions as of 2026.

How It Works

To understand P2WPKH, it helps to compare it with legacy P2PKH. Both require the spender to prove ownership of a single private key. The difference is where the proof lives inside the transaction.

Legacy P2PKH Structure

In a P2PKH transaction, the scriptSig (inside the transaction body) contains both the signature and the public key. Every byte of scriptSig counts at full weight when calculating the transaction fee:

scriptPubKey: OP_DUP OP_HASH160 <20-byte-hash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig:    <signature> <public-key>

P2WPKH Structure

P2WPKH replaces the verbose scriptPubKey with a compact witness program and moves the spending proof into the witness field:

scriptPubKey: OP_0 <20-byte-key-hash>
witness:      <signature> <compressed-public-key>

The scriptPubKey shrinks from 25 bytes to 22 bytes. More importantly, the signature (~72 bytes) and compressed public key (33 bytes) now reside in the witness, where each byte costs only 1 weight unit instead of 4. This is the witness discount defined in BIP 141.

The Witness Discount

Bitcoin measures transaction size in weight units (WU). Non-witness data costs 4 WU per byte; witness data costs 1 WU per byte. Virtual bytes (vbytes) equal total weight divided by 4. Since miners set fee rates in sats/vbyte, placing large data (signatures) in the discounted witness field directly reduces fees.

For a typical single-input, two-output transaction:

The ~38% savings over P2PKH made P2WPKH the clear choice for cost-conscious users. For a deeper look at how fee dynamics play out across address types, see the Bitcoin fee market dynamics research article.

BIP 143: Improved Signature Hashing

P2WPKH uses a new transaction digest algorithm defined in BIP 143. The legacy sighash algorithm had a serious flaw: its computation time grew quadratically with the number of inputs (O(n²) hashing). A transaction with many inputs could take minutes to verify.

BIP 143 fixes this by pre-computing hash values for previous outputs, sequences, and outputs, then reusing them across all inputs. It also commits to the value of each input being spent, which prevents a class of fee-related attacks where a hardware signing device could be tricked into signing away more in fees than the user intended.

Bech32 Encoding

P2WPKH addresses use Bech32 encoding (BIP 173), which produces human-readable strings starting with "bc1q":

bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

Breakdown:
  bc   → human-readable part (Bitcoin mainnet)
  1    → separator
  q    → witness version 0 (encoded in base32)
  ...  → 20-byte key hash + 6-character BCH checksum

The Bech32 format uses only lowercase letters and digits (no mixed case), which makes addresses easier to read aloud, copy accurately, and encode in QR codes. The BCH error-correcting checksum guarantees detection of any single error affecting up to 4 characters and catches longer error bursts with probability greater than 1 in 10&sup9;.

Derivation Path and Wallet Integration

BIP 84 standardizes the derivation path for P2WPKH addresses in HD wallets:

m/84'/0'/0'/0/0   (first receiving address)
m/84'/0'/0'/1/0   (first change address)

Purpose: 84' (P2WPKH, per BIP 84)
Coin:    0'  (Bitcoin mainnet)
Account: 0'  (first account)

Extended public keys for P2WPKH accounts use the "zpub" prefix (as opposed to "xpub" for legacy or "ypub" for wrapped SegWit). This prefix tells wallets which address format to derive, preventing users from accidentally mixing address types. For more on how Bitcoin address types have evolved, see the Bitcoin address types: P2PKH to Taproot research article.

Use Cases

• Everyday transactions: P2WPKH is the standard address type for most Bitcoin wallets. Any user sending or receiving bitcoin benefits from the reduced fees compared to legacy addresses.
• Exchange withdrawals: most major exchanges default to P2WPKH (bc1q) for withdrawals, minimizing network fees for their users and reducing the exchange's own consolidation costs.
• UTXO consolidation: when wallets merge many small outputs into fewer large ones, the fee savings of P2WPKH compound across every input, making consolidation significantly cheaper than with legacy formats.
• Layer 2 funding: opening Lightning channels or depositing into protocols like Spark typically uses P2WPKH or P2TR inputs for the on-chain funding transaction.

The Transition to Taproot (P2TR)

Taproot (BIP 341), activated in November 2021, introduced P2TR as the next-generation single-key address format. For simple key-path spends, P2TR is roughly 15% cheaper than P2WPKH on inputs because it uses Schnorr signatures (64 bytes, no DER encoding overhead) instead of ECDSA signatures (~72 bytes).

P2TR addresses use witness version 1 and Bech32m encoding (BIP 350), producing "bc1p" addresses. The BIP 86 derivation path (m/86'/0'/0') standardizes Taproot key-only wallets, analogous to how BIP 84 standardized P2WPKH.

Despite Taproot's advantages, P2WPKH remains dominant. As of 2026, native SegWit v0 transactions still account for the majority of Bitcoin network activity. The transition is gradual because P2WPKH enjoys universal wallet and exchange support, while Taproot adoption continues to grow. For applications building on Bitcoin today, supporting both P2WPKH and P2TR is the practical choice.

Risks and Considerations

Compatibility with Older Software

When P2WPKH was first introduced, not all wallets and services could send to bc1q addresses. This gap led to the interim P2SH-P2WPKH (wrapped SegWit) format that looks like a traditional "3..." address to legacy software. By 2026, bc1q support is effectively universal, but some very old or unmaintained software may still lack it.

Address Reuse and Privacy

P2WPKH does not improve on-chain privacy compared to P2PKH. Each address still reveals a unique public key hash, and reusing addresses links transactions to the same key. P2TR improves this slightly because all key-path spends look identical on-chain regardless of the underlying script complexity.

Bech32 Length-Extension Weakness

The original Bech32 encoding (BIP 173) has a known weakness: inserting or removing a "q" character before the final character of a witness version 1+ address can produce a valid checksum. This does not affect P2WPKH (witness version 0) but motivated the creation of Bech32m (BIP 350) for Taproot and future witness versions. P2WPKH addresses continue to use the original Bech32 encoding safely.

Fee Estimation

Because P2WPKH transactions have a different weight profile than legacy transactions, fee estimation must account for the witness discount. Wallets that estimate fees based on raw byte size rather than virtual bytes may overpay. Modern wallet software handles this correctly, but custom PSBT workflows or manual transaction construction require awareness of the weight calculation.

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.