SLQ notes: 8. Blockchain and Bitcoin – Nodes and the Bitcoin Network

Blockchain and Bitcoin – Nodes and the Bitcoin Network

When people first learn about Bitcoin, they often picture two things. One is the blockchain as a big ledger that everyone shares. The other is mining, with computers racing to find new blocks.

There is an important piece in between those two pictures. That piece is the network of nodes.

Nodes are the machines that hold copies of the blockchain, talk to each other, check every transaction and every block, and decide which chain is valid. Without nodes, there would be no shared view of the ledger and no way to agree on which coins exist and who can spend them.

This article explains what nodes are, how they behave, and how the Bitcoin network ties everything together. It starts with short definitions of the main concepts, then goes deeper into the important parts: what full nodes really do, how transactions and blocks travel through the network, and what it means to verify Bitcoin for yourself.

1. Core concepts in brief

1.1 Node

A node is a program that speaks the Bitcoin protocol on the network and understands the rules of the system. It connects to other nodes, sends and receives messages, and maintains some view of the blockchain and the set of unspent outputs.

You can think of a node as a participant in the shared database. Some nodes fully verify every block and every transaction. Others rely on those full nodes.

1.2 Full node

A full node downloads blocks, verifies them against all consensus rules, and independently maintains the current UTXO set. It does not simply trust others when they say “this chain is valid”. It checks.

Full nodes can accept incoming connections from other peers and relay transactions and blocks across the network. They are the backbone of Bitcoin.

1.3 Mining node

A mining node is a full node with extra software that builds candidate blocks and runs the proof of work process. It participates in creating new blocks. Many miners use separate full nodes and talk to them through a local interface.

All valid blocks, whether mined by you or someone else, must satisfy the same rules that full nodes enforce.

1.4 Lightweight client

A lightweight client, sometimes called an SPV client, does not verify every transaction and does not keep the full UTXO set. It usually tracks block headers and asks full nodes for proofs that certain transactions appear in the chain.

This saves bandwidth and storage but changes the trust model. A lightweight client relies on full nodes to provide honest information.

1.5 Peer to peer network

Bitcoin uses a peer to peer network. There is no central server that coordinates everything. Nodes connect directly to each other, share addresses of other nodes, and relay data in a gossip like fashion.

Every node chooses a set of peers and builds its own view of the network.

1.6 Transaction and block propagation

When a wallet sends a transaction, it first reaches one node. That node checks the transaction and, if it looks acceptable, relays it to its peers. They do the same. The transaction spreads outward like ripples.

Newly mined blocks spread in a similar way. Nodes advertise that they have a block. Interested peers ask for the full data. Once they check the block, they relay it further.

2. Types of nodes at a glance

Not every node has the same role. At a high level there are several common types.

2.1 Fully validating archival nodes

These nodes:

Download the entire blockchain from the beginning.
Verify every block header and every transaction against the rules.
Maintain a full UTXO set.
Keep all historical blocks on disk.

They can answer questions such as “what did this address receive five years ago” and can serve historical data to other nodes.

2.2 Pruned full nodes

Pruned nodes also validate the full chain and maintain the full UTXO set, but they do not keep all old blocks on disk.

After a block is old enough and its transactions no longer affect the UTXO set beyond the current state, a pruned node can delete that block data to save space, while keeping the minimum amount of history required by its configuration.

From a consensus point of view, pruned nodes are full nodes. They still check all rules. They simply do not act as long term archives for others.

2.3 Mining nodes and pool setups

Mining nodes use full node logic plus mining specific software.

There are several layers in typical mining setups:

A full node that maintains the chain and UTXO view.
A mining daemon that constructs candidate blocks from the mempool.
Many worker machines that search for valid hashes over the candidate blocks.

Mining pools can separate these roles across many machines and locations, but all of them ultimately depend on a full node view of the chain.

2.4 Lightweight clients and wallets

Lightweight clients are usually wallet applications that:

Do not download all transactions.
Do not maintain a full UTXO set.
Rely on full nodes to tell them about relevant transactions.

They may track only block headers and request proofs that specific transactions are in specific blocks. They can verify that the proof of work on headers looks valid, but they cannot recheck all script and UTXO rules on their own.

3. What a full node really does

Full nodes are important because they enforce the rules of Bitcoin independently. To see why this matters, it helps to look inside their main tasks.

