Private key

A Bitcoin private key is a secret integer used to authorize spending under a Bitcoin public key. Wallet software uses a private key to create a digital signature; Bitcoin nodes verify the signature with the corresponding public key without learning the private key. Anyone who obtains a usable private key can normally authorize the same spending conditions as its legitimate controller, so the key must remain secret.

Private keys are not Bitcoin addresses. An address encodes information about a locking script or spending condition and is intended to be shared for receiving payments. Modern wallets may derive many keys and addresses from one protected seed, and some spending conditions require several keys rather than one.

Mathematical basis

Bitcoin uses the secp256k1 elliptic curve. A valid secret key is a 32-byte value interpreted as an integer from 1 through n−1, where n is the order of the curve's generator. The corresponding public key is calculated by elliptic-curve point multiplication. This operation is designed to be one-way: BIP 32 describes recovering the private key from a public key as requiring about 2¹²⁸ elliptic-curve operations under the assumed security of secp256k1.^[1]

Bitcoin historically used ECDSA signatures. Taproot outputs use the BIP 340 Schnorr signature scheme, which also uses secp256k1.^[2] A key's mathematical strength does not protect it from weak randomness, defective nonce generation, malware, side channels, or an unsafe backup procedure.

Generation and derivation

Wallets should generate keys with a cryptographically secure random-number generator or derive them using a reviewed deterministic-wallet scheme. BIP 32 defines hierarchical deterministic (HD) wallets, in which a root seed produces a tree of extended keys. An extended private key includes both key material and a chain code and can derive an entire branch, so exposing it may compromise many addresses rather than one.^[1]

Recovery words are not themselves ordinary private keys. In schemes such as BIP 39, wallet-generated entropy is encoded as a sequence of words and transformed into a seed, from which an HD wallet derives keys.^[3] A recovery phrase or root seed is therefore at least as sensitive as the derived private keys. Words chosen by a person are not a safe substitute for wallet-generated entropy; see Brainwallet.

Extended keys and derivation paths

An extended public key can derive and monitor a branch of non-hardened public keys without gaining ordinary spending authority. This is useful for watch-only wallets and receiving systems, but it also reveals transaction relationships and balances for that branch. Under BIP 32, disclosure of a non-hardened child private key together with its parent extended public key can reveal the parent private key; hardened derivation is designed to prevent that particular escalation.^[1]

A derivation path identifies where a key sits in an HD tree. A seed alone may be insufficient for straightforward recovery if the wallet type, derivation scheme, script type, accounts, or optional passphrase are unknown. Backups should therefore include the non-secret wallet metadata needed by the software's documented recovery process, without placing secret material in an online note.

Representations and wallet descriptions

A private key may be stored internally as 32 bytes. Legacy software can export a single key in Wallet Import Format (WIF), a Base58Check encoding that includes network and public-key-compression information. An extended private key has a different encoding, commonly beginning with an implementation-specific prefix such as xprv.

An encoding does not make a key safer. Hexadecimal, WIF, an extended private key, a QR code, a seed phrase, and a wallet backup can each disclose spending authority. This article deliberately provides no working private-key example, because examples are frequently copied, indexed, or mistakenly funded.

Output script descriptors provide a machine-readable description of how wallet scripts and keys are derived. A descriptor may contain only public information for a watch-only wallet or may contain private key material; the latter must be protected as a secret. Bitcoin Core's descriptor-wallet interface distinguishes public descriptors from descriptors returned with private material.^[4]

Importing, sweeping, and rescanning

Importing a private key adds it to a wallet so the wallet can monitor and spend relevant outputs. Sweeping creates a transaction that moves those outputs to a new key controlled by the receiving wallet. Behavior varies by wallet, script type, descriptor support, and rescan policy. A single imported key may not reconstruct related HD-wallet addresses or the original wallet's backup policy.

Do not paste a funded private key or recovery phrase into a website, block explorer, converter, support chat, AI prompt, or unfamiliar wallet. Follow the documentation of the wallet that created the backup. If a legacy key must be recovered, use trusted, current software on a controlled device and verify the destination wallet before moving funds.

Custody arrangements

