Private key → P2TR address (Taproot)

What this page computes

Input: one 256-bit private key. Output: the BIP86 key-path Taproot address, the string that starts with bc1p. Taproot is not "SegWit with a bigger program" — the public key is first adjusted by a hash-derived scalar, and that adjustment is what the address commits to:

Every intermediate value is printed in the result panel, including the parity decision, the two 32-byte hashes inside the tagged hash, and the tweaked point itself.

1. What Taproot set out to solve

Taproot is three proposals shipped together, activated on 14 November 2021:

Privacy. Before Taproot, a payment to a contract looked different on-chain: the output committed to a script hash, so an observer could see that something complicated was happening. Taproot makes the two indistinguishable. Every output looks like OP_1 <32 bytes>. If everyone in a multisig or a channel cooperates, they spend it with a single signature on the key path, and the blockchain shows exactly what an ordinary single-signature payment shows. Only if cooperation fails does a script path get revealed — and even then, only the one branch that was used.

Schnorr instead of ECDSA. Schnorr signatures (BIP340) are a fixed 64 bytes; ECDSA signatures are DER-encoded, vary between 70 and 72 bytes, and have a malleable encoding SegWit had to work around. More importantly, Schnorr is linear: a sum of signatures is a valid signature for the sum of keys. That property is what makes MuSig-style key aggregation, threshold signatures and batch verification possible without hacks.

2. x-only public keys: why BIP340 throws away y

An secp256k1 point has two coordinates, but for any x there are only two candidate points: P and −P = (x, p − y). One of them always has an even y. BIP340 defines the canonical interpretation of a 32-byte public key as "the point with that x and even y" — a function called lift_x. Dropping y saves a byte in every signature and removes an ambiguity that ECDSA carried around for years.

Two consequences matter in practice:

• If your private key k produces a point with odd y, the BIP340 signer uses n − k instead, since (n − k)·G = −P, the even-y representative of the same x. For k = 6 the point's y is ae12777a…6b075f297, which is odd, so the signer negates — yet the address is still bc1p4rsld9ryjhte00drc0r23r8ngd63xrzh5s4fvmy6q5yt70xzlsdqcuvtzv. Get this wrong and signatures fail to verify.
• Because the tweak below depends only on x, P and −P produce the same Taproot address — this page computes both and shows they match — while their legacy P2PKH addresses differ. x-only keys are not a compression trick; they are a different signing model.

3. The TapTweak construction, and why it is a tagged hash

An output key is never the raw public key you derived. It is that key plus a scalar multiple of the generator:

For a key-path-only address (BIP86) the merkle root is omitted entirely, so the input is just the 32-byte x-only internal key. The result Q is the output key, and only its x coordinate goes into the address. Nobody can tell from the address whether a script tree exists — the internal key absorbs that commitment.

A tagged hash is the BIP340 pattern for deriving specialised hashes from SHA-256:

The tag hash is prepended twice. That costs one extra compression block and buys domain separation: a hash computed for one purpose can never collide with a hash computed for another. Without it, an attacker could construct a value meaningful both as a signature nonce and as a TapTweak input — a cross-protocol attack surface that costs nothing to close. For the tag "TapTweak", SHA256("TapTweak") is e80fe1639c9ca050e3af1b39c143c63e429cbceb15d940fbb5c5a1f4af57c5e9.

4. Key path vs script path

There are two ways to spend a Taproot output.

• Key path. Provide one signature by the tweaked private key. The witness contains a single 64-byte (occasionally 65-byte) item. Nothing about scripts, branches or participants is revealed. This is the cheapest and most private option, and it is the only one this BIP86 page builds.
• Script path. Provide a leaf script, the data it needs, and a control block: the internal key plus the 32-byte sibling hashes that lead from that leaf to the Merkle root. The verifier recomputes the root, redoes the tweak and checks that the output key matches. Only the used leaf is revealed; every unused branch stays hidden — which a P2SH multisig cannot do, since it publishes the whole script.

