> For the complete documentation index, see [llms.txt](https://www.notbank.com/learn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.notbank.com/learn/academy/en/bitcoin/p2p-networks.md).
# P2P Networks
***
> “Miners build blocks; nodes decide consensus.”\
> — Paraphrasing *Gregory Maxwell*
***
## 1. Introduction
The Bitcoin P2P network is the backbone of the system.\
Without it:
* there would be no consensus
* there would be no transaction propagation
* there would be no coordinated mining
* there would be no distributed blockchain
This chapter explores:
* Network topology
* How full nodes work
* P2P protocol messages
* Validation and synchronization
* Relay of blocks and transactions
* Protection against attacks
* Gossip structure
* Sociopolitical role of the sovereign node
***
## 2. Bitcoin network design philosophy
Bitcoin is a network:
* **decentralized** (no central server),
* **permissionless** (anyone can connect),
* **pseudonymous** (no mandatory identity),
* **robust** (partial failures do not affect the whole),
* **high-latency tolerant**,
* **leaderless**,
* message-based, like *gossip*.
It is not like a corporate network; it is more like **an ant colony where each node has little information, but the global system emerges from the whole.**
***
## 3. Types of nodes in the network
### 3.1. Full nodes
These nodes:
* download the entire blockchain
* verify all consensus rules
* reject invalid blocks
* maintain the mempool
* retransmit transactions and blocks
They are the **sovereign force of consensus**.
***
### 3.2. Lightweight nodes (SPV)
Simplified Payment Verification:
* do not verify rules
* only download headers
* rely on full nodes
They use **Merkle Proofs** to prove that a transaction is included in a block.
***
### 3.3. Mining nodes
They are full nodes + specialized hardware (ASICs).\
They use:
* block templates (`getblocktemplate`)
* mempool data
* fast synchronization
***
### 3.4. Archival nodes
They keep all historical states without pruning.\
They are optional.
***
## 4. Network topology
Bitcoin adopts an **unstructured mesh,** where each node typically maintains:
* 8 outgoing connections
* up to hundreds of incoming (depending on configuration)
The network stays connected even in the face of massive node loss.
***
## 5. P2P protocol: messaging and structure
### 5.1. Main messages
| Message | Function |
| ----------- | ----------------------------- |
| `version` | Initiates connection |
| `verack` | Confirms version |
| `inv` | Announces data (blocks or TX) |
| `getdata` | Requests data |
| `tx` | Transaction broadcast |
| `block` | Block broadcast |
| `getblocks` | Synchronization |
| `ping/pong` | Liveness check |
| `addr` | Node propagation |
***
## 6. Transaction propagation
When a node receives a valid transaction:
1. It fully verifies it.
2. It adds it to the mempool.
3. It sends a message `inv` to its peers.
4. They request the transaction if they do not have it.
This is called **gossip protocol**: redundant diffusion.
***
## 7. Block propagation
Blocks circulate faster than transactions.
Process:
1. Miner finds valid PoW.
2. Sends `inv` to peers.
3. They request the block.
4. They verify header, transactions and PoW.
5. They in turn broadcast it.
***
### 7.1. Relay methods
#### 1. **Standard block relay**
Sends full block.
#### 2. **Compact Blocks (BIP152)**
Reduces bandwidth → 90% more efficient.
#### 3. **Header-first relay**
Sends header first → allows preliminary validation.
***
## 8. Validation of transactions and blocks
Full nodes verify *everything*.
***
### 8.1. Transaction validation
They check:
* signatures
* scripts
* format
* values
* absence of double spending
* existence of UTXOs
* size limits
* witness structures
* correct sighash
* valid locktime
***
### 8.2. Block validation
They check:
* PoW
* size
* merkle root
* rewards
* valid coinbase
* reasonable timestamp
* correct header
* linking
* all transactions
***
## 9. Blockchain synchronization
Process known as **Initial Block Download (IBD)**.
Steps:
1. Download all headers.
2. Verify PoW of each one.
3. Download full blocks.
4. Verify transactions.
5. Build the UTXO set.
Final UTXO ≈ 4–10 GB\
Blockchain ≈ 500+ GB (depending on the year).
***
## 10. Mempool: memory of pending transactions
Each node maintains its own mempool:
* it is not global
* it is not synchronized
* each one accepts/rejects according to its rules
* applies fee policies
* drops spam
It is a **permissive**, not a consensus.
***
## 11. Protection against P2P attacks
Bitcoin includes numerous defenses.
***
### 11.1. Anti-Sybil
* no identity
* PoW limits the usefulness of thousands of fake nodes
* random connections
* limited slots for incoming
***
### 11.2. Anti-DDoS
* rate limits
* automatic disconnections
* penalization of malicious peers
* temporary ban
* sparse topology
***
### 11.3. Anti-eclipse
* multiple connections
* diverse sources
* periodic reconnection
* diverse DNS seeds
* address rotation
***
## 12. Game theory applied to nodes
Nodes do not receive financial reward.\
But they do receive **sovereign security**:
* control over their rules
* protection against inflation
* independent validation
* not relying on third parties
The incentive is:
> “I verify my own coins → I guarantee their value.”
***
## 13. Sovereignty and full nodes
A full node is:
* a tool of financial self-defense
* a mechanism for independent verification
* a wall against inflation
* a regulator of consensus
* a technical “vote,” not a political one
Nodes:
* validate
* reject
* protect
* synchronize
* preserve history
***
## 14. Propagation mathematics
The average propagation time:
T_{prop} \approx \log(N)
N = number of nodes (\~15k public + unknown private)
This enables:
* fast consensus
* low latency
* minimal desynchronization
***
## 15. Orphan block scenario
If two miners find blocks at the same time:
* both propagate
* each node temporarily chooses one
* eventually one is discarded (orphan block)
Accumulated PoW resolves the race.
***
## 16. Future of the P2P protocol
Improvements in development:
* Erlay (more efficient relay)
* Forward Block Relay
* BIP324 (encryption of P2P connections)
* BlockTorrent (proposed)
***
## 17. Chapter conclusion
The Bitcoin P2P network is:
* decentralized
* resistant to attacks
* efficient
* flexible
* self-organizing
* sovereign
* verifiable
* robust against censorship
Full nodes are the **backbone of consensus**, more important than miners.\
**Without nodes, there are no rules.**\
**Without rules, there is no Bitcoin.**
In the next chapter we will delve into **the system's economy**, analyzing advanced monetary theory applied to Bitcoin.
***
> Running a full node is like owning a monetary firewall that defends your savings.
***
---
# 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://www.notbank.com/learn/academy/en/bitcoin/p2p-networks.md?ask=&goal=
```
`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.