3.1 Maintaining the UTXO set

The UTXO set is the current “state of the ledger”. It lists all unspent outputs and their amounts and locking scripts.

A full node:

Starts from the genesis block with an empty UTXO set.
Processes each block in order.
For each transaction in each block:
- Checks that all inputs refer to UTXOs that currently exist in the set.
- Checks that scripts and signatures in those inputs are valid.
- Removes those UTXOs from the set because they are now spent.
- Adds the new outputs as new UTXOs.

At any moment, the node can answer the question “is this input trying to spend an existing unspent output” by looking in its UTXO database.

The UTXO set is much smaller than the full history of all transactions. It is the compact result of all past activity.

3.2 Validating transactions

When a full node receives a new transaction from the network, before adding it to its mempool it checks:

Each input references a UTXO that is unspent and known.
The sum of inputs is at least as large as the sum of outputs.
Fees are not negative and are within reasonable bounds.
Scripts run successfully and do not use forbidden operations.
Transaction size and structure fit policy rules.

If any of these checks fail, the node rejects the transaction and does not relay it. This local decision protects the node and its peers from wasting resources on invalid data.

Once in the mempool, the transaction is ready to be considered for inclusion in a future block by miners.

3.3 Validating blocks

When a full node receives a new block, it performs checks at two levels.

First, block header checks:

The block references a previous block that the node knows.
The timestamp is within reasonable bounds.
The proof of work target and actual hash satisfy difficulty rules.

Second, transaction and state checks:

The block obeys size and weight limits.
The coinbase transaction respects subsidy and fee rules.
Every transaction in the block is valid in the same way as for mempool entries.
No UTXO is spent twice in the block or in the chain history.

Only if all checks pass does the node accept the block and connect it to its current chain. It then updates its UTXO set and removes any included transactions from the mempool.

3.4 Selecting the best chain

At any time there may be several branches of blocks that extend from the past. A full node chooses one branch as its active chain according to the consensus rule.

The usual rule is that the active chain is the one with the most accumulated work, which in practice is often the longest sequence of valid blocks.

If a node receives a new block that creates a longer valid chain than the one it uses, it may switch to that chain. This involves:

Rolling back some blocks from its current tip.
Replaying blocks from the new branch.
Updating the UTXO set accordingly.

This process keeps nodes in rough agreement about which chain represents the current state, even if miners occasionally produce competing blocks.

4. The peer to peer network

Now that we know what a full node does internally, we can look at how nodes find each other and exchange information.

4.1 Connecting to peers

When a Bitcoin node starts, it needs to discover peers. It can do this by:

Using hard coded bootstrap addresses, such as known servers.
Querying DNS seeds that return a list of node addresses.
Using a saved list of peers from previous sessions.

Once it has some addresses, the node opens outgoing connections to them. It also listens for incoming connections if its network setup allows it.

After a connection is established, nodes send version messages to announce their protocol level and some basic information. If both sides agree, they continue and become peers.

4.2 Gossip rather than central broadcast

There is no central point that broadcasts every transaction or block to everyone. Instead, nodes exchange inventory messages that say “I have this transaction or block, identified by this hash”.

If a peer sees an inventory item it does not know, it can request the full data. Once it receives and verifies that data, it may in turn advertise it to its own peers.

Over time, information spreads across the network through many overlapping paths. This is often called a gossip protocol. It has several advantages:

No single point of failure.
Many routes for data to travel, which improves robustness.
Nodes can control their bandwidth by choosing how many peers to connect to and how often to relay.

4.3 Topology and randomness

The network topology is not fixed. Nodes come and go, connections appear and disappear.

To avoid fragile structures and censorship, nodes choose peers somewhat randomly among the addresses they know. They try to maintain a mix of long lived connections and new ones. This helps the network stay connected even if some parts fail or are attacked.

Because different nodes pick different peers, their local view of the network graph is unique, but the overall structure tends to be a large, loosely connected mesh.

5. How transactions travel through the network

From the point of view of a node, a transaction arrives, is checked, and either relayed or rejected. From the point of view of the whole network, countless such decisions create a flow.

5.1 From wallet to first node

A wallet typically connects to one or more nodes. These can be nodes you run yourself or nodes provided by a service.

When you create a transaction and broadcast it, the wallet sends it to its connected node. That node checks it as described earlier. If it passes, the node adds it to its mempool and advertises it to peers.

