> 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/wiki/the-network/the-bitcoin-network/peer-to-peer-network-architecture.md).

# Peer-to-Peer Network Architecture

Peer-to-Peer computing or networking is a distributed application network architecture that shares resources amongst the participants. Participants are called nodes and are said to form a Peer-to-Peer network \[1]. A distributed network architecture is classified as a "Pure" Peer-to-Peer if the removal of any single, arbitrarily chosen, node will not result in the loss of network service.

1. The Bitcoin Peer-to-Peer Network Formally, the Bitcoin network is a Pure Peer-to-Peer network built on top of the internet. In the early days of Bitcoin the network had a flat topological structure, in which users were capable of running full nodes that could perform all of Bitcoin's main functions: transaction creation, transaction validation and mining (see [bitcoinv0.1](https://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html)). However, as the network has grown, the requirements needed to perform each function on the network have evolved creating a necessity for nodes to specialize. Currently, the 3 main functions of the Bitcoin system are, in general, performed by separate actors within the ecosystem. Transaction creation is done by SPV wallets. Transaction validation is done by the Bitcoin SV node client software and mining is a separate function performed using purpose built mining software.
2. Peer-to-Peer Architecture and the Bitcoin Scalability Dispute Peer-to-peer is a term often misused and misunderstood, partly due the philosophical significance of **decentralization** which is seen as a key feature of "blockchain technology". It has also been at the heart of disputes within the Bitcoin community that have lead to contentious ledger duplications that have resulted in the creation of competing blockchains on two occasions as well as generally delayed the development of the technology. The role of transaction validation and mining cannot be dominated by a single entity as the network would cease to provide any cryptographic or game theoretic advantages over existing centralized digital money systems. It is the firm belief of the Bitcoin SV community that scalability can be achieved through specialization whilst maintaining strong security and distribution of the network in a leaderless manner.
3. References
4. Rüdiger Schollmeier, [A Definition of Peer-to-Peer Networking for the Classification of Peer-to-Peer Architectures and Applications](https://www.researchgate.net/publication/3940901_A_Definition_of_Peer-to-Peer_Networking_for_the_Classification_of_Peer-to-Peer_Architectures_and_Applications), Proceedings of the First International Conference on Peer-to-Peer Computing, IEEE (2002).


---

# 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/wiki/the-network/the-bitcoin-network/peer-to-peer-network-architecture.md?ask=<question>&goal=<user_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.