---
title: Operating Modes
description: "# Operating Modes The Bitcoin software has different levels of security and tradeoffs in order to verify the blockchain. ## Introduction Currently there are two primary methods of validating the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain as a client: Full nodes and [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients.…"
url: "https://bitcoindevelopers.org/docs/developer-guides/operating-modes/"
updated: "2025-05-13"
category: Developer Guides
---

# Operating Modes

# Operating Modes

The Bitcoin software has different levels of security and tradeoffs in order to verify the blockchain.

## Introduction

Currently there are two primary methods of validating the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain as a client: Full nodes and [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients. Other methods, such as server-trusting methods, are not discussed as they are not recommended.

## Full [Node](https://bitcoindevelopers.org/encyclopedia/node/)

The first and most secure model is the one followed by Bitcoin Core, also known as a “thick” or “full chain” client. This security model assures the validity of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain by downloading and validating blocks from the genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) all the way to the most recently discovered [Block](https://bitcoindevelopers.org/encyclopedia/block/). This is known as using the *[Height](https://bitcoindevelopers.org/encyclopedia/height/)* of a particular [Block](https://bitcoindevelopers.org/encyclopedia/block/) to verify the client’s view of the network.

For a client to be fooled, an adversary would need to give a complete alternative [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain history that is of greater [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) than the current “true” chain, which is computationally expensive (if not impossible) due to the fact that the chain with the most cumulative [Proof of work](https://bitcoindevelopers.org/encyclopedia/proof-of-work/) is by definition the “true” chain. Due to the computational [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) required to generate a new [Block](https://bitcoindevelopers.org/encyclopedia/block/) at the tip of the chain, the ability to fool a full [Node](https://bitcoindevelopers.org/encyclopedia/node/) becomes very expensive after 6 [Confirmations](https://bitcoindevelopers.org/encyclopedia/confirmations/). This form of verification is highly resistent to sybil attacks—only a single honest network [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) is required in order to receive and verify the complete state of the “true” [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

  ![Block Height Compared To Block Depth](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-block-height-vs-depth.svg)

[Block height](https://bitcoindevelopers.org/encyclopedia/block-height/) Compared To [Block](https://bitcoindevelopers.org/encyclopedia/block/) Depth

## [Simplified Payment Verification](https://bitcoindevelopers.org/encyclopedia/simplified-payment-verification/) ([SPV](https://bitcoindevelopers.org/encyclopedia/spv/))

An alternative approach detailed in the original Bitcoin paper is a client that only downloads the headers of blocks during the initial syncing process and then requests transactions from full nodes as needed. This scales linearly with the [Height](https://bitcoindevelopers.org/encyclopedia/height/) of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain at only 80 bytes per [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/), or up to 4.2MB per year, regardless of total [Block](https://bitcoindevelopers.org/encyclopedia/block/) size.

As described in the white paper, the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) along with a merkle branch can prove to the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client that the transaction in question is embedded in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. This does not guarantee validity of the transactions that are embedded. Instead it demonstrates the amount of work required to perform a double-spend attack.

The [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s depth in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain corresponds to the cumulative [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) that has been performed to build on top of that particular [Block](https://bitcoindevelopers.org/encyclopedia/block/). The [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client knows the [Merkle root](https://bitcoindevelopers.org/encyclopedia/merkle-root/) and associated transaction information, and requests the respective merkle branch from a full [Node](https://bitcoindevelopers.org/encyclopedia/node/). Once the merkle branch has been retrieved, proving the existence of the transaction in the [Block](https://bitcoindevelopers.org/encyclopedia/block/), the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client can then look to [Block](https://bitcoindevelopers.org/encyclopedia/block/) *depth* as a proxy for transaction validity and security. The cost of an attack on a user by a malicious [Node](https://bitcoindevelopers.org/encyclopedia/node/) who inserts an invalid transaction grows with the cumulative [Difficulty](https://bitcoindevelopers.org/encyclopedia/difficulty/) built on top of that [Block](https://bitcoindevelopers.org/encyclopedia/block/), since the malicious [Node](https://bitcoindevelopers.org/encyclopedia/node/) alone will be [Mining](https://bitcoindevelopers.org/encyclopedia/mining/) this forged chain.

### Potential [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) Weaknesses

If implemented naively, an [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client has a few important weaknesses.

First, while the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client can not be easily fooled into thinking a transaction is in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) when it is not, the reverse is not true. A full [Node](https://bitcoindevelopers.org/encyclopedia/node/) can simply lie by omission, leading an [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client to believe a transaction has not occurred. This can be considered a form of Denial of Service. One mitigation strategy is to connect to a number of full nodes, and send the requests to each [Node](https://bitcoindevelopers.org/encyclopedia/node/). However this can be defeated by network partitioning or Sybil attacks, since identities are essentially free, and can be bandwidth intensive. Care must be taken to ensure the client is not cut off from honest nodes.

Second, the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client only requests transactions from full nodes corresponding to keys it owns. If the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client downloads all blocks and then discards unneeded ones, this can be extremely bandwidth intensive. If they simply ask full nodes for blocks with specific transactions, this allows full nodes a complete view of the public addresses that correspond to the user. This is a large privacy leak, and allows for tactics such as denial of service for clients, users, or addresses that are disfavored by those running full nodes, as well as trivial linking of funds. A client could simply spam many fake transaction requests, but this creates a large strain on the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client, and can end up defeating the purpose of thin clients altogether.

To mitigate the latter issue, Bloom filters have been implemented as a method of obfuscation and compression of [Block](https://bitcoindevelopers.org/encyclopedia/block/) data requests.

### Bloom Filters

A [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) is a space-efficient probabilistic data structure that is used to test membership of an element. The data structure achieves great data compression at the expense of a prescribed false positive rate.

A [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) starts out as an array of n bits all set to 0. A set of k random hash functions are chosen, each of which [Output](https://bitcoindevelopers.org/encyclopedia/output/) a single integer between the range of 1 and n.

When adding an element to the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/), the element is hashed k times separately, and for each of the k outputs, the corresponding [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) bit at that index is set to 1.

Querying of the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) is done by using the same hash functions as before. If all k bits accessed in the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) are set to 1, this demonstrates with high probability that the element lies in the set. Clearly, the k indices could have been set to 1 by the addition of a combination of other elements in the domain, but the parameters allow the user to choose the acceptable false positive rate.

Removal of elements can only be done by scrapping the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) and re-creating it from scratch.

### Application Of Bloom Filters

Rather than viewing the false positive rates as a liability, it is used to create a tunable parameter that represents the desired privacy level and bandwidth trade-off. A [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client creates their [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) and sends it to a full [Node](https://bitcoindevelopers.org/encyclopedia/node/) using the [Message](https://bitcoindevelopers.org/encyclopedia/message/) `filterload`, which sets the filter for which transactions are desired. The command `filteradd` allows addition of desired data to the filter without needing to send a totally new [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/), and `filterclear` allows the connection to revert to standard [Block](https://bitcoindevelopers.org/encyclopedia/block/) discovery mechanisms. If the filter has been loaded, then full nodes will send a modified form of blocks, called a [Merkle block](https://bitcoindevelopers.org/encyclopedia/merkle-block/). The [Merkle block](https://bitcoindevelopers.org/encyclopedia/merkle-block/) is simply the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) with the merkle branch associated with the set [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/).

An [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client can not only add transactions as elements to the filter, but also public keys, data from [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts and pubkey scripts, and more. This enables P2SH transaction finding.

If a user is more privacy-conscious, he can set the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) to include more false positives, at the expense of extra bandwidth used for transaction discovery. If a user is on a tight bandwidth budget, he can set the false-positive rate to low, knowing that this will allow full nodes a clear view of what transactions are associated with his client.

**Resources:** BitcoinJ, a Java implementation of Bitcoin that is based on the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) security model and Bloom filters. Used in most Android wallets.

Bloom filters were standardized for use via BIP37. Review the BIP for implementation details.

## Future Proposals

There are future proposals such as Unspent Transaction [Output](https://bitcoindevelopers.org/encyclopedia/output/) ([UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/)) commitments in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain to find a more satisfactory middle-ground for clients between needing a complete copy of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, or trusting that a majority of your connected peers are not lying. [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) commitments would enable a very secure client using a finite amount of storage using a data structure that is authenticated in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. These type of proposals are, however, in very early stages, and will require soft forks in the network.

Until these types of operating modes are implemented, modes should be chosen based on the likely threat model, computing and bandwidth constraints, and liability in bitcoin value.

**Resources:** Original Thread on [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) Commitments