At this moment there is at least one copy of the transaction in the network.

5.2 Inventory and relay

Peers do not blindly push full transactions to everyone at all times. Instead they:

Send an inventory message that lists hashes of transactions they have.
Wait for peers to request any transactions they are missing.
Send the requested transaction data.

This reduces wasted bandwidth. If a node already has a transaction in its mempool or has seen it before, it can ignore the inventory item.

When a node receives a new transaction, verifies it, and finds it acceptable, it adds it to its mempool and repeats the process with its peers. In this way, a single transaction can reach many nodes quickly.

5.3 Local policy and mempool differences

Each node has its own mempool and its own policy rules beyond the strict consensus rules. A node may choose not to accept or relay transactions that are:

Below a certain minimum fee rate.
Too large according to its own limits.
Non standard in some way.

This means that not every transaction reaches every node. There is no requirement that all nodes must store every pending transaction.

In practice, as long as a transaction satisfies common policies and pays a reasonable fee, it tends to reach the miners’ nodes and has a chance to be included in a block.

6. How blocks travel and how nodes stay in sync

Blocks travel in a similar pattern to transactions, but they also affect which chain a node considers valid.

6.1 Block advertisement and download

When a miner finds a valid block, it announces it to its peers with an inventory message. Interested peers ask for the full block.

Upon receiving the block, each node:

Checks the block header.
Validates all the transactions and updates its UTXO set if the block is acceptable.
Creates its own inventory messages to inform peers about the new block.

Because blocks are larger than typical transactions, nodes may use special protocols to optimize block relay. The goal is to reduce the time it takes for the network to learn about a new block, since miners want to work on the latest tip.

6.2 Competing blocks and short forks

Sometimes two miners find valid blocks at nearly the same time. Different parts of the network may see different blocks first.

In this case, a node:

Sees a new block that extends the current tip. It tentatively accepts it as the new tip.
Later sees another block that extends the same previous tip but is different. That second block forms a competing chain of the same length.

The node follows a simple principle. It usually keeps the branch it saw first as its active chain as long as both chains have the same length and accumulated work. It still stores the other block and its branch as a side chain.

When a later block appears that extends one of these branches, that branch becomes longer. All nodes then switch to that branch as the active chain. The block on the other branch that was previously at the tip becomes an orphan in practice.

Transactions in orphaned blocks go back into mempools if they are still valid and not already mined in the new branch.

This process of short lived forks and reconvergence is normal. It is one reason why waiting for several confirmations reduces the chance that a transaction will be undone.

6.3 Initial block download

When a new full node joins the network, it needs to catch up on all past blocks.

The process is often called initial block download:

The node connects to peers and learns about the current chain tip.
It requests block headers in batches to build the chain of headers.
It verifies proof of work on headers and selects the best header chain.
It then downloads full blocks in order and processes them, updating the UTXO set.

This can take some time, depending on bandwidth and hardware. Once complete, the node has an independent and fully verified view of the blockchain and can keep up with new blocks in real time.

7. Trust and verification models

Different node types give different answers to the question “whom do I have to trust”.

7.1 Full node trust model

A full node that you control is the strictest form of verification.

You do not need to trust miners about the validity of blocks. You do not need to trust peers about which chain is correct. You check all rules yourself.

You still rely on:

Your own software being correct.
Your hardware behaving as expected.
The network delivering data, although even here you can use multiple peers and cross check.

The essential point is that no remote party can trick your node into accepting a different set of rules without your consent. If a miner or group of miners creates blocks that break the rules, your node will reject them.

7.2 Lightweight client trust model

A lightweight client that only tracks headers and does not check every transaction relies on full nodes in several ways:

It believes that the longest chain of valid looking headers it sees is genuine.
It believes that transaction proofs it receives correspond to real blocks in that chain.
It usually trusts remote nodes to tell it which transactions are relevant.

This is still stronger than blind trust in a central server, because the client can verify proof of work on headers and compare views from multiple peers. However, it cannot detect certain subtle rule violations or targeted misinformation as reliably as a full node can.

7.3 Using someone else’s node

Many wallets connect by default to nodes operated by the wallet provider or another service. In that case, the trust model is closer to that of a traditional client server relationship.

The server:

Decides which chain to consider valid.
Decides which transactions to show you as confirmed or unconfirmed.
Can filter or modify the view of the blockchain it presents to you.

