> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/implementation-notes/node-operations.md).

# Node Operations

{% hint style="info" %}
This page describes **how the reference node software implements** the protocol — validation flow, block assembly, storage, chain tracking. This is implementation detail, **not** part of the consensus rules. The validity contract is specified in [Consensus Rules](/bitcoin-protocol-documentation/specification/consensus-rules.md) and the [Specification](/bitcoin-protocol-documentation/specification/transactions.md) section. An independent implementation may organise these functions differently and remain fully interoperable, provided it enforces the same consensus rules. The reference implementation is [`bitcoin-sv/bitcoin-sv`](https://github.com/bitcoin-sv/bitcoin-sv).
{% endhint %}

A node runs three concurrent workflows: validating transactions, assembling and validating blocks, and tracking the longest valid chain.

<figure><img src="/files/C2WUenmXyzWE6cUHLWwn" alt=""><figcaption></figcaption></figure>

## Transaction validation

When a node receives a transaction it applies the consensus checks before accepting it into the mempool and relaying it; the same checks are applied to every transaction when validating a block. The authoritative rule set is [Consensus Rules](/bitcoin-protocol-documentation/specification/consensus-rules.md); in summary the node checks transaction structure, non-empty input/output lists, size, value ranges, absence of duplicate or null inputs, that each referenced output exists and is unspent, coinbase maturity, that inputs cover outputs, fee policy, and that each input's unlocking script validates against the output's locking script ([Opcodes](/bitcoin-protocol-documentation/specification/opcodes.md#cryptography)).

On success the spent outputs are marked in the [UTXO set](#utxo-set), the new outputs are added, and the transaction enters the [mempool](#mempool). Any failure rejects the transaction.

## UTXO set

The UTXO set is the current ledger state: every output that exists and has not been spent. Except for coinbase transactions, every valid transaction spends at least one existing UTXO and creates new ones. Because any unspent output may be spent at any time, the full set must be persisted and is never pruned away.

A UTXO's lifecycle: validating a transaction creates its output UTXOs; referencing a UTXO as an input locks it (enforcing the first-seen rule); acceptance marks it spent. UTXO state is relative to the chain tip and is resynced when the tip changes.

## Mempool

The mempool is a node's cache of validated but unconfirmed transactions. It is a local, policy-governed structure, **not** defined by consensus. Entries are removed when mined into a block, when conflicting with a mined transaction (a double spend, with its descendants), or on expiry (a default of two weeks — a policy setting).

## Block assembly

The block assembler builds a candidate block: it takes the current chain tip, gathers validated transactions from the mempool, orders them, adds the coinbase, computes the Merkle root, and forms the header for the proof-of-work search (see [Blocks](/bitcoin-protocol-documentation/specification/blocks.md)). As new transactions arrive it updates the candidate and its Merkle root.

## Mining

Mining performs the proof-of-work search over the candidate header: the 80-byte header is double-SHA-256 hashed and compared to the target; the nonce is incremented (and, when exhausted, the coinbase extra-nonce changed) until the hash meets the target. On finding a solution the node propagates the block over the [BSN](#bitcoin-server-network-bsn); other nodes validate and extend it. See [Blocks — Proof of work](/bitcoin-protocol-documentation/specification/blocks.md#proof-of-work).

## Block validation

When a node learns of a new block it validates it against the block-level consensus rules ([Blocks](/bitcoin-protocol-documentation/specification/blocks.md), [Consensus Rules](/bitcoin-protocol-documentation/specification/consensus-rules.md)): the header and proof of work, then every transaction, then the Merkle root against the header. Transactions already validated need not be rechecked. On success the node adopts the block as the new chain tip and builds on top of it. A block is rejected if it violates a consensus rule, awards more than subsidy + fees, contains an invalid transaction, has invalid proof of work, or has an invalid timestamp.

**Orphan blocks.** When two nodes find a solution at nearly the same time the network briefly holds two candidate tips; the fork resolves when the next block extends one of them, and the block on the abandoned tip is orphaned. Nodes always build on the chain with the most cumulative work.

## Chain tracking

The node stores every block header from Genesis to the current tip and tracks the longest valid chain. When a peer announces a block it triggers download and validation; if the node has fallen behind it downloads and validates the missing blocks to rejoin the tip. It keeps the mempool and UTXO set aligned with the active tip and tracks competing candidate tips so temporary forks are handled correctly.

## Bitcoin Server Network (BSN)

The BSN is the node's peer-to-peer message layer. It maintains connections to peers and distributes and retrieves new blocks, new transactions, chain state, and (on demand) block headers and full blocks. Every node performs the same role. Block-header clients connect the same way but store only headers.

## Pruning

A node may prune historical transaction data from disk once it no longer needs that data for the policies it implements (validating new transactions primarily requires the [UTXO set](#utxo-set)). Pruning does **not** by itself preserve the ability to serve SPV Merkle proofs for deleted transactions: reconstructing an inclusion proof requires either the full transaction list for the block or retained intermediate Merkle hashes for the path. A pruned node that discards those data can still validate new blocks against the UTXO set, but cannot rebuild arbitrary historical SPV proofs unless it stored them (see [Light Clients and SPV](/bitcoin-protocol-documentation/implementation-notes/light-clients-and-spv.md)).

{% hint style="info" %}
The white paper notes that transactions may be discarded to save disk space: a proof of the previous transaction can be kept and the rest pruned, allowing the chain to continue without the full transaction history.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/implementation-notes/node-operations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.