Private Keys vs Public Keys Explained

What is the difference between a private key and a public key?

Public-key cryptography creates an intentional asymmetry. One piece of information stays secret and authorises actions; another can be distributed widely and lets anyone check the resulting proof. Blockchains use that asymmetry to validate spending without asking a bank or account administrator to identify the customer.

The beginner shorthand - "public key receives, private key spends" - points in the right direction but is technically too broad. A public key normally verifies signatures; an address, output or account receives value. A private key may be the sole authority for a simple account, one signer in a multisignature policy, a share in a threshold system, or irrelevant to a contract address whose code defines control.

What exactly is a private key?

A private key is not a username, account password or support code. It is the secret mathematical input that allows a signer to create a proof matching a public key. Bitcoin and Ethereum use the secp256k1 elliptic curve for ordinary user signatures. A valid secp256k1 private key is a scalar in the curve group, commonly stored in 32 bytes. Ed25519 systems such as Solana commonly begin with a 32-byte secret seed and derive the signing scalar and public key according to EdDSA rules.

Descriptions such as "a random 256-bit number" are useful for secp256k1 but should not be treated as a universal wallet definition. Keys also appear in different encodings: hexadecimal, Wallet Import Format, encrypted keystores, hardware-backed key objects or non-exportable operating-system credentials. The encoding is a container or representation; the signing authority is the underlying secret.

Generation quality matters

The keyspace is enormous, but only if the wallet uses trustworthy randomness and correct cryptographic code. A human-chosen phrase, memorable number or improvised "brainwallet" has far less entropy and can be searched. BIP39 explicitly describes a way to transport computer-generated randomness; it is not a method for turning user-created sentences into secure wallets.

Signature implementations must also handle the per-message nonce correctly. In ECDSA, reusing or badly biasing that secret nonce can reveal the private key even when the long-term key was generated perfectly. Deterministic ECDSA procedures such as RFC 6979 reduce dependence on fresh random nonces, while implementations still need side-channel and fault protections.

A private key does not always equal the whole account

For a simple Ethereum externally owned account, possession of the key is sufficient to sign any transaction permitted by the protocol. For a Bitcoin output, the key is useful only if it satisfies the output script. A multisignature output may require several keys. An Ethereum contract account has no private key of its own; code determines which calls or signatures are accepted. A Solana program-derived address has no private key at all.

Takeaway: "Whoever has the private key has the funds" is accurate for a single-key account, but it is not a universal definition of blockchain ownership. The actual authority is whatever the account, output script or program validates.

What exactly is a public key?

In elliptic-curve cryptography, deriving the public key involves multiplying a standard curve point by the secret scalar. Forward computation is efficient. Recovering the scalar from the resulting point is the elliptic-curve discrete logarithm problem, which is computationally infeasible for properly chosen modern parameters using known classical methods. This one-way relationship is the security assumption behind ECDSA, Schnorr and EdDSA.

Public keys have several encodings. Bitcoin secp256k1 keys may appear as 33-byte compressed points, older 65-byte uncompressed points or 32-byte x-only keys for BIP340 Schnorr. Ethereum tools usually derive an uncompressed secp256k1 public key internally even though users interact with a 20-byte address. Solana Ed25519 public keys are 32 bytes and normally displayed in base58.

What a public key does not prove

A public key is not automatically a legal name or human identity. A signature proves control of the corresponding signing authority at the time of signing; it does not prove who physically held the device, whether malware initiated the request, whether the signer understood the payload or whether the key had been stolen. Identity comes from the surrounding system - certificates, account registration, social verification or other evidence - not from the bare keypair alone.

Is a wallet address the same as a public key?

The phrase "an address is a shortened public key" is an overgeneralisation. Addresses are designed for a network's account or output model, checksum and spending rules. Two addresses on the same chain can even represent different kinds of authority.

Bitcoin developer documentation often speaks generically about distributing public keys, while noting that wallets commonly distribute public-key hashes or script hashes instead. Ethereum distinguishes externally owned accounts from contract accounts. Solana explicitly supports both Ed25519 public-key addresses and off-curve program-derived addresses.

Address format is not enough

An address must be paired with the intended network, asset and, where required, memo or tag. The same hexadecimal EVM address can exist across several networks, but assets sent on the wrong network may not be accessible through the recipient's expected service. Address validity also does not prove ownership by the intended person: verify the destination through an independent channel.

How do digital signatures work - and what do they prove?

Digital signatures are the operational bridge between a secret key and a public blockchain. The signer does not transmit the private key. It transmits a signature and enough context for verifiers to reconstruct the signed payload and identify the relevant public key or address. NIST describes digital signatures as mechanisms for detecting unauthorised modification and authenticating a signatory under the key-management system around them.

