---
title: Wallets
description: "# Wallets A Bitcoin [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) can refer to either a [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program or a [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) file. ## Introductions [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs create public keys to receive [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) and use the corresponding private keys to spend those [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/). [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) files store private…"
url: "https://bitcoindevelopers.org/docs/developer-guides/wallets/"
updated: "2025-05-13"
category: Developer Guides
---

# Wallets

# Wallets

A Bitcoin [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) can refer to either a [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program or a [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) file.

## Introductions

[Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs create public keys to receive [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) and use the corresponding private keys to spend those [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/). [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) files store private keys and (optionally) other information related to transactions for the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program.

[Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs and [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) files are addressed below in separate subsections, and this document attempts to always make it clear whether we’re talking about [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs or [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) files.

## [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) Programs

Permitting receiving and spending of [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) is the only essential feature of [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software—but a particular [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program doesn’t need to do both things. Two [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs can work together, one program distributing public keys in order to receive [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) and another program signing transactions spending those [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/).

[Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs also need to interact with the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network to get information from the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain and to broadcast new transactions. However, the programs which distribute public keys or sign transactions don’t need to interact with the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network themselves.

This leaves us with three necessary, but separable, parts of a [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) system: a [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) distribution program, a signing program, and a networked program. In the subsections below, we will describe common combinations of these parts.

Note: we speak about distributing public keys generically. In many cases, P2PKH or P2SH hashes will be distributed instead of public keys, with the actual public keys only being distributed when the outputs they control are spent.

### Full-Service Wallets

The simplest [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is a program which performs all three functions: it generates private keys, derives the corresponding public keys, helps distribute those public keys as necessary, monitors for outputs spent to those public keys, creates and signs transactions spending those outputs, and broadcasts the signed transactions.

  ![Full-Service Wallets](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-wallets-full-service.svg)

Full-Service Wallets

As of this writing, almost all popular wallets can be used as full-service wallets.

The main advantage of full-service wallets is that they are easy to use. A single program does everything the user needs to receive and spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/).

The main disadvantage of full-service wallets is that they store the private keys on a device connected to the Internet. The compromise of such devices is a common occurrence, and an Internet connection makes it easy to transmit private keys from a compromised device to an attacker.

To help protect against theft, many [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs offer users the option of encrypting the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) files which contain the private keys. This protects the private keys when they aren’t being used, but it cannot protect against an attack designed to capture the encryption key or to read the decrypted keys from memory.

### Signing-Only Wallets

To increase security, private keys can be generated and stored by a separate [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program operating in a more secure environment. These signing-only wallets work in conjunction with a networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) which interacts with the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network.

Signing-only wallets programs typically use deterministic key creation (described in a later subsection) to create parent private and public keys which can create child private and public keys.

  ![Signing-Only Wallets](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-wallets-signing-only.svg)

Signing-Only Wallets

When first run, the signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) creates a [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) and transfers the corresponding parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to the networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

The networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) uses the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to derive child public keys, optionally helps distribute them, monitors for outputs spent to those public keys, creates unsigned transactions spending those outputs, and transfers the unsigned transactions to the signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

Often, users are given a chance to review the unsigned transactions’ details (particularly the [Output](https://bitcoindevelopers.org/encyclopedia/output/) details) using the signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

After the optional review step, the signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) uses the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) to derive the appropriate child private keys and signs the transactions, giving the signed transactions back to the networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

The networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) then broadcasts the signed transactions to the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network.

The following subsections describe the two most common variants of signing-only wallets: offline wallets and hardware wallets.

#### Offline Wallets

Several full-service wallets programs will also operate as two separate wallets: one program instance acting as a signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) (often called an “offline [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/)”) and the other program instance acting as the networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) (often called an “online [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/)” or “watching-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/)”).

The offline [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is so named because it is intended to be run on a device which does not connect to any network, greatly reducing the number of attack vectors. If this is the case, it is usually up to the user to handle all data transfer using removable media such as USB drives. The user’s workflow is something like:

1. (Offline) Disable all network connections on a device and install the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software. Start the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software in offline mode to create the parent private and public keys. Copy the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to removable media.
2. (Online) Install the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software on another device, this one connected to the Internet, and import the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) from the removable media. As you would with a full-service [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/), distribute public keys to receive payment. When ready to spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/), fill in the [Output](https://bitcoindevelopers.org/encyclopedia/output/) details and save the unsigned transaction generated by the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) to removable media.
3. (Offline) Open the unsigned transaction in the offline instance, review the [Output](https://bitcoindevelopers.org/encyclopedia/output/) details to make sure they spend the correct amount to the correct [Address](https://bitcoindevelopers.org/encyclopedia/address/). This prevents malware on the online [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) from tricking the user into signing a transaction which pays an attacker. After review, sign the transaction and save it to removable media.
4. (Online) Open the signed transaction in the online instance so it can broadcast it to the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network.

The primary advantage of offline wallets is their possibility for greatly improved security over full-service wallets. As long as the offline [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is not compromised (or flawed) and the user reviews all outgoing transactions before signing, the user’s [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are safe even if the online [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is compromised.

The primary disadvantage of offline wallets is hassle. For maximum security, they require the user dedicate a device to only offline tasks. The offline device must be booted up whenever funds are to be spent, and the user must physically copy data from the online device to the offline device and back.

#### Hardware Wallets

Hardware wallets are devices dedicated to running a signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/). Their dedication lets them eliminate many of the vulnerabilities present in operating systems designed for general use, allowing them to safely communicate directly with other devices so users don’t need to transfer data manually. The user’s workflow is something like:

1. (Hardware) Create parent private and public keys. Connect hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) to a networked device so it can get the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/).
2. (Networked) As you would with a full-service [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/), distribute public keys to receive payment. When ready to spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/), fill in the transaction details, connect the hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/), and click Spend. The networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) will automatically send the transaction details to the hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).
3. (Hardware) Review the transaction details on the hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/)’s screen. Some hardware wallets may prompt for a passphrase or PIN number. The hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) signs the transaction and uploads it to the networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).
4. (Networked) The networked [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) receives the signed transaction from the hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) and broadcasts it to the network.

