Private key → P2WPKH address (bech32)

What this page computes

You give it one 256-bit private key. It gives you back the native SegWit address for that key — the string that starts with bc1q. Rather than printing only the final answer, the page keeps every layer of the derivation separate, so each step can be checked against the next one by hand:

1. What SegWit actually changed, and why this address exists

"SegWit" (segregated witness, BIP141/143/173) activated on 24 August 2017 and is usually described as one change. It was really four, and this address type is the visible surface of all of them.

Transaction malleability. Before SegWit an ECDSA signature travelled inside the scriptSig of the input it authorised. A signature is a DER-encoded pair of integers, and several different byte strings decode to the same mathematical signature — so a third party could re-encode a signature, or wrap it in extra push operations, without invalidating the transaction. That mutated the transaction id: the money still moved, but any second-layer protocol that had committed to the old txid (unconfirmed child spends, payment channels, Lightning's ancestors) broke. The fix was structural: sign the input, then move the signature out of the transaction proper into a parallel witness structure. The txid is now computed from the serialization without witness data, so it can no longer be changed by touching a signature; a separate wtxid covers the witness.

Block weight instead of block size. A block is no longer measured in bytes but in weight units (WU). Non-witness bytes cost 4 WU each; witness bytes cost 1 WU each. The cap is 4,000,000 WU, which still enforces the old 1 MB limit on the non-witness part of a block while leaving room for witness data on top.

The witness discount. Because witness bytes are 4× cheaper in weight terms, moving data into the witness cuts the effective fee. Spending a P2WPKH output is roughly a third lighter than spending the equivalent P2PKH output — the table below is the arithmetic for one input, computed from the exact byte counts rather than quoted from folklore.

Script versioning. The "witness program" is a byte string plus a version number, and the consensus rules for it are chosen by that version. Version 0 is P2WPKH/P2WSH; version 1 is Taproot. That upgrade path is the reason SegWit mattered for the future as much as for the present.

2. Where the fee saving comes from

A P2WPKH input carries an empty scriptSig (one byte, the length 00) and puts the signature and the public key in the witness instead. The numbers below assume one input, a 72-byte DER signature, a 33-byte compressed public key, and a 64-byte Schnorr signature for Taproot; vsize is weight ÷ 4 (rounded up, as nodes do).

That is 54.1% less weight than P2PKH for the same single-key spend, before any output changes. On a busy chain, that difference is the whole reason wallets pushed users onto bc1q addresses.

3. The witness program: OP_0 <20-byte push>

What actually lives on the blockchain is a 22-byte output script. The address is only a human-friendly encoding of its middle 20 bytes.

to spend it, the witness stack supplies exactly two items: a signature and the full compressed public key. The script interpreter hashes the key, compares the result with the 20 bytes in the program, and checks the signature against that key. Nothing in the program commits to a signature encoding, and nothing is executed from the script itself — that is what removes the malleability surface.

4. bech32, byte by byte

bech32 (BIP173) is a base-32 encoding with a checksum, designed for QR codes and for reading aloud. An address has exactly four parts:

The 32 characters of the data payload are not the 20 program bytes written out. base32 has an alphabet of 32 symbols, i.e. 5 bits per character, while the program is a sequence of 8-bit bytes. bech32 therefore re-groups the bit stream: it takes the 160 bits of the program and emits 160 ÷ 5 = 32 groups of 5 bits. No padding is needed here because 160 divides by 5 exactly; for a 32-byte program (Taproot) the division leaves a remainder, and the final word is padded with zero bits on the right.

Each 5-bit group indexes this alphabet (the same one Bitcoin uses everywhere in bech32):

Note which characters are absent: 1, b, i and o. They are missing because they are the characters people confuse when copying by hand or reading a screen (1/l, 0/o, b/6). The alphabet was chosen for human transcription, not for compactness.

The checksum is a BCH code computed by a 30-bit polynomial accumulator ("polymod") fed with hrpExpand(hrp) ‖ data ‖ 000000, XORed with the constant 1 for bech32, and split into 6 five-bit characters. Its published error-detection properties are the reason bech32 is trusted for money: it detects any error affecting at most four characters, and has a failure probability below 1 in 10⁹ for larger errors. Because the hrp is part of the input, changing bc to tb also invalidates the checksum — this page verifies both claims against the demo address by mutating it and re-decoding.

Case. bech32 strings must be either entirely lower case or entirely upper case. Mixed case is a hard failure, not a normalisation opportunity, because the two cases would otherwise encode the same program in two different strings. The canonical form on-chain and in wallets is lower case; upper case exists so that a QR code or a printed label can be transcribed without ambiguity.

5. Worked example — the real demo key

Everything below is what this page computes for the sample key, and every value in the results panel is recomputed live from your input.

Notice the testnet address: the data part is character-for-character identical, and only the hrp and therefore the checksum differ (naerk6 vs emzsdf).

6. Witness v0 requires bech32 — never bech32m

There are two checksum variants in use. bech32 (BIP173, constant 1) is for witness version 0; bech32m (BIP350, constant 0x2bc830a3 = 734539939 decimal) is for witness version 1 and above. The pairing is mandatory, and a decoder that does not enforce it will silently accept addresses that other nodes reject. This page's decoder enforces it, and you can watch it fail: re-encoding the demo address with the bech32m constant gives bc1qy86hkm0telzmvuvzm76279jp7z5p3yqjxpf0nc, which decodes to the error "Witness v0 must use bech32, not bech32m".

7. P2WPKH next to its neighbours

8. Where this fits in the chain

• Before it: private key → compressed public key, then hash160. The compressed key is not optional here.
• Sibling: P2PKH (same hash160, Base58Check instead of bech32) and P2SH-P2WPKH (the same program wrapped inside a P2SH address).
• After it: P2TR / Taproot uses the same key but a different program size, a different checksum variant and a key tweak.
• To take an address apart again: the bech32 decoder.

9. Security notes

• The address commits to a hash of the public key, not to the key itself. The key stays hidden until the output is spent — after which it is public forever, together with the address it funded.
• Reusing one address for many payments links them publicly and destroys the privacy of everyone who ever paid you. Derive a fresh address per payment (that is what HD wallets are for).
• The checksum protects against typos, not against a deliberately substituted address. Compare the first and last few characters on the sending device, and prefer QR codes over retyping.
• An address is not a secret, but it is also not a proof of ownership: whoever holds k can spend. Never paste a private key into a web page you do not fully trust — this page computes locally on the host you are talking to, and it never sends your key anywhere else.

10. Common mistakes

• Hashing the uncompressed key. Produces a different 20-byte program and a different address, unspendable under BIP143's compressed-key rule.
• Using bech32m for v0. Every modern wallet rejects it; only the length-extension weakness of the original checksum and 6 characters of it differ.
• Treating the separator as the first 1. Parsers must split at the last 1. The data charset has no 1, which makes this unambiguous.
• Lower-casing a QR payload by hand. All-upper is fine, mixed case is not; a converter that flips only some characters produces a string that no verifier will accept.
• Assuming "SegWit" means "the address starts with bc1". P2SH-P2WPKH is also SegWit and still starts with 3.

11. Quick reference