For small amounts or low risk uses, this may be acceptable. For high value or high risk uses, many people prefer to connect their wallet to a node they run themselves.

8. Why run your own node

Running a full node requires disk space, bandwidth and some technical effort. It is natural to ask why anyone would bother when they can let others do the work.

There are several reasons.

8.1 Independent verification of rules

A core principle of Bitcoin is that you do not have to trust any single authority about what the rules are or whether they are being followed.

When you run a full node:

You choose which software to run.
You choose which consensus rules to accept.
You decide which chain is valid based on those rules and proof of work.

If others attempt to change the rules in a way you do not accept, your node simply rejects blocks that break the rules, even if some miners produce them.

8.2 Improved privacy

If your wallet connects to a node you control, you do not have to reveal your addresses and transaction patterns to a third party node operator.

From the network’s point of view, your node looks like any other. From your wallet’s point of view, it is a trusted source of blockchain data.

This does not solve all privacy issues, especially those caused by transaction structure on chain, but it removes one common channel of information leakage.

8.3 Contributing to network robustness

The more independently operated full nodes exist, the harder it is to attack or corrupt the network.

An attacker who wants to feed false information to users or censor transactions would have to influence a large number of nodes across many jurisdictions and administrative domains.

By running a node, you:

Provide another honest peer that relays valid transactions and blocks.
Increase the diversity of implementations and configurations.
Help the network remain decentralized and resilient.

Even if your node is small compared to large mining operations, it still participates in enforcing rules and in relaying data.

8.4 Pruned nodes as a practical compromise

If storage is a concern, running a pruned node can be an attractive choice.

A pruned node:

Verifies the entire chain.
Maintains the full UTXO set.
Discards old block data beyond a chosen threshold.

You still get independent verification of current state, but you do not act as a long term archive for others. For many users, this is a reasonable balance between resource use and sovereignty.

9. Network health and decentralization

Nodes and the network layer play an important role in Bitcoin’s decentralization and security.

9.1 Geographic and jurisdictional spread

If most full nodes and miners were located in one country or under one legal system, it would be easier for that jurisdiction to influence the network.

A healthy network has nodes in many countries, run by many different people and organizations. This makes regulatory capture harder. It also reduces the impact of local outages, natural disasters or infrastructure failures.

9.2 Diversity of software and infrastructure

Different node implementations and different versions of the software add resilience.

If a bug affects one implementation, nodes running other implementations may continue to function and keep the network alive. This is similar to diversity in ecological systems. A monoculture is fragile. A mix of species is more robust.

At the same time, too much fragmentation can be dangerous if different implementations interpret rules in incompatible ways. This is why careful testing and gradual deployment of changes are important.

9.3 Attacks at the network layer

Because nodes rely on the network to receive blocks and transactions, the network layer can be a target for attacks.

Examples include:

Trying to isolate a node by surrounding it with malicious peers that feed it a false view of the chain.
Attempting to delay or block certain transactions by refusing to relay them.
Overloading nodes with spam connections or malformed messages.

Bitcoin software includes many protections against such attacks, such as:

Limiting the number of connections from a single IP range.
Disconnecting peers that behave in obviously incorrect ways.
Using multiple peers to reduce the chance of isolation.

No system is perfectly immune, but a large, diverse network of nodes is much harder to manipulate than a small, centralized one.

10. How nodes and the network tie the system together

Previous articles have described:

How UTXOs represent the ledger.
How transactions prove ownership and move value.
How scripts express spending conditions.
How fees, mempools and miners create a fee market.
How privacy and on-chain analysis interact.

Nodes and the Bitcoin network are the environment in which all of this happens.

Nodes maintain the UTXO set and enforce the rules.
The peer to peer network lets transactions and blocks reach those nodes without a central coordinator.
Full nodes give users a way to verify the system independently.
Lightweight clients offer convenience while relying on full nodes for deeper checks.

Understanding nodes and the network completes the picture. You can now see Bitcoin not only as a ledger and a set of rules, but also as a living network of machines that constantly talk to each other, compare views of the world, and reject anything that does not fit the agreed rules.

From here, the next natural step is to look more closely at block structure and consensus, and to see how these nodes use proof of work and chain selection to converge on a single history in a noisy and imperfect world.

December 19, 2025

8. Blockchain and Bitcoin – Nodes and the Bitcoin Network