Not every Bitcoin output is controlled by one private key. Common arrangements include:

single-signature custody, where one key can satisfy the spending condition;
multisignature custody, where a threshold of several keys is required;
hardware signing, where a device keeps key material isolated and signs approved transactions;
watch-only coordination, where an online system constructs and monitors transactions but a separate system signs them; and
threshold signing, where parties jointly create a signature without reconstructing one complete private key in one place.

These arrangements change the failure model, not the need for backups. A multisignature wallet can reduce dependence on one device, but recovery also requires the correct scripts or descriptors, key origins, threshold policy, and enough surviving signers. Complexity that is not tested can itself cause permanent loss.

Legacy key storage

Paper wallets and physical bitcoins often stored a single private key or encrypted private-key record. BIP 38 specified a passphrase-protected format using scrypt and AES for such records.^[5] These formats remain relevant when recovering historical funds, but they lack many properties of modern HD backups and can fail through printer compromise, unreadable media, weak passphrases, software incompatibility, or accidental reuse after a partial spend.

A passphrase protects only as well as its entropy and implementation. Encryption does not repair a key that was predictably generated, copied before encryption, or exposed while decrypted.

Security and storage

Common failure modes include:

malware, clipboard replacement, screenshots, logging, or cloud synchronization exposing a secret;
predictable or biased random-number generation;
a user-chosen phrase that can be guessed offline;
reuse of a key published in source code, documentation, puzzles, or websites;
loss, damage, or incomplete backups;
phishing that asks for a seed or key to “verify”, “synchronize”, “claim”, or “recover” a wallet; and
leaking an extended private key, or combining a non-hardened child private key with related extended-public-key data in an unsafe BIP 32 design.^[1]

A sound backup strategy depends on the wallet and threat model. Typical safeguards include using maintained wallet software, keeping offline backups in physically protected locations, testing recovery with non-sensitive or test data, and using hardware signing devices where appropriate. A backup should account for theft, physical damage, incapacity, inheritance, and software obsolescence without unnecessarily increasing the number of people or systems that can read the secret.

Suspected compromise

If a private key may have been exposed, treat it as compromised. On a trusted device, create a new wallet with fresh entropy, verify its backup, and move funds to a new receiving address. For a complex wallet or large amount, first establish which outputs and related keys may be affected and obtain qualified assistance without disclosing the secret. Do not reuse the old key after the transfer, and do not rely on deleting one copy: an attacker may already have retained it.

Private key, public key, and address

A private key creates signatures and must remain secret.
A public key lets nodes verify signatures and can be derived from the private key.
A Bitcoin address is a user-facing encoding related to a particular output script; it is not simply another name for a public key.
An extended key combines a key with a chain code for deterministic derivation and can represent an entire branch of a wallet.
A descriptor describes one or more output scripts and their key derivation; it may be public-only or may contain private material.

References

↑ ^1.0 ^1.1 ^1.2 ^1.3 BIP 32: Hierarchical Deterministic Wallets, “Conventions” and “Security”, accessed 27 August 2026.
↑ BIP 340: Schnorr Signatures for secp256k1, “Public Key Generation” and “Default Signing”, accessed 27 August 2026.
↑ BIP 39: Mnemonic code for generating deterministic keys, accessed 27 August 2026.
↑ Bitcoin Core 30.0 RPC: listdescriptors, accessed 27 August 2026.
↑ BIP 38: Passphrase-protected private key, accessed 27 August 2026.

[bip32-1] 1.0 ^1.1 ^1.2 ^1.3 BIP 32: Hierarchical Deterministic Wallets, “Conventions” and “Security”, accessed 27 August 2026.

[bip340-2] BIP 340: Schnorr Signatures for secp256k1, “Public Key Generation” and “Default Signing”, accessed 27 August 2026.

[bip39-3] BIP 39: Mnemonic code for generating deterministic keys, accessed 27 August 2026.

[core-listdescriptors-4] Bitcoin Core 30.0 RPC: listdescriptors, accessed 27 August 2026.

[bip38-5] BIP 38: Passphrase-protected private key, accessed 27 August 2026.

[1]

[2]

[3]

[4]

[5]