Every crypto wallet is a public-key cryptography engine wearing a friendly UI. Understanding what happens when you "sign a transaction" or "reveal your address" is not about memorizing math — it is about knowing which piece is a secret you protect, which piece is public information, and what the relationship between them actually proves.
The system is 50 years old, well-tested, and simpler than the terminology suggests.
Two keys, one relationship
Public-key cryptography rests on one fundamental idea: a matched pair of keys, where one is secret and one is public, and where messages can be signed with the secret one and verified with the public one, but not the reverse.
The pair is generated together. You generate a private key first (typically a large random number), and the public key is derived from it via a mathematical operation. The math is designed to be easy in one direction (private → public is a fast computation) but effectively impossible in reverse (public → private would require billions of years of computing).
For Bitcoin and Ethereum this operation is elliptic-curve multiplication on the secp256k1 curve. You do not need to know what that means — just know that public keys are derived, that the derivation is one-way, and that no one can compute your private key from your public key.
The private key: what it actually is
A Bitcoin private key is a random 256-bit number — think of it as a randomly-chosen integer between 1 and about 1.16 × 10^77. Any number in that range is a valid private key.
That is a genuinely enormous space. If every atom in the observable universe were a computer trying to guess private keys, they could try billions per second for the entire age of the universe and cover almost none of the space. This is why "brute forcing" a private key is not a real concern.
Private keys are usually written in a compact format — for Bitcoin, WIF (Wallet Import Format, starts with 5, K, or L). Ethereum uses hexadecimal (64 characters starting with 0x). Both encode the same underlying number.
Seed phrases (12 or 24 English words) are a way to encode a private key that humans can back up on paper. The BIP-39 standard defines how a seed phrase maps to a specific master key, from which many private keys can be derived deterministically. Your 12-word phrase is not itself a private key — it is a seed that generates all your keys.
The public key: what it actually is
The public key is a point on the elliptic curve. In practice, it is stored as either 33 bytes (compressed) or 65 bytes (uncompressed). Wallets show it in hex; you rarely see the raw public key because most workflows show you the address instead.
The public key can be shared freely. Someone with your public key can:
- Verify signatures you made with the corresponding private key
- Compute your Bitcoin address (which is a hash of the public key)
- Send you funds via that address
Nothing they can do reveals your private key or lets them spend your funds. That is the whole design.
Signatures: proving without revealing
A signature is proof that whoever created it knew the private key, without revealing the private key itself. When your wallet "signs a transaction," it uses your private key to produce a signature over the transaction data. The transaction plus the signature can then be verified by any node using only your public key — no private key ever leaves your wallet.
Signatures are transaction-specific. Signing "send 1 BTC to Bob" produces a signature that is valid only for that exact transaction; it cannot be reused to authorize any different transaction. This is why intercepting a signed transaction is useless — the attacker cannot modify it or repurpose it.
Signature schemes for crypto: Bitcoin used ECDSA (Elliptic Curve Digital Signature Algorithm) exclusively until Taproot added support for Schnorr signatures. Ethereum uses ECDSA. Both prove the same thing in slightly different ways; Schnorr is cleaner and enables multisig aggregation, which is why Taproot adopted it.
Addresses: a derived shorthand
A Bitcoin address is not the same as a public key. It is a shorter, checksummed hash of the public key, designed to be typed or scanned without error. The relationship: address = f(public_key) where f is a specific hash function plus formatting rules.
This layer of indirection has a subtle privacy benefit. When you receive Bitcoin to an address, the public key is not yet on the blockchain — only the address is. Someone knows you own that address, but they do not know your public key. The public key only becomes visible when you spend from that address, at which point the transaction includes the public key so nodes can verify the signature.
Address reuse means the public key stays visible on-chain, which weakens some future security properties (like quantum resistance). This is one of many reasons wallets always suggest a fresh address for each incoming payment.
What a wallet actually does
A software wallet is a collection of key pairs (usually derived from one seed) plus the ability to:
- Show you the addresses corresponding to your public keys
- Sign transactions with your private keys when you approve
- Broadcast signed transactions to the network
A hardware wallet does the same thing, except the private keys never leave the physical device — the device signs internally and returns only the signature. This is why hardware wallets are more secure: even a compromised computer cannot extract the private key from a hardware wallet.
A watch-only wallet has only public keys (or extended public keys). It can show balances and generate addresses but cannot sign. This is useful for monitoring cold storage without exposing signing capability.
What breaks the system
The math is not the weak point. In practice, private keys are compromised because:
- The seed phrase was written down insecurely, photographed, or entered into a phishing site.
- Malware on the computer intercepted the key when it was displayed or entered.
- A "random" number generator was not actually random and the key is predictable.
- The user was tricked into signing a malicious transaction that transferred funds away.
Every real crypto loss comes from one of these failure modes, not from an attacker breaking public-key cryptography itself. The math holds. The humans, hardware, and software around the math sometimes do not.
Why quantum computers scare people
Public-key cryptography today assumes that certain mathematical problems (discrete logarithms on elliptic curves, integer factorization) are computationally infeasible. A sufficiently large quantum computer running Shor's algorithm could solve these problems in polynomial time — meaning it could compute private keys from public keys.
The rescue plan: post-quantum cryptography, based on different math problems that are still hard for quantum computers. Bitcoin has not adopted any post-quantum scheme yet, partly because there is no consensus on which scheme is right, partly because sufficiently large quantum computers do not yet exist.
For addresses that have not spent (public key not revealed), you have address hashing as an extra layer of protection — a quantum attacker needs the public key, and they cannot compute a public key from just an address. For addresses that have spent, the public key is on-chain and vulnerable in principle.
This is a real but slow-moving concern. The threat model requires quantum computers that are 100-1000x more powerful than anything demonstrated in 2026. When they get closer, expect a coordinated migration to post-quantum signatures — Bitcoin's soft-fork process is well-suited to this.
For today: your keys are safe. Protect the seed phrase, use hardware wallets for meaningful funds, and generate fresh addresses. That is the practical security stack.
