A Bitcoin node is, therefore, a machine running an implementation of the Bitcoin protocol. Behind this common definition of nodes, several possible configurations exist, not all of which offer the same level of autonomy, resource consumption, and usefulness for the network. In this chapter, we'll attempt to understand these differences to help you choose a node architecture that suits your use and hardware constraints.

A full node is simply a Bitcoin node that downloads the entire Blockchain from the Genesis block, validates each block independently, and stores the history of all that Blockchain locally. This is the "normal" form of a Bitcoin node, as imagined by Satoshi Nakamoto.

The full node doesn't need to trust anyone because it validates and knows all the information in the system. It's the type of node that gives you the most guarantees: you know, without relying on a third party, whether a payment is valid, whether a block is valid, whether a reorganization is legitimate, and so on.

In practice, a full node requires non-trivial resources, including several hundred gigabytes for block files, a processor capable of validating scripts, RAM for the Mempool and caches, and stable bandwidth. The first synchronization (IBD) reads and verifies the complete history: it's intensive, but only happens once. A full node actively participates in the network, relaying blocks and transactions, and can accept incoming connections to assist other peers.

Depending on your needs, you can add an indexer to your full node. Bitcoin Core offers transaction indexing as an optional feature (deactivated by default), which can be useful for specific purposes. However, it doesn't include an address indexer, which is often the most sought-after feature for individual users. To remedy this, you can install dedicated software on your node, such as Electrs or Fulcrum, to speed up address balance verification queries from associated UTXOs. We'll come back to the role of the indexer in more detail in a separate chapter.

The pruned node validates everything as a full node, from the Genesis block to the head of the chain with the most work, but only keeps the most recent part of the block files. Once the old blocks have been checked, it gradually deletes them to stay below a space limit you can set. This configuration is ideal if you have disk space constraints: you retain the independence of block validation, without storing the complete Blockchain history archive. This option is particularly useful if you simply want to install Bitcoin Core on your personal computer, without using a dedicated machine.

The technical implications of this option are fairly straightforward: the pruned node is perfectly capable of broadcasting your transactions, participating in the relay, verifying blocks and transactions, and tracking the chain. On the other hand, it cannot serve as a source of historical data beyond its limits for other applications (e.g., full explorers, indexers, wallets). Functions requiring the archive (or a global index) will therefore not be available.

In practical terms, you can use a pruned node to connect wallet management software such as Sparrow wallet. However, you won't be able to scan transactions on your wallet that predate the pruning limit. For example, if you have a transaction registered in block 901 458, but your node only keeps blocks from 905 402 upwards (because the oldest have been pruned), you won't be able to scan this transaction. On the other hand, if you had already scanned it when your node still had this block height, then your wallet management software will store the information and display the balance of the corresponding UTXOs correctly.

In short, wallet tracking works without a hitch on a pruned node if you create a new wallet while your software is already connected to that node. On the other hand, you may encounter difficulties if you restore an old wallet, as past transactions that are no longer retained by the node will obviously not be retrievable.

An SPV (Simplified Payment Verification) node, or lightweight node, retains only block headers, not transaction details, and relies on other full nodes to obtain proof that a transaction is in a block (Merkle proofs via trees) for which it has the header. The concept of simplified payment verification is not new, having been proposed by Satoshi Nakamoto himself in part 8 of the White Paper.

Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://Bitcoin.org/Bitcoin.pdf

This type of node is obviously much lighter in terms of storage and CPU usage than a full node or even a pruned node. The SPV node is therefore well-suited to smaller devices and intermittent connections. In fact, it is often integrated directly into the wallet, especially mobile software such as the Blockstream App.

The trade-off is trust and confidentiality: an SPV client doesn't check scripts or validation policies itself; it assumes that the chain with the most work is valid, and depends on one or more full nodes for responses. Using this type of node is therefore a better option than connecting to a third-party node; however, it is still less advantageous than having a full node or even a pruned node.

For a novice user with just a wallet on a mobile app, using an SPV node is surely the best way to get started. Installation is quick, requires few resources, and the experience is simple and fluid. This means that you can verify certain information yourself and, therefore, rely less on third-party nodes while simultaneously being more independent when it comes to broadcasting transactions.

An intermediate user with a PC can install a pruned node to benefit from almost all the advantages of a full node, without overloading their machine on a daily basis: full validation, moderate disk usage, and simple maintenance. It's an ideal solution for connecting your desktop wallets and remaining independent in the distribution of your transactions, without investing in a dedicated machine or overloading your disk space.

A full node remains the best solution if you want to be totally independent in your use of Bitcoin and not limit yourself later on to advanced uses such as an indexer, a Lightning node, or even a block explorer. That's exactly what we're going to explore in this course!