Signing is not encryption

Most public blockchain transactions are visible. A signature authenticates a transaction; it does not conceal the amount, recipient or contract call. Some systems also use public-key cryptography for encryption or key agreement, but that is a separate operation with separate algorithms and assumptions.

A gas-free signature can still move value later

Wallets may sign off-chain messages such as token permits, marketplace orders, login challenges or typed-data authorisations. Some signatures merely authenticate a session; others authorise a third party or contract to spend assets later. The absence of a network fee at signing time does not make the request harmless. Read the domain, chain, spender, asset, amount, expiry and action before approving.

Where do crypto keys come from?

Early wallets generated and backed up many unrelated private keys. Hierarchical deterministic wallets changed the model: a root seed and chain code derive a tree of child keys. BIP32 standardised this approach for Bitcoin-compatible systems, including public-only branches that can generate receiving addresses without exposing spending keys.

Wallets then use derivation paths to separate accounts, networks, receiving addresses and change addresses. BIP44 and related standards define common conventions, but implementation choices still vary. A phrase restored into a different product may show an empty wallet until the correct derivation scheme, account index and network are selected.

Key generation should be verifiable and repeatable

The wallet should use a cryptographically secure random generator, preserve enough backup information and clearly explain recovery. Hardware wallets may generate and keep the secret inside a dedicated device. Mobile wallets may rely on operating-system secure storage. Threshold wallets may generate shares jointly so that no complete private key is ever assembled. These are different custody designs, not merely different interfaces.

Is a recovery phrase the same as a private key?

Calling the phrase "the private key in words" is memorable but technically misleading. A typical deterministic wallet contains many private keys. The phrase is a human-readable backup input for the root from which those keys are derived. BIP39 allows 12, 15, 18, 21 or 24 words depending on entropy size, although 12 and 24 are the common consumer formats. Not every wallet uses BIP39, and some custodial or smart-account systems expose no mnemonic at all.

Do not forget the optional passphrase

A BIP39 passphrase is sometimes marketed as a "25th word", but it can be any supported string and is not stored inside the mnemonic. Losing it can make the intended wallet unrecoverable even when the words are correct. Recording the words without the wallet type, passphrase policy and recovery instructions can therefore create a backup that looks complete but is not.

Does one wallet contain only one keypair?

A Bitcoin wallet often derives new receiving and change addresses to reduce address reuse and manage the UTXO model. Each address may correspond to a different child key or script. An Ethereum wallet commonly displays several externally owned accounts derived from one phrase, each with its own private key and address. A Solana wallet can manage multiple keypairs and token accounts. An exchange account may show a balance without giving the customer any blockchain private key at all.

Takeaway: Saying "my wallet has one private key" is often wrong. Security planning should identify every root secret, signer, device, backup and recovery path that can authorise or regenerate the wallet.

How do Bitcoin, Ethereum and Solana differ?

Ethereum after Pectra: delegation is not key replacement

EIP-7702 allows an Ethereum EOA to delegate execution to code, enabling smart-account-like features. The EOA private key nevertheless retains full authority and can replace or remove the delegation. Delegating an EOA to multisig-style code does not turn the underlying EOA key into a true threshold requirement.

Why algorithm names matter

ECDSA, Schnorr and EdDSA all produce digital signatures, but their encodings, nonce rules, aggregation properties and verification procedures differ. A key or signature for one scheme cannot be assumed compatible with another merely because both use 32-byte values. Network software decides exactly which algorithms and encodings are valid.

Is it safe to share a public key or wallet address?

Public keys exist to be public, and addresses exist to be distributed. Someone who knows your Bitcoin address, Ethereum address or Solana public key cannot simply compute the private key with today's classical computing methods. They can, however, observe public activity associated with that identifier and combine it with exchange records, social posts, domain names or leaked data.

What an address reveals depends on usage

A reused account-style address can expose a long transaction history and current token balances. Bitcoin wallets often generate fresh receive addresses, reducing straightforward reuse while still leaving graph-analysis links. Publishing an extended public key is much more revealing: it can allow an observer to derive an entire public branch and monitor many future addresses.

Receiving safely

• Share the address through a channel appropriate to the risk, and confirm high-value destinations independently.
• Specify the network and asset, not just the character string. The same EVM address can exist on multiple networks.
• Do not copy a repeat recipient from transaction history without checking; address-poisoning transfers are designed to plant lookalike entries.
• Verify the complete destination on a trusted display for high-value transfers. Checking only the first and last few characters is not enough against targeted lookalikes.
• Consider a test transaction when operationally appropriate, then confirm receipt through a separate channel before sending the balance.
• Avoid publicly linking large holdings to your legal name, home location or travel schedule.

What should you do if a private key or recovery phrase is exposed?