This is why the page is key-path-only: it is what a single-key wallet (BIP86) does, and it is the only form where the address depends on nothing but the internal key. If you wanted a script path, the tweak would need the tree's Merkle root, giving a completely different tweak, a different output key and a different address. For scale: substituting a dummy 32-byte Merkle root of 1111…11 turns the demo key's tweak into 254264f6410f1b3890db1ee95ea9990b28875f4b3e06cf35dfd0d0a6dda6d04b instead of the real bae91685…85e8fa4d, so the address changes too.

5. bech32m, and why witness v1+ needs it

Taproot addresses use bech32m (BIP350): the same alphabet and structure as bech32, with a different checksum constant, 0x2bc830a3 (734539939) instead of 1. Witness v0 must use bech32; witness v1 and above must use bech32m.

The reason for the second variant is an insertion weakness in the original checksum, stated plainly in BIP350: whenever the final character of a bech32 string is p, inserting or deleting any number of q characters immediately before it does not invalidate the checksum. The checksum characters shift along, so the same six characters can validate strings whose data parts have different lengths — an ambiguity between "this address" and "that address" produced from one string. The server behind this page verified it: the valid address bc1qgey9e3xtk8fpdsgchch25saytdp6nlhdt9gm0p keeps a valid checksum after inserting one, two or three q characters before its final p (…gm0qp, …gm0qqp, …gm0qqqp). Across 78,624 single-character insertions attempted on bc-prefixed strings, every checksum-preserving insertion had exactly that shape, and all of them were bech32 strings — not one bech32m string accepted an insertion. The same experiment on a bech32m address ending in p fails the checksum outright, which is the whole point of the new constant.

Witness version 0 escaped the problem: its programs are restricted to exactly 20 or 32 bytes, so a decoder that enforces the structural rules rejects the mutated string. Witness v1+ has no such restriction, so BIP350 mandated the fixed constant for it.

6. The witness program and the address, byte by byte

A Taproot output script is 34 bytes: a version opcode, a 32-byte push, and the output key.

And the address that encodes it:

Decoding the demo address returns witver = 1, variant bech32m, and a 32-byte program identical to the output key in the results — a round trip, not an assumption.

7. Worked example — the real demo key

8. Taproot next to P2WPKH

9. Where this fits in the chain

• Before it: private key → compressed public key and P2WPKH, which uses the same key with a hashed 20-byte program.
• Related: secp256k1 point arithmetic for what P + t·G really means, and the bech32/bech32m decoder to take this address apart again.
• Wallets: BIP39 mnemonic → BIP32 child key — a BIP86 wallet derives m/86'/0'/0'/0/i and builds exactly this address.

10. Security notes

• The address commits to the tweaked key, so you cannot recognise your own Taproot address by looking at your public key alone. Always derive, never compare by eye.
• x-only means the y parity of your point may have to be negated before signing. If a wallet reports "signature verification failed" for a key that is definitely correct, check the parity handling.
• A script-path spend needs the internal key, the leaf script and the control block. Lose the control block and the branch is permanently unspendable; the key path is your backup, which is a good reason to keep a key path in any Taproot wallet.
• Reusing one Taproot address links payments exactly like any other address type does. Taproot hides scripts, not the fact that the same key was paid twice.

11. Common mistakes

• Tweaking with a tagged hash of the wrong tag. "TapTweak" is case-sensitive, and the tag is hashed twice. A single wrong character yields a valid-looking, useless address.
• Using the internal key as the address. The address commits to x(Q), not to x(P). Funds sent to an "address" built from the untweaked key are unspendable.
• Encoding v1 with bech32. Rejected by every compliant decoder; see the verified error messages above.
• Assuming Taproot hides the amount or the sender. It hides scripts, not amounts; the transaction graph stays public.
• Forgetting the version character. bc1p and bc1q differ by one character and describe different scripts; copy addresses, never retype them.

12. Quick reference