Bitcoin Key & Address Explorer
Explore Bitcoin's cryptographic foundations. See how private keys, public keys, and addresses are derived. Educational tool for understanding Bitcoin's key hierarchy.
Explore Bitcoin's cryptographic foundations.
See how private keys, public keys, and addresses relate to each other — visually.
This educational tool demonstrates the structure and format of Bitcoin's key and address types. Generate random example values to see how each step in the derivation chain transforms data — from raw entropy to the addresses you use every day.
For Educational Purposes Only
Never use keys shown on any website for real funds. This tool demonstrates the structure and format of Bitcoin keys and addresses, not actual cryptographic derivation. The values generated here are random examples meant to illustrate correct prefixes, lengths, and encoding formats. Real key derivation requires secure offline software.
Key & Address Explorer
Click the button below to generate a new set of random example values. Each generation uses the Web Crypto API for random bytes, then formats them to match Bitcoin's real key and address structures.
Private Key (Raw)
Random 256-bit number (32 bytes)
--
64 hex characters = 256 bits of entropy, generated via crypto.getRandomValues()
Wallet Import Format (WIF)
Base58Check-encoded private key
--
Structure: Version byte (0x80) + private key bytes + compression flag (0x01) + 4-byte checksum. The checksum is the first 4 bytes of SHA-256(SHA-256(payload)). The result is then Base58-encoded. Compressed WIF keys start with K or L; uncompressed start with 5.
Note The example above shows the correct format structure. Actual WIF conversion requires Base58Check encoding with SHA-256 double hashing.
Compressed Public Key
33 bytes via secp256k1 elliptic curve multiplication
--
Derivation: The public key is computed as P = k * G where k is the private key and G is the secp256k1 generator point. Compressed format uses prefix 02 (even y) or 03 (odd y) followed by the 32-byte x-coordinate. This is a one-way function — you cannot derive the private key from the public key.
Address Formats
Different encodings of the public key hash
--
Starts with 1 | ~25-34 chars | Base58Check(0x00 + RIPEMD160(SHA256(pubkey)) + checksum)
--
Starts with 3 | ~25-34 chars | Base58Check(0x05 + RIPEMD160(SHA256(script)) + checksum)
--
Starts with bc1q | ~42 chars | Bech32(hrp + witness version 0 + 20-byte keyhash)
--
Starts with bc1p | ~62 chars | Bech32m(hrp + witness version 1 + 32-byte tweaked pubkey)
Derivation Flow Diagram
The diagram below shows the complete chain from random entropy to Bitcoin addresses. Each transformation is a one-way cryptographic operation — you can always go forward but never backward.
Random 256-bit Number
Private Key (Hex)
WIF Format
Base58Check encoding
Version + Key + Flag + Checksum
Public Key
secp256k1 (k * G)
RIPEMD160(SHA256(pubkey))
20-byte hash
P2PKH
1...
P2SH
3...
SegWit
bc1q...
Taproot
bc1p...
Understanding Elliptic Curve Cryptography
Bitcoin uses the secp256k1 elliptic curve, defined by the equation y² = x³ + 7 over a finite field. This specific curve was chosen for its efficiency and lack of known backdoors — unlike some NIST curves that have raised concerns in the cryptographic community.
Point Multiplication
A private key k is multiplied with the generator point G to produce the public key P = k * G. This uses repeated point addition on the elliptic curve. The operation is computationally easy in one direction but infeasible to reverse — this is the Elliptic Curve Discrete Logarithm Problem (ECDLP).
Key Space Size
The secp256k1 curve has an order of approximately 2256 — roughly 1.16 x 1077 possible private keys. For context, the estimated number of atoms in the observable universe is about 1080. Brute-forcing a private key is computationally impossible with current or foreseeable technology.
Compressed vs Uncompressed
An elliptic curve point has both x and y coordinates (64 bytes uncompressed). Since y can be derived from x using the curve equation, compressed keys store only x plus a prefix byte indicating y's parity — reducing size from 65 to 33 bytes. Modern Bitcoin exclusively uses compressed public keys.
Schnorr Signatures (Taproot)
Taproot introduced Schnorr signatures (BIP 340), which offer several advantages over ECDSA: they are provably secure, enable efficient multi-signature aggregation, and make complex spending conditions indistinguishable from simple ones on-chain — significantly improving privacy and reducing fees.
Private Key Formats Explained
A Bitcoin private key is fundamentally just a 256-bit number, but it can be represented in several formats. Each format serves a different purpose — from raw computation to human-readable import/export.
| Format | Prefix | Length | Description |
|---|---|---|---|
| Raw Hex | — | 64 chars | Plain hexadecimal, 32 bytes |
| WIF (Uncompressed) | 5 | 51 chars | Base58Check, no compression flag |
| WIF (Compressed) Recommended | K or L | 52 chars | Base58Check, with 0x01 compression flag |
| Mini Private Key | S | 30 chars | Compact format, used in physical coins |
Address Encoding: Base58Check vs Bech32
Bitcoin uses two fundamentally different encoding schemes for addresses. Understanding the difference explains why address formats look so different and why newer formats are considered superior.
- Uses Base58 alphabet: 1-9, A-Z, a-z, excluding 0, O, I, l to avoid visual ambiguity
- 4-byte checksum from double SHA-256 hash appended to payload
- Case-sensitive (mixed case), making QR codes less efficient
- Version byte determines prefix: 0x00 = "1...", 0x05 = "3..."
- Can detect errors but cannot identify which character is wrong
- Uses 32-character lowercase alphabet: a-z excluding b, i, o + digits 0-9 excluding 1
- BCH error-correcting code can detect up to 4 character errors and locate them
- Lowercase only — more efficient QR codes (alphanumeric mode)
- Human-readable part (bc) + separator (1) + data + 6-char checksum
- Bech32m (BIP 350) fixes a length-extension mutability issue in original Bech32
Why Do Different Address Types Exist?
Bitcoin's address format evolution reflects years of protocol improvements, each solving specific limitations while maintaining backward compatibility with the entire network.
P2PKH — The Original
Introduced with Bitcoin itself. Pay-to-Public-Key-Hash adds a layer of security by hashing the public key before use in the address. If ECDSA is ever broken, funds in P2PKH addresses where the public key hasn't been revealed remain protected by the hash function.
P2SH — Programmable Scripts
BIP 16 introduced Pay-to-Script-Hash, allowing complex spending conditions (multi-signature, time-locks) while keeping the address simple. The sender doesn't need to know the script — they just send to a "3..." address. Later became the wrapper for SegWit compatibility.
Bech32 — Segregated Witness
The SegWit upgrade (BIP 141/173) separated signature data from transaction data, fixing transaction malleability and enabling the Lightning Network. Native SegWit addresses use Bech32 encoding, reducing transaction weight by ~30-40% and lowering fees accordingly.
Bech32m — Taproot
The Taproot upgrade (BIP 340/341/342) introduced Schnorr signatures, MAST (Merkelized Alternative Script Trees), and improved privacy. Complex multi-signature transactions become indistinguishable from simple payments on-chain. Uses Bech32m encoding (BIP 350) to fix a subtle checksum issue in the original Bech32.
Frequently Asked Questions
What is the relationship between a private key and a public key?
Why does WIF format start with 5, K, or L?
Can someone guess my private key?
What is the difference between Bech32 and Bech32m?
Why does Bitcoin hash the public key instead of using it directly?
Is this tool safe to use? Are the generated values real?
Put Your Knowledge to Work
Now that you understand how Bitcoin keys and addresses work, start mining with NoxHash. We handle the cryptography — you collect the rewards. Secure key management, instant withdrawals to any address format.