The response depends on what leaked. One child private key may compromise only the associated accounts, although reuse across chains and advanced HD relationships can broaden the damage. A recovery phrase normally compromises every account derived from it, including accounts not yet displayed. A signer key in a multisig or smart account may be replaceable if enough uncompromised signers remain.

Immediate response sequence

• Stop using the possibly compromised device or browser session. Do not follow recovery links sent by anyone who contacts you.
• On a clean device, initialise a new wallet or signer policy with fresh secret material. Verify the software, network and recovery backup independently.
• Move valuable assets or rotate the signer according to the account design. A compromised key creates a race; prioritise assets and native fee tokens carefully.
• For Ethereum token approvals, remember that revocation alone does not solve a leaked private key: the attacker can sign new transactions. Move authority or assets.
• Check every network on which the same key or phrase was used, including test accounts, Layer 2 networks and less-visible token balances.
• Preserve transaction hashes, addresses, messages and device evidence. Report theft promptly to relevant custodians, exchanges and law enforcement.
• Reject anyone promising guaranteed recovery for an upfront fee. Recovery scammers systematically target known victims.

What happens if a private key is lost?

The network does not know whether a key was lost, destroyed or intentionally abandoned. It only knows whether a valid authorisation is presented. Without one, the locked value remains part of the ledger indefinitely. This is why backup design is part of ownership rather than an optional convenience.

Succession and incapacity

A recovery plan should cover death, incapacity and loss - not only theft. The plan must give authorised people enough information to recover without creating an easy single target today. Depending on value and jurisdiction, that may involve multisignature, professional custody, sealed instructions, legal documentation or a carefully tested smart-account recovery policy. Technical recovery and legal entitlement are separate questions.

Can a private key be changed, split or replaced?

For practical wallet security, an independently generated replacement key has a different public key, and finding a different key that preserves a truncated address identifier is computationally infeasible under the intended security assumptions. For an ordinary single-key Bitcoin output or Ethereum EOA, key rotation therefore means transferring funds to a fresh destination. An upgradable smart-account policy may replace an authorised signer without changing the account address. A multisignature policy may require a transaction to establish a new signer set.

On-chain multisignature

The blockchain validates a policy requiring several independent signatures or contract approvals. The policy may be visible on-chain, although Taproot can hide unused script paths until spending. Multisig provides transparent rule enforcement and chain-specific recovery options, but it can cost more and expose operational structure.

Threshold signatures and MPC

A threshold protocol distributes signing shares so that a required subset cooperates to produce one ordinary signature. In a proper distributed-key-generation design, the complete private key never has to exist in one memory. The blockchain may see a normal signature rather than a multisig policy. Security then depends heavily on protocol choice, independent share environments and implementation quality.

Smart accounts and passkeys

Contract-based accounts can validate several signature schemes, passkeys, spending limits, sessions, guardians or delayed recovery. This can improve usability and key rotation, while adding code, upgrade and governance risks. A contract address is therefore controlled by policy, not by an inherent public-private keypair.

What do hardware wallets protect?

The strongest hardware-wallet benefit is separation. The computer or phone can prepare an unsigned transaction while the device holds the secret and performs signing internally. Even if the host is compromised, the attacker should still need the user to approve on the device. This only works when the user verifies the destination, amount, network and relevant contract permissions on the trusted screen.

Limits that matter

• Recovery phrase compromise bypasses the device. Anyone with the phrase can recreate the keys elsewhere.
• Blind or unreadable signing can authorise malicious approvals, permits or contract calls even when the key never leaves the device.
• A substituted destination on the computer can succeed if the user confirms it without checking the hardware display.
• Firmware, supply chain, physical access and backup procedures remain part of the threat model.
• A single hardware wallet plus one phrase can still be a single point of failure. Multisig or threshold designs address a different problem.
• No device protects against asset price risk, fraudulent counterparties, compromised smart contracts or a mistaken network choice.

Takeaway: Hardware isolation is valuable, but "keys stayed offline" is not the same as "the transaction was safe". The trusted display and the user's verification decision are part of the security boundary.

What do quantum computers mean for crypto keys?

NIST's FIPS 186-5 explicitly notes that its classical signature algorithms are not expected to resist a large-scale quantum computer. NIST has separately standardised post-quantum signatures including ML-DSA and SLH-DSA. These standards do not automatically upgrade a blockchain: each network needs compatible addresses, signature validation, wallet support and a migration path for existing funds.

The often-repeated claim that "unused addresses are quantum safe because only the hash is public" is not universally reliable. Address types differ; Taproot output keys and Solana signer public keys are visible, Ethereum public keys can often be recovered from signatures after use, and funds may be moved or exposed in different ways. Hashing can delay some forms of public-key exposure, but it is not a complete migration strategy.

