> 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/concepts/concepts.md).
# Blockchain Fundamentals
Conceptual background to the protocol specification
This section gives the conceptual background needed to read the [Specification](/bitcoin-protocol-documentation/specification/transactions.md). It is context, not the validity contract itself — every rule that determines whether a transaction or block is valid is stated in the Specification section.
## Blocks and the chain
A block is an 80-byte header followed by an ordered list of transactions. Each header contains the double-SHA-256 of the previous block's header (`hashPrevBlock`), so blocks form a chain: altering an old block would change its hash and break every block after it. The header also carries the **Merkle root**, a single hash committing to every transaction in the block (see [Blocks](/bitcoin-protocol-documentation/specification/blocks.md)).
Chain of blocks
## Transactions and the UTXO model
A transaction consumes existing outputs and creates new ones. Each **output** carries an amount and a locking script (`scriptPubKey`); each **input** references a previous output and supplies an unlocking script (`scriptSig`) that satisfies it (see [Transactions](/bitcoin-protocol-documentation/specification/transactions.md)).
An output that has not been spent is an **unspent transaction output (UTXO)**. The set of all UTXOs is the current ledger state — collectively it accounts for every satoshi in existence. Spending is all-or-nothing at the output level: consuming a 100-satoshi UTXO to pay 50 (with, say, 10 in fees) consumes the whole 100 and creates a new 40-satoshi output as change. Because outputs are independent and carry no shared balance, transactions spending different UTXOs can be validated in parallel.
The first transaction of every block is the **coinbase**: it has a null input and issues new coins, up to the block subsidy plus fees (see [Economic Model](/bitcoin-protocol-documentation/concepts/economic-model.md)).
The UTXO model
## Proof of work and consensus
Nodes agree on the next block through **proof of work**: a node assembles a candidate block and searches for a nonce that makes the header hash meet the target in `nBits`. Finding a solution is competitive; validating a proposed block is cooperative — a block that satisfies the [consensus rules](/bitcoin-protocol-documentation/specification/consensus-rules.md) is accepted by other nodes, which express acceptance by building on it. The chain with the greatest cumulative work is the one nodes extend. A node earns a block's subsidy and fees only if the network builds on its block, aligning its incentive with rule-compliant behaviour.
## Properties
The following properties all follow from the rules and structures above:
* **Immutability.** Changing any transaction changes its block's Merkle root and hash, invalidating the proof of work of that block and every block after it.
* **Distributed validation.** Every node applies the same consensus rules, so honest nodes converge on the same valid chain; a block is accepted only after independent validation.
* **Pseudonymity.** Transactions reference public keys and scripts, not identities; any identity binding is off-chain (see [Privacy and Identity](/bitcoin-protocol-documentation/concepts/privacy-and-identity.md)).
* **Economic security.** Rewriting a confirmed block requires out-pacing the honest chain's cumulative work, making history rewrites economically impractical.
* **Consensus by work.** Influence over the chain is proportional to work performed ("one CPU, one vote"), a Sybil-resistant answer to the Byzantine Generals problem.
* **Scale.** From Genesis the block-size limit is a miner-configured consensus cap and the maximum transaction size is 1 GB; Script imposes no protocol limit on the number of inputs or outputs.
* **Peer-to-peer verification.** SPV lets a party verify a transaction's inclusion in a block with a Merkle proof, without the full chain (see [Light Clients and SPV](/bitcoin-protocol-documentation/implementation-notes/light-clients-and-spv.md)).
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/concepts/concepts.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