The primary advantage of hardware wallets is their possibility for greatly improved security over full-service wallets with much less hassle than offline wallets.

The primary disadvantage of hardware wallets is their hassle. Even though the hassle is less than that of offline wallets, the user must still purchase a hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) device and carry it with them whenever they need to make a transaction using the signing-only [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

An additional (hopefully temporary) disadvantage is that, as of this writing, very few popular [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs support hardware wallets—although almost all popular [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs have announced their intention to support at least one model of hardware [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/).

### Distributing-Only Wallets

[Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs which run in difficult-to-secure environments, such as webservers, can be designed to distribute public keys (including P2PKH or P2SH addresses) and nothing more. There are two common ways to design these minimalist wallets:

  ![Distributing-Only Wallets](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-wallets-distributing-only.svg)

Distributing-Only Wallets

- Pre-populate a database with a number of public keys or addresses, and then distribute on request a [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) or [Address](https://bitcoindevelopers.org/encyclopedia/address/) using one of the database entries. To avoid key reuse, webservers should keep track of used keys and never run out of public keys. This can be made easier by using parent public keys as suggested in the next method.
- Use a parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to create child public keys. To avoid key reuse, a method must be used to ensure the same [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) isn’t distributed twice. This can be a database entry for each key distributed or an incrementing pointer to the [Key index](https://bitcoindevelopers.org/encyclopedia/key-index/) number.

Neither method adds a significant amount of overhead, especially if a database is used anyway to associate each incoming payment with a separate [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) for payment tracking. See the Payment Processing section for details.

## [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) Files

Bitcoin wallets at their core are a collection of private keys. These collections are stored digitally in a file, or can even be physically stored on pieces of paper.

### [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) Formats

Private keys are what are used to unlock [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) from a particular [Address](https://bitcoindevelopers.org/encyclopedia/address/). In Bitcoin, a [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) in standard format is simply a 256-bit number, between the values:

0x01 and 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4140, representing nearly the entire range of 2256-1 values. The range is governed by the secp256k1 ECDSA encryption standard used by Bitcoin.

#### [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) Import Format ([WIF](https://bitcoindevelopers.org/encyclopedia/wif/))

In order to make copying of private keys less prone to error, [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) Import Format may be utilized. [WIF](https://bitcoindevelopers.org/encyclopedia/wif/) uses [Base58check](https://bitcoindevelopers.org/encyclopedia/base58check/) encoding on a [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/), greatly decreasing the chance of copying error, much like standard Bitcoin addresses.

1. Take a [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/).
2. Add a 0x80 byte in front of it for [Mainnet](https://bitcoindevelopers.org/encyclopedia/mainnet/) addresses or 0xef for [Testnet](https://bitcoindevelopers.org/encyclopedia/testnet/) addresses.
3. Append a 0x01 byte after it if it should be used with compressed public keys (described in a later subsection). Nothing is appended if it is used with uncompressed public keys.
4. Perform a SHA-256 hash on the [Extended key](https://bitcoindevelopers.org/encyclopedia/extended-key/).
5. Perform a SHA-256 hash on result of SHA-256 hash.
6. Take the first four bytes of the second SHA-256 hash; this is the checksum.
7. Add the four checksum bytes from point 5 at the end of the [Extended key](https://bitcoindevelopers.org/encyclopedia/extended-key/) from point 2.
8. Convert the result from a byte string into a Base58 string using [Base58check](https://bitcoindevelopers.org/encyclopedia/base58check/) encoding.

The process is easily reversible, using the Base58 decoding function, and removing the padding.

#### Mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) Format

Mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) format is a method for encoding a [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) in under 30 characters, enabling keys to be embedded in a small physical space, such as physical bitcoin tokens, and more damage-resistant QR codes.

1. The first character of mini keys is ‘S’.
2. In order to determine if a mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) is well-formatted, a question mark is added to the [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/).
3. The SHA256 hash is calculated. If the first byte produced is a `00’, it is well-formatted. This key restriction acts as a typo-checking mechanism. A user brute forces the process using random numbers until a well-formatted mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) is produced.
4. In order to derive the full [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/), the user simply takes a single SHA256 hash of the original mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/). This process is one-way: it is intractable to compute the mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) format from the derived key.

Many implementations disallow the character ‘1’ in the mini [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) due to its visual similarity to ‘l’.

**Resource:** A common tool to create and redeem these keys is the Casascius Bitcoin [Address](https://bitcoindevelopers.org/encyclopedia/address/) Utility.

### [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Formats

Bitcoin ECDSA public keys represent a point on a particular Elliptic Curve (EC) defined in secp256k1. In their traditional uncompressed form, public keys contain an identification byte, a 32-byte X coordinate, and a 32-byte Y coordinate. The extremely simplified illustration below shows such a point on the elliptic curve used by Bitcoin, y2 = x3 + 7, over a field of contiguous numbers.

  ![Point On ECDSA Curve](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ecdsa-compressed-public-key.svg)

Point On ECDSA Curve

(Secp256k1 actually modulos coordinates by a large prime, which produces a field of non-contiguous integers and a significantly less clear plot, although the principles are the same.)

An almost 50% reduction in [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) size can be realized without changing any fundamentals by dropping the Y coordinate. This is possible because only two points along the curve share any particular X coordinate, so the 32-byte Y coordinate can be replaced with a single bit indicating whether the point is on what appears in the illustration as the “top” side or the “bottom” side.

No data is lost by creating these compressed public keys—only a small amount of CPU is necessary to reconstruct the Y coordinate and access the uncompressed [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). Both uncompressed and compressed public keys are described in official secp256k1 documentation and supported by default in the widely-used OpenSSL library.

Because they’re easy to use, and because they reduce almost by half the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain space used to store public keys for every spent [Output](https://bitcoindevelopers.org/encyclopedia/output/), compressed public keys are the default in Bitcoin Core and are the recommended default for all Bitcoin software.

However, Bitcoin Core prior to 0.6 used uncompressed keys. This creates a few complications, as the hashed form of an uncompressed key is different than the hashed form of a compressed key, so the same key works with two different P2PKH addresses. This also means that the key must be submitted in the correct format in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script so it matches the hash in the previous [Output](https://bitcoindevelopers.org/encyclopedia/output/)’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/).

For this reason, Bitcoin Core uses several different identifier bytes to help programs identify how keys should be used:

- Private keys meant to be used with compressed public keys have 0x01 appended to them before being Base-58 encoded. (See the [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) encoding section above.)
- Uncompressed public keys start with 0x04; compressed public keys begin with 0x03 or 0x02 depending on whether they’re greater or less than the midpoint of the curve. These prefix bytes are all used in official secp256k1 documentation.

### Hierarchical Deterministic Key Creation

The hierarchical deterministic key creation and transfer protocol ([HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/)) greatly simplifies [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) backups, eliminates the need for repeated communication between multiple programs using the same [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/), permits creation of child accounts which can operate independently, gives each parent account the ability to monitor or control its children even if the child account is compromised, and divides each account into full-access and restricted-access parts so untrusted users or programs can be allowed to receive or monitor payments without being able to spend them.

The [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) takes advantage of the ECDSA [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) creation function, “point()”, which takes a large integer (the [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/)) and turns it into a graph point (the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/)):

```
point(private_key) == public_key
```

Because of the way “point()” works, it’s possible to create a child [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) by combining an existing (parent) [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) with another [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) created from any integer (*i*) value. This child [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) is the same [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) which would be created by the “point()” function if you added the *i* value to the original (parent) [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) and then found the remainder of that sum divided by a global constant used by all Bitcoin software (*p*):

```
point( (parent_private_key + i) % p ) == parent_public_key + point(i)
```

This means that two or more independent programs which agree on a sequence of integers can create a series of unique [Child key](https://bitcoindevelopers.org/encyclopedia/child-key/) pairs from a single [Parent key](https://bitcoindevelopers.org/encyclopedia/parent-key/) pair without any further communication. Moreover, the program which distributes new public keys for receiving payment can do so without any access to the private keys, allowing the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) distribution program to run on a possibly-insecure platform such as a public web server.

Child public keys can also create their own child public keys (grandchild public keys) by repeating the [Child key](https://bitcoindevelopers.org/encyclopedia/child-key/) derivation operations:

```
point( (child_private_key + i) % p ) == child_public_key + point(i)
```

Whether creating child public keys or further-descended public keys, a predictable sequence of integer values would be no better than using a single [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) for all transactions, as anyone who knew one child [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) could find all of the other child public keys created from the same parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). Instead, a random seed can be used to deterministically generate the sequence of integer values so that the relationship between the child public keys is invisible to anyone without that seed.

The [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) uses a single [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/) to create a hierarchy of child, grandchild, and other descended keys with unlinkable deterministically-generated integer values. Each [Child key](https://bitcoindevelopers.org/encyclopedia/child-key/) also gets a deterministically-generated seed from its parent, called a [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), so the compromising of one [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) doesn’t necessarily compromise the integer sequence for the whole hierarchy, allowing the master [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) to continue being useful even if, for example, a web-based [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) distribution program gets hacked.

  ![Overview Of Hierarchical Deterministic Key Derivation](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hd-overview.svg)

Overview Of Hierarchical Deterministic Key Derivation

As illustrated above, HD key derivation takes four inputs:

- The [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) and *parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/)* are regular uncompressed 256-bit ECDSA keys.
- The parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) is 256 bits of seemingly-random data.
- The index number is a 32-bit integer specified by the program.

In the normal form shown in the above illustration, the parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/), and the index number are fed into a one-way cryptographic hash (HMAC-SHA512) to produce 512 bits of deterministically-generated-but-seemingly-random data. The seemingly-random 256 bits on the righthand side of the hash [Output](https://bitcoindevelopers.org/encyclopedia/output/) are used as a new child [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/). The seemingly-random 256 bits on the lefthand side of the hash [Output](https://bitcoindevelopers.org/encyclopedia/output/) are used as the integer value to be combined with either the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) or parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to, respectively, create either a child [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) or child [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/):

```
child_private_key == (parent_private_key + lefthand_hash_output) % G
child_public_key == point( (parent_private_key + lefthand_hash_output) % G )
child_public_key == point(child_private_key) == parent_public_key + point(lefthand_hash_output)
```

Specifying different index numbers will create different unlinkable child keys from the same parent keys. Repeating the procedure for the child keys using the child [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) will create unlinkable grandchild keys.

Because creating child keys requires both a key and a [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), the key and [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) together are called the [Extended key](https://bitcoindevelopers.org/encyclopedia/extended-key/). An extended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) and its corresponding extended [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) have the same [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/). The (top-level parent) [Master private key](https://bitcoindevelopers.org/encyclopedia/master-private-key/) and master [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) are derived from random data, as illustrated below.

  ![Creating A Root Extended Key Pair](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hd-root-keys.svg)

Creating A Root [Extended key](https://bitcoindevelopers.org/encyclopedia/extended-key/) Pair

A [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/) is created from either 128 bits, 256 bits, or 512 bits of random data. This [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/) of as little as 128 bits is the only data the user needs to backup in order to derive every key created by a particular [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program using particular settings.

![Warning icon](https://bitcoindevelopers.org/wp-content/uploads/2025/05/icon_warning.svg) **Warning:** As of this writing, HD [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) programs are not expected to be fully compatible, so users must only use the same HD [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) program with the same HD-related settings for a particular [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/).

The [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/) is hashed to create 512 bits of seemingly-random data, from which the [Master private key](https://bitcoindevelopers.org/encyclopedia/master-private-key/) and master [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) are created (together, the master extended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/)). The master [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) is derived from the [Master private key](https://bitcoindevelopers.org/encyclopedia/master-private-key/) using “point()”, which, together with the master [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), is the master extended [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). The master extended keys are functionally equivalent to other extended keys; it is only their location at the top of the hierarchy which makes them special.

#### Hardened Keys

Hardened extended keys fix a potential problem with normal extended keys. If an attacker gets a normal parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) and parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/), he can brute-force all chain codes deriving from it. If the attacker also obtains a child, grandchild, or further-descended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/), he can use the [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) to generate all of the extended private keys descending from that [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/), as shown in the grandchild and great-grandchild generations of the illustration below.

  ![Cross-Generational Key Compromise](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hd-cross-generational-key-compromise.svg)

Cross-Generational Key Compromise

Perhaps worse, the attacker can reverse the normal child [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) derivation formula and subtract a parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) from a child [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) to recover the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/), as shown in the child and parent generations of the illustration above. This means an attacker who acquires an extended [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) and any [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) descended from it can recover that [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/)’s [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) and all keys descended from it.

For this reason, the [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) part of an extended [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) should be better secured than standard public keys and users should be advised against exporting even non-extended private keys to possibly-untrustworthy environments.

This can be fixed, with some tradeoffs, by replacing the normal key derivation formula with a hardened key derivation formula.

The normal key derivation formula, described in the section above, combines together the index number, the parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), and the parent [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) to create the child [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) and the integer value which is combined with the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) to create the child [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/).

  ![Creating Child Public Keys From An Extended Private Key](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hd-private-parent-to-private-child.svg)

Creating Child Public Keys From An Extended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/)

The hardened formula, illustrated above, combines together the index number, the parent [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/), and the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/) to create the data used to generate the child [Chain code](https://bitcoindevelopers.org/encyclopedia/chain-code/) and child [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/). This formula makes it impossible to create child public keys without knowing the [Parent private key](https://bitcoindevelopers.org/encyclopedia/parent-private-key/). In other words, parent extended public keys can’t create hardened child public keys.

Because of that, a hardened extended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) is much less useful than a normal extended [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/)—however, hardened extended private keys create a firewall through which multi-level key derivation compromises cannot happen. Because hardened child extended public keys cannot generate grandchild chain codes on their own, the compromise of a parent extended [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) cannot be combined with the compromise of a grandchild [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) to create great-grandchild extended private keys.

The [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) uses different index numbers to indicate whether a normal or hardened key should be generated. Index numbers from 0x00 to 0x7fffffff (0 to 231-1) will generate a normal key; index numbers from 0x80000000 to 0xffffffff will generate a hardened key. To make descriptions easy, many developers use the prime symbol to indicate hardened keys, so the first normal key (0x00) is 0 and the first hardened key (0x80000000) is 0´.

(Bitcoin developers typically use the ASCII apostrophe rather than the unicode prime symbol, a convention we will henceforth follow.)

This compact description is further combined with slashes prefixed by *m* or *M* to indicate hierarchy and key type, with *m* being a [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) and *M* being a [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). For example, m/0’/0/122’ refers to the 123rd hardened private child (by index number) of the first normal child (by index) of the first hardened child (by index) of the [Master private key](https://bitcoindevelopers.org/encyclopedia/master-private-key/). The following hierarchy illustrates prime notation and hardened key firewalls.

  ![Example HD Wallet Tree Using Prime Notation](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-hd-tree.svg)

Example HD [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) Tree Using Prime Notation

Wallets following the BIP32 [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) only create hardened children of the [Master private key](https://bitcoindevelopers.org/encyclopedia/master-private-key/) (*m*) to prevent a compromised [Child key](https://bitcoindevelopers.org/encyclopedia/child-key/) from compromising the master key. As there are no normal children for the master keys, the master [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) is not used in HD wallets. All other keys can have normal children, so the corresponding extended public keys may be used instead.

The [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) also describes a serialization format for extended public keys and extended private keys. For details, please see the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) section in the developer reference or BIP32 for the full [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) specification.

#### Storing Root Seeds

Root seeds in the [HD protocol](https://bitcoindevelopers.org/encyclopedia/hd-protocol/) are 128, 256, or 512 bits of random data which must be backed up precisely. To make it more convenient to use non-digital backup methods, such as memorization or hand-copying, BIP39 defines a method for creating a 512-bit [Root seed](https://bitcoindevelopers.org/encyclopedia/root-seed/) from a pseudo-sentence (mnemonic) of common natural-language words which was itself created from 128 to 256 bits of entropy and optionally protected by a password.

The number of words generated correlates to the amount of entropy used:

| Entropy Bits | Words |
| --- | --- |
| 128 | 12 |
| 160 | 15 |
| 192 | 18 |
| 224 | 21 |
| 256 | 24 |

The passphrase can be of any length. It is simply appended to the mnemonic pseudo-sentence, and then both the mnemonic and password are hashed 2,048 times using HMAC-SHA512, resulting in a seemingly-random 512-bit seed. Because any [Input](https://bitcoindevelopers.org/encyclopedia/input/) to the hash function creates a seemingly-random 512-bit seed, there is no fundamental way to prove the user entered the correct password, possibly allowing the user to protect a seed even when under duress.

For implementation details, please see BIP39.

### Loose-Key Wallets

Loose-Key wallets, also called “Just a Bunch Of Keys (JBOK)”, are a deprecated form of [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) that originated from the Bitcoin Core client [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/). The Bitcoin Core client [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) would create 100 [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/)/[Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) pairs automatically via a Pseudo-Random-Number Generator (PRNG) for later use.

These unused private keys are stored in a virtual “key pool”, with new keys being generated whenever a previously-generated key was used, ensuring the pool maintained 100 unused keys. (If the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is encrypted, new keys are only generated while the [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) is unlocked.)

This created considerable [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) in backing up one’s keys, considering backups have to be run manually to save the newly-generated private keys. If a new [Key pair](https://bitcoindevelopers.org/encyclopedia/key-pair/) set is generated, used, and then lost prior to a backup, the stored [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are likely lost forever. Many older-style mobile wallets followed a similar format, but only generated a new [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) upon user demand.

This [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) type is being actively phased out and discouraged from being used due to the backup hassle.