What users should do now

• Do not panic or move funds to an unreviewed "quantum-safe" product marketed through urgency.
• Keep wallet software and signing devices supported so they can adopt future network migration tools.
• Avoid unnecessary address reuse where the network's wallet model recommends fresh addresses.
• Follow official protocol and wallet guidance if a migration is announced; verify destinations and deadlines independently.
• For long-lived institutional custody, include cryptographic agility and migration authority in governance planning.

Frequently asked questions

What is a private key in one sentence?

A private key is secret cryptographic material used to create signatures that satisfy an account or output's authorisation rules. It must remain secret because possession may be enough to move assets in a single-key design.

What is a public key in one sentence?

A public key is verification data derived from a private key. It lets anyone check matching signatures without learning the private key or gaining the ability to sign.

Is a wallet address the same as a public key?

Not generally. An address may encode a public key, a public-key hash, a script or witness program, a contract identifier, or a program-derived address. On Solana, a standard signer address is the public key itself; on Ethereum, contract addresses have no corresponding private key.

Can someone steal crypto with only my wallet address?

Normally no. An address grants no signing authority. It can reveal balances and transaction history, enable targeted scams or be used in address-poisoning attempts, so it is public but not always privacy-neutral.

Can someone calculate my private key from my public key?

Not with known practical classical methods when a secure supported curve and correct implementation are used. The problem is computationally infeasible at current security levels. A future large fault-tolerant quantum computer would change that assumption, which is why migration planning matters.

Is a seed phrase the same as a private key?

No. A recovery phrase normally encodes entropy used to derive a seed, and a deterministic wallet derives many private keys from that seed. The phrase is often more powerful than one raw private key because it can recreate the whole wallet hierarchy.

What is the difference between a wallet password and a private key?

A wallet password or PIN usually unlocks local software, decrypts a keystore or authorises a device. The private key is the blockchain signing authority. Forgetting a password may be recoverable with the wallet's backup; losing the only signing key is not.

Can I change my private key without changing my address?

Not for a conventional mathematical keypair. A different private key produces a different public key. A smart-contract wallet or other policy-controlled account may replace an authorised signer while retaining the same account address.

Why does my Bitcoin wallet generate a new address?

Hierarchical deterministic Bitcoin wallets derive many receive and change addresses from one root seed. Using fresh addresses reduces simple address reuse and helps the wallet manage separate UTXOs without requiring a new independent backup each time.

Should I share an extended public key?

Only with a trusted system when you understand the privacy consequences. An extended public key can allow monitoring and derivation of an entire public branch of addresses even though it normally cannot spend funds.

Does a hardware wallet store my coins?

No. The blockchain records the assets. A hardware wallet stores or protects signing material and approves transactions. Its recovery phrase or other backup can recreate the authority on another compatible device.

The bottom line

Private keys, public keys, addresses and recovery phrases are connected, but they are not interchangeable. The private key or signing share creates authority. The public key verifies it. The address identifies a network destination or spending condition. The recovery system regenerates or replaces the authority when the original device fails. Confusing these layers produces both bad explanations and expensive mistakes.

The durable security habit is to protect the whole signing system rather than one string. Generate keys with trusted software or hardware. Keep recovery material private and tested. Verify the exact transaction on a trusted display. Treat signatures as powerful authorisations, including off-chain ones. Use a custody model whose recovery and failure modes you actually understand.

Sources and further reading

Key references for this article, current as of July 2026.

• NIST FIPS 186-5 - Digital Signature Standard. https://csrc.nist.gov/pubs/fips/186-5/final
• Bitcoin Developer Guide - Wallets. https://developer.bitcoin.org/devguide/wallets.html
• Bitcoin Developer Guide - Transactions. https://developer.bitcoin.org/devguide/transactions.html
• BIP 340 - Schnorr Signatures for secp256k1. https://bips.dev/340/
• BIP 341 - Taproot: SegWit version 1 spending rules. https://bips.dev/341/
• BIP 32 - Hierarchical Deterministic Wallets. https://bips.dev/32/
• BIP 39 - Mnemonic code for generating deterministic keys. https://bips.dev/39/
• Ethereum.org - Ethereum accounts. https://ethereum.org/developers/docs/accounts/
• Ethereum.org - Security and scam prevention. https://ethereum.org/security/
• Ethereum.org - Pectra EIP-7702 guidelines. https://ethereum.org/roadmap/pectra/7702/
• Solana documentation - Account structure. https://solana.com/docs/core/accounts
• Solana documentation - Program Derived Addresses. https://solana.com/docs/core/pda
• RFC 8032 - Edwards-Curve Digital Signature Algorithm. https://www.rfc-editor.org/info/rfc8032/
• NIST FIPS 204 - Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final