A Bitcoin private key is a secret 256-bit number that authorizes spending. A public key is derived from it and enables signature verification. A Bitcoin address is a shorter, human-readable identifier derived from a public key, used for receiving payments. These three objects (private key, public key, address) form the cryptographic foundation every Bitcoin transaction depends on.
This guide explains what each object is, how they relate, where seed phrases and wallets fit in, and what security mistakes to avoid. It covers address formats, signature schemes, key derivation, and custody trade-offs. No cryptography math required.
What is a Bitcoin private key and what does it do?
A Bitcoin private key is a 256-bit randomly generated integer, displayed as a 64-character hexadecimal string. Its valid range runs from 1 to approximately 1.16 × 1077, close to but slightly less than 2256. That range is so large that the probability of any two wallets generating the same private key is negligible for practical purposes.
The private key's sole job is to produce digital signatures. When you spend bitcoin, your wallet uses your private key to sign the transaction. Every node on the network verifies that signature using only the corresponding public key; no one ever learns the private key itself.
Private keys are never stored on the blockchain. They exist only where you store them: inside wallet software, on a hardware device, on paper, or encoded in a seed phrase. If an attacker obtains your private key, they can spend every bitcoin locked to its associated addresses immediately. If you lose it with no backup, those funds are permanently inaccessible: there is no recovery mechanism, no customer support, no password reset.
What private key ownership really means in Bitcoin
The protocol does not record names. "Owning" bitcoin means controlling the private key that can satisfy the cryptographic spend conditions locked to specific unspent transaction outputs (UTXOs). Control equals cryptographic proof, nothing more.
WIF encoding
Private keys are sometimes exported from wallets in Wallet Import Format (WIF), a Base58Check-encoded representation designed for easier portability between wallets. WIF adds version byte and checksum information so the key survives copying errors. Importing a WIF-encoded key into a compatible wallet restores access to the addresses that key controls.
The probability argument in concrete terms
Brute-forcing a 256-bit private key means guessing one number from a set of roughly 1.16 × 1077 possibilities. Current global computing capacity could not exhaust even a tiny fraction of that space in any timeframe that matters. The security of Bitcoin private keys rests on this mathematical impossibility, not on legal protection or institutional gatekeeping.
What is a Bitcoin public key and how is it derived?
A Bitcoin public key is a point on the secp256k1 elliptic curve, computed by multiplying the private key integer by the curve's generator point G using elliptic curve multiplication. The result is a coordinate pair (x, y) where each coordinate is a 256-bit number.
Bitcoin chose secp256k1 (defined by the equation y² = x³ + 7 over a prime field) rather than the NIST P-256 curve used in many other cryptographic systems. Two reasons drove that choice. First, secp256k1's constants were selected in a predictable, non-random way that reduces the risk of a designer-inserted backdoor. Second, well-optimized secp256k1 implementations run more than 30% faster than equivalent NIST curve implementations (source: Bitcoin Wiki).
Elliptic curve multiplication is a one-way function: computing the public key from the private key is fast; reversing the process to derive a private key from a public key is computationally infeasible with any known algorithm. This asymmetry is the mathematical guarantee that makes Bitcoin ownership work.
Compressed vs uncompressed public keys
Public keys have two common representations:
Uncompressed (65 bytes, prefix 04): includes both x and y coordinates in full. Rarely used today.
Compressed (33 bytes, prefix 02 or 03): includes only the x coordinate. The prefix signals whether y is even (02) or odd (03), allowing the y coordinate to be recomputed from the curve equation. Compressed keys are the standard in modern wallets.
X-only (32 bytes, no prefix): used in Taproot (P2TR) outputs. Since Taproot assumes the y coordinate is always even, only the 32-byte x coordinate is stored, saving further space.
What the public key reveals
Having someone's public key does not allow spending their bitcoin. Spending requires producing a valid signature, which requires the private key. The public key's role is verification: it confirms that a signature was produced by whoever controls the matching private key.
On-chain visibility
In P2PKH (Legacy) transactions, the public key appears in the scriptSig when the output is spent. In P2WPKH (SegWit) transactions, it appears in the witness data. P2TR outputs expose only an x-only public key in the locking script. The practical implication: spending from an address reveals the public key on-chain for the first time. This is why address reuse is a privacy risk: once you spend, observers can link your public key to your transaction history.
xPub is not a public key
An extended public key (xPub) is a BIP-32 construct containing a public key plus a 256-bit chain code. From one xPub, anyone can derive every child address your wallet will ever generate for that derivation path. Sharing an xPub exposes your entire transaction history and total balance, even though it cannot be used to spend funds. Treat it as sensitive financial data.
What is a Bitcoin address and how does it differ from a public key?
A Bitcoin address is a receiving identifier, a shorter, human-readable label derived from a public key (or script hash) that you share with anyone sending you bitcoin. Addresses are not public keys, though they are derived from them.
Addresses do not store bitcoin. Bitcoin is recorded as UTXOs on the blockchain, locked by spending conditions. When someone sends bitcoin to your address, they create a UTXO with a locking script that your private key can satisfy.
The key-to-address derivation chain (P2PKH example):
Private key (256-bit integer)
Elliptic curve multiplication → compressed public key (33 bytes)
SHA-256 hash of the public key
RIPEMD-160 hash of the SHA-256 output → 20-byte public key hash
Prepend version byte (0x00 for mainnet P2PKH)
Double SHA-256 of the result → extract first 4 bytes as checksum
Append checksum → encode in Base58Check → address starting with 1
The RIPEMD-160 step produces a 160-bit hash, meaning addresses are shorter than public keys and include an error-detection checksum (source: Bitcoin Wiki).
Address formats and their prefixes:
Format | Prefix | Encoding | Script type | Notes |
|---|---|---|---|---|
Legacy (P2PKH) | 1 | Base58Check | Pay-to-pubkey-hash | Original format; highest fees |
P2SH | 3 | Base58Check | Pay-to-script-hash | Used for multisig and SegWit-wrapped |
Native SegWit (P2WPKH) | bc1q | Bech32 | Pay-to-witness-pubkey-hash | Lower fees; BIP-141 (2017) |
Taproot (P2TR) | bc1p | Bech32m | Pay-to-taproot | Lowest fees; most private; BIP-341 (Nov 2021) |
What changes across formats: Not ownership. Ownership is determined by control of the private key regardless of address format. What changes is transaction efficiency, fee cost, and compatibility. Taproot (bc1p) addresses use Schnorr signatures, support Merkelized script trees (MAST) for complex conditions, and make multisig outputs look identical to single-key outputs on-chain, a meaningful privacy improvement. SegWit (bc1q) addresses reduce transaction weight versus Legacy. Legacy (1) addresses have the widest compatibility but the highest fees.
Why wallets show new addresses. Modern wallets use HD derivation to generate a fresh address for each incoming payment. All these addresses derive from the same seed phrase; you manage one backup, not hundreds. Generating fresh addresses prevents blockchain analysts from clustering your transactions together by address.
How do Bitcoin digital signatures prove ownership without revealing the private key?
A digital signature is the proof that the holder of a specific private key authorized a specific transaction. Every Bitcoin node can verify a signature using only the public key and transaction data; the private key never leaves your device.
Common misconception: signatures do not encrypt the transaction. Bitcoin transactions are publicly visible on the blockchain. A signature proves authorization; it does not hide content.
The signing and verification process:
Your wallet constructs a transaction: which UTXOs to spend, recipient addresses, amounts, fee
Your wallet hashes the transaction data
Your private key, the transaction hash, and a random nonce are combined through the signing algorithm (ECDSA or Schnorr) to produce a signature
The transaction and signature are broadcast to the network
Every receiving node uses the public key and transaction hash to mathematically verify the signature is valid
Nodes reject any transaction with an invalid or missing signature
Signatures are transaction-specific. A signature created for one transaction cannot be reused for a different transaction, preventing replay attacks (source: Learn Me a Bitcoin).
ECDSA vs Schnorr signatures
Bitcoin originally used ECDSA (Elliptic Curve Digital Signature Algorithm) over secp256k1. The Taproot upgrade, activated at block 709,632 in November 2021, introduced Schnorr signatures via BIP-340 (source: Bitcoin Wiki).
Property | ECDSA | Schnorr (BIP-340) |
|---|---|---|
Signature size | 71-73 bytes (DER-encoded) | 64 bytes (fixed) |
Public key encoding in P2TR | N/A | 32-byte x-only |
Key aggregation | Not native | Native (MuSig2) |
Batch verification | Not supported | Supported |
Malleability | Possible | Non-malleable |
For users, the practical difference is that Taproot (bc1p) addresses use Schnorr signatures and benefit from smaller signatures, lower fees, and better privacy in multisig setups. Wallets handle the signature algorithm automatically; you do not choose at signing time.
Transaction signing vs message signing
Your wallet may offer both. Transaction signing authorizes spending UTXOs: funds move, and the action is irreversible once confirmed. Message signing proves you control an address to a third party (e.g., to verify ownership to a service) without spending anything. No funds move in message signing. A common scam: malicious actors present a transaction as a "message to sign." Always verify what you are signing before confirming.
How do seed phrases, HD wallets, and key derivation connect everything?
A seed phrase (typically 12 or 24 words) is not itself a private key. It is a human-readable encoding of a master secret, specified by BIP-39 (source: GitHub). From that master secret, an entire tree of private keys, public keys, and addresses can be derived deterministically.
The derivation hierarchy
Seed phrase (12-24 BIP-39 words)
↓ PBKDF2 (2048 rounds of HMAC-SHA512)
512-bit seed
↓ HMAC-SHA512
Master private key + master chain code
↓ BIP-32 HD derivation
Account-level extended keys (xprv / xpub)
↓
Individual private keys → public keys → addresses
Three BIP standards govern this process:
BIP-39: defines the word list and mnemonic-to-seed process. The standard 2048-word list ensures cross-wallet compatibility.
BIP-32: defines hierarchical deterministic (HD) derivation : how a master key generates child keys at any depth via derivation paths (e.g., m/44'/0'/0'/0/0).
BIP-44: standardizes the derivation path structure so wallets interoperate. A BIP-44 compliant wallet and a competing BIP-44 compliant wallet will derive identical addresses from the same seed phrase.
The critical consequence for backups
One seed phrase backs up everything. Every private key, every address your wallet ever derived: all recoverable from those 12 or 24 words. This is why a compromised seed phrase equals a total loss, and why losing it with no backup means those funds are gone permanently.
Passphrase (BIP-39 optional extension)
A passphrase is an optional additional word appended to the seed phrase before derivation. It produces an entirely different wallet, useful for plausible deniability or an extra security layer. A passphrase is not a PIN (a device-access number) and is not a seed phrase. Confusing them is a common source of wallet loss.
What does custody mean, and how does the key model differ across wallet types?
The private key/public key distinction has direct consequences for how you hold bitcoin depending on where your keys live.
Exchanges and services like Blofin operate on a different key-custody model than self-custody wallets: user funds are pooled in exchange-managed wallets where private keys are held by the operator, not the user. This is the structural reason exchange accounts are not the same as personal hardware wallets.
From a custodial perspective, the public-key/private-key distinction matters because most user-facing exchange features (deposits, withdrawals, trading) abstract the keys away, but the underlying responsibility split is what "not your keys, not your coins" captures.
Custody models and their trade-offs
Custody type | Who holds private keys | Recovery if provider fails | Access if device lost |
|---|---|---|---|
Exchange / custodial | Provider | Depends on provider's policies | Via account credentials |
Software wallet (hot) | You | Via seed phrase backup | Via seed phrase backup |
Hardware wallet (cold) | You (key generated offline) | Via seed phrase backup | Via seed phrase backup |
Multisig self-custody | Distributed across N keys | Requires M-of-N keys | Requires M-of-N keys |
Hot vs cold storage
Hot wallets (phone/desktop software) keep keys on internet-connected devices. Convenient for frequent transactions; exposed to malware, phishing, and device compromise. Hardware wallets keep private keys on an offline device; the key never touches an internet-connected environment. The hardware wallet signs transactions internally and only outputs the signed transaction, not the key. For amounts you cannot afford to lose, hardware storage is the appropriate tool. For more detail on the storage decision, see how to store bitcoin, hot wallet vs cold wallet, and what is a hardware wallet.
For self-custody decisions and what custodial arrangements mean for your control, see custodial wallet vs self-custody.
What is multisig and when does it help with key security?
Multisig (multi-signature) requires M signatures from a set of N designated private keys to authorize a transaction; for example, 2 of 3 keys. The mechanism is defined at the script level; a 2-of-3 multisig output locks funds so that any two of three specified keys must sign to spend.
Multisig addresses look like P2SH (3...) or, for modern setups, P2WSH (bc1q...) or P2TR (bc1p...). With Taproot, multiple-key arrangements can look identical to single-key spends on-chain, improving privacy for institutional setups.
When multisig helps:
Eliminates single point of failure: one compromised or lost key is not enough to lose funds or to steal them
Enables institutional controls: treasury funds requiring approval from multiple parties
Geographic redundancy: keys stored in separate physical locations
When multisig is not the right tool:
Small amounts where setup complexity exceeds risk
Beginners who have not mastered single-key backup discipline first
Situations where reliable access to all required signers cannot be guaranteed
For most beginners, a single hardware wallet with a properly backed-up seed phrase handles the risk adequately. For detailed multisig setup and use cases, see bitcoin multisig and air-gapped bitcoin signing.
How do keys appear inside a real Bitcoin transaction?
When someone sends bitcoin to your address, they create a UTXO with a locking script (scriptPubKey) encoding the spend conditions tied to your address. To spend that UTXO, you provide unlocking data proving you satisfy those conditions.
Conceptual transaction structure:
INPUT (spending a previous UTXO):
├── Reference: txid:abc123, output index 0
├── Unlocking data (scriptSig / witness):
│ ├── Signature (proves authorization, produced by private key)
│ └── Public key (enables verification)
│
OUTPUT (creating new UTXOs):
├── Amount: 0.1 BTC
├── Locking condition (scriptPubKey):
│ └── "Requires valid signature from key controlling bc1q..."
Network nodes verify the signature using only public information: the public key, the transaction data, and the signature itself. They never see the private key. This is trustless verification: anyone can confirm a transaction is valid independently.
The UTXO model means addresses do not have "balances" in the traditional sense. Bitcoin belonging to one person may be distributed across dozens of UTXOs locked to different addresses, all controlled by a single seed phrase. For more on how transactions are constructed and broadcast, see how Bitcoin transactions work and what UTXOs are.
What are the most common key-security mistakes and how do you avoid them?
Most Bitcoin losses come from preventable security failures, not cryptographic breaks. The threats are human and operational, not mathematical.
Never do:
Share your seed phrase with anyone, for any reason, through any channel
Type your seed phrase into a website (the only legitimate use of a seed phrase is in wallet recovery software from official sources)
Take a screenshot of your seed phrase or store it digitally
Store your seed phrase in cloud storage, email, notes apps, or password managers
Share your xPub with untrusted parties
Sign a transaction because "support" asked you to verify something
Assume you can reverse a confirmed Bitcoin transaction
Always do:
Write your seed phrase on paper or metal immediately on wallet setup; store in a physically separate secure location from your device
Test recovery with a small amount before transferring significant holdings
Verify recipient addresses character-by-character before sending; at minimum check first and last four characters
Send a small test transaction when using a new address or wallet for the first time
Use a hardware wallet for amounts material to your finances
Confirm whether you are signing a transaction or a message before approving any wallet prompt
The threat model split: Hot wallets face digital threats: malware, phishing, clipboard hijacking. Cold storage faces physical threats: device loss, physical theft, damage. Most users benefit from both: small routine amounts in a hot wallet, larger holdings on a hardware device with geographically distributed seed phrase backups.
For common attack patterns targeting key theft, see common Bitcoin scams and social engineering scams in crypto. For a full self-custody setup guide, see what is a seed phrase.
Frequently asked questions
Is a Bitcoin address the same as a public key?
No. A Bitcoin address is derived from a public key through a hashing process (SHA-256 followed by RIPEMD-160 for Legacy addresses). The resulting address is shorter, includes an error-detection checksum, and reveals less information than the full public key. For most address types, the public key is not visible on-chain until you spend from the address. Receiving bitcoin requires sharing your address, not your raw public key.
If someone knows my Bitcoin address, can they steal my funds?
No. Knowing an address lets someone see the balance and send bitcoin to it. Spending from an address requires producing a valid signature, which requires the private key. Sharing your address for receiving payments is safe and expected; it carries no spending risk.
What is the difference between a private key and a seed phrase?
A private key is a single 256-bit number controlling one set of addresses. A seed phrase (BIP-39) is a human-readable backup of a master secret from which many private keys are derived via BIP-32 HD derivation. One seed phrase regenerates your entire wallet: all keys, all addresses across all accounts. Losing your seed phrase means losing everything in that wallet with no recovery path.
Can two wallets generate the same private key?
Theoretically possible, but the probability is approximately 1 in 2256 (roughly 1 in 1077). In practice, Bitcoin's private key space is so large that a collision would not happen within any meaningful timeframe. The security of Bitcoin addresses depends on this mathematical improbability.
Why does my wallet generate a new address for each transaction?
To protect your privacy. Using the same address repeatedly allows blockchain analysts to cluster your transactions and estimate your total holdings. HD wallets (BIP-32/BIP-44) generate fresh addresses automatically; all derive from your single seed phrase, so there is no separate backup needed per address.
What is the difference between signing a transaction and signing a message?
Message signing proves you control a specific address to a third party; nothing spends, no funds move. Transaction signing authorizes the spending of UTXOs; funds transfer irreversibly once confirmed. A common scam involves asking users to "sign" something described as harmless that is actually a transaction. Always read the full wallet prompt before confirming any signature.
What happens if I lose my private key and have no seed phrase backup?
Your bitcoin is permanently inaccessible. Bitcoin has no backdoor, no account recovery process, no central authority that can restore access. This is by design: the same cryptographic properties that prevent unauthorized spending also mean no one can restore access for you. Back up your seed phrase before storing any meaningful amount.
What is xPub and why is it risky to share?
An xPub (extended public key, BIP-32) can derive all child public keys and addresses in a derivation path. Anyone with your xPub can compute every address your wallet has generated or will generate, track your complete transaction history, and calculate your balance. They cannot spend your funds without the corresponding private key. Still, sharing xPub is a serious privacy breach; treat it like bank statement access.
Do different address formats change who owns the bitcoin?
No. Ownership is determined by control of the private key regardless of address format. Legacy (1), P2SH (3), SegWit (bc1q), and Taproot (bc1p) addresses all represent different transaction script types offering different efficiency and fee trade-offs, but all require the private key to spend. Taproot offers the best efficiency and privacy of the four.
Does the blockchain store private keys?
No. The blockchain records transactions, UTXOs, and scripts. Private keys exist only where you store them: in wallet software, on a hardware device, or as a backed-up seed phrase. The blockchain has no private key data. If you lose your key and have no backup, the bitcoin remains locked on-chain forever with no mechanism to unlock it.
Why can't someone reverse-engineer a private key from a public key?
The security relies on the discrete logarithm problem on elliptic curves. Computing a public key from a private key (multiplying an integer by the curve's generator point) is fast. Reversing that process, finding the integer given only the result, has no known efficient algorithm. On secp256k1, this is computationally infeasible with any plausible amount of classical computing power Bitcoin Wiki.
Key relationships at a glance
Object | Size | Created by | Purpose | Safe to share? |
|---|---|---|---|---|
Private key | 256 bits | Random generation | Signs transactions | Never |
Public key | 33 bytes (compressed) | Derived from private key | Verifies signatures | Generally yes, with privacy caution |
Address | 20-34 characters | Derived from public key | Receives bitcoin | Yes |
xPub | Extended key | Derived from master key | Derives child addresses | No (privacy leak) |
Seed phrase | 12-24 words | BIP-39 | Recovers entire wallet | Never |
Signature | 64-72 bytes | Created by private key | Authorizes spending | Automatically public on-chain |
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. All facts independently verified.
Disclaimer: This content is for educational purposes only and does not constitute financial, investment, legal, or tax advice. Crypto assets are highly volatile and carry significant risk of loss. Always verify local regulations and consult a qualified professional before making financial decisions.