---
title: P2P Network
description: "# P2P Network The Bitcoin network protocol allows full nodes (peers) to collaboratively maintain a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network for [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction exchange. ## Introduction Full nodes download and verify every [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction prior to relaying them to other nodes.…"
url: "https://bitcoindevelopers.org/docs/developer-guides/p2p-network/"
updated: "2025-05-13"
category: Developer Guides
---

# P2P Network

# P2P Network

The Bitcoin network protocol allows full nodes (peers) to collaboratively maintain a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network for [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction exchange.

## Introduction

Full nodes download and verify every [Block](https://bitcoindevelopers.org/encyclopedia/block/) and transaction prior to relaying them to other nodes. Archival nodes are full nodes which store the entire blockchain and can serve historical blocks to other nodes. Pruned nodes are full nodes which do not store the entire blockchain. Many [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients also use the Bitcoin network protocol to connect to full nodes.

[Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) do not cover networking, so Bitcoin programs may use alternative networks and protocols, such as the high-speed [Block](https://bitcoindevelopers.org/encyclopedia/block/) relay network used by some miners and the dedicated transaction information servers used by some wallets that provide [SPV](https://bitcoindevelopers.org/encyclopedia/spv/)-level security.

To provide practical examples of the Bitcoin [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network, this section uses Bitcoin Core as a representative full [Node](https://bitcoindevelopers.org/encyclopedia/node/) and BitcoinJ as a representative [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client. Both programs are flexible, so only default behavior is described. Also, for privacy, actual IP addresses in the example [Output](https://bitcoindevelopers.org/encyclopedia/output/) below have been replaced with RFC5737 reserved IP addresses.

## [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) Discovery

When started for the first time, programs don’t know the IP addresses of any active full nodes. In order to discover some IP addresses, they query one or more DNS names (called DNS seeds) hardcoded into Bitcoin Core and BitcoinJ. The response to the lookup should include one or more DNS A records with the IP addresses of full nodes that may accept new incoming connections. For example, using the Unix ``dig` command `__:

```
;; QUESTION SECTION:
;seed.bitcoin.sipa.be.      IN  A

;; ANSWER SECTION:
seed.bitcoin.sipa.be.   60  IN  A  192.0.2.113
seed.bitcoin.sipa.be.   60  IN  A  198.51.100.231
seed.bitcoin.sipa.be.   60  IN  A  203.0.113.183
[...]
```

The DNS seeds are maintained by Bitcoin community members: some of them provide dynamic [DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) servers which automatically get IP addresses of active nodes by scanning the network; others provide static DNS seeds that are updated manually and are more likely to provide IP addresses for inactive nodes. In either case, nodes are added to the [DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) if they run on the default Bitcoin ports of 8333 for [Mainnet](https://bitcoindevelopers.org/encyclopedia/mainnet/) or 18333 for [Testnet](https://bitcoindevelopers.org/encyclopedia/testnet/).

[DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) results are not authenticated and a malicious seed operator or network man-in-the-middle attacker can return only IP addresses of nodes controlled by the attacker, isolating a program on the attacker’s own network and allowing the attacker to feed it bogus transactions and blocks. For this reason, programs should not rely on DNS seeds exclusively.

Once a program has connected to the network, its peers can begin to send it `addr` ([Address](https://bitcoindevelopers.org/encyclopedia/address/)) messages with the IP addresses and port numbers of other peers on the network, providing a fully decentralized method of [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) discovery. Bitcoin Core keeps a record of known peers in a persistent on-disk database which usually allows it to connect directly to those peers on subsequent startups without having to use DNS seeds.

However, peers often leave the network or change IP addresses, so programs may need to make several different connection attempts at startup before a successful connection is made. This can add a significant delay to the amount of time it takes to connect to the network, forcing a user to wait before sending a transaction or checking the status of payment.

To avoid this possible delay, BitcoinJ always uses dynamic DNS seeds to get IP addresses for nodes believed to be currently active. Bitcoin Core also tries to strike a balance between minimizing delays and avoiding unnecessary [DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) use: if Bitcoin Core has entries in its [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) database, it spends up to 11 seconds attempting to connect to at least one of them before falling back to seeds; if a connection is made within that time, it does not query any seeds.

Both Bitcoin Core and BitcoinJ also include a hardcoded list of IP addresses and port numbers to several dozen nodes which were active around the time that particular version of the software was first released. Bitcoin Core will start attempting to connect to these nodes if none of the [DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) servers have responded to a query within 60 seconds, providing an automatic fallback option.

As a manual fallback option, Bitcoin Core also provides several command-line connection options, including the ability to get a list of peers from a specific [Node](https://bitcoindevelopers.org/encyclopedia/node/) by IP [Address](https://bitcoindevelopers.org/encyclopedia/address/), or to make a persistent connection to a specific [Node](https://bitcoindevelopers.org/encyclopedia/node/) by IP [Address](https://bitcoindevelopers.org/encyclopedia/address/). See the `-help` text for details. BitcoinJ can be programmed to do the same thing.

**Resources:** Bitcoin Seeder, the program run by several of the seeds used by Bitcoin Core and BitcoinJ. The Bitcoin Core [DNS seed](https://bitcoindevelopers.org/encyclopedia/dns-seed/) Policy. The hardcoded list of IP addresses used by Bitcoin Core and BitcoinJ is generated using the makeseeds script.

## Connecting To Peers

Connecting to a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) is done by sending a “version” [Message](https://bitcoindevelopers.org/encyclopedia/message/), which contains your version number, [Block](https://bitcoindevelopers.org/encyclopedia/block/), and current time to the remote [Node](https://bitcoindevelopers.org/encyclopedia/node/). The remote [Node](https://bitcoindevelopers.org/encyclopedia/node/) responds with its own “version” [Message](https://bitcoindevelopers.org/encyclopedia/message/). Then both nodes send a “verack” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to the other [Node](https://bitcoindevelopers.org/encyclopedia/node/) to indicate the connection has been established.

Once connected, the client can send to the remote [Node](https://bitcoindevelopers.org/encyclopedia/node/) `getaddr` and “addr” messages to gather additional peers.

In order to maintain a connection with a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/), nodes by default will send a [Message](https://bitcoindevelopers.org/encyclopedia/message/) to peers before 30 minutes of inactivity. If 90 minutes pass without a [Message](https://bitcoindevelopers.org/encyclopedia/message/) being received by a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/), the client will assume that connection has closed.

## Initial [Block](https://bitcoindevelopers.org/encyclopedia/block/) Download

Before a full [Node](https://bitcoindevelopers.org/encyclopedia/node/) can validate unconfirmed transactions and recently-mined blocks, it must download and validate all blocks from [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1 (the [Block](https://bitcoindevelopers.org/encyclopedia/block/) after the hardcoded genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/)) to the current tip of the best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. This is the Initial [Block](https://bitcoindevelopers.org/encyclopedia/block/) Download ([IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)) or initial sync.

Although the word “initial” implies this method is only used once, it can also be used any time a large number of blocks need to be downloaded, such as when a previously-caught-up [Node](https://bitcoindevelopers.org/encyclopedia/node/) has been offline for a long time. In this case, a [Node](https://bitcoindevelopers.org/encyclopedia/node/) can use the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) method to download all the blocks which were produced since the last time it was online.

Bitcoin Core uses the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) method any time the last [Block](https://bitcoindevelopers.org/encyclopedia/block/) on its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain has a [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) time more than 24 hours in the past. Bitcoin Core 0.10.0 will also perform [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) if its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain is more than 144 blocks lower than its local best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/) (that is, the local [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain is more than about 24 hours in the past).

### Blocks-First

Bitcoin Core (up until version 0.9.3) uses a simple initial [Block](https://bitcoindevelopers.org/encyclopedia/block/) download ([IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)) method we’ll call *blocks-first*. The goal is to download the blocks from the best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain in sequence.

  ![Overview Of Blocks-First Method](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-blocks-first-flowchart.svg)

Overview Of Blocks-First Method

The first time a [Node](https://bitcoindevelopers.org/encyclopedia/node/) is started, it only has a single [Block](https://bitcoindevelopers.org/encyclopedia/block/) in its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain—the hardcoded genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) ([Block](https://bitcoindevelopers.org/encyclopedia/block/) 0). This [Node](https://bitcoindevelopers.org/encyclopedia/node/) chooses a remote [Peer](https://bitcoindevelopers.org/encyclopedia/peer/), called the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/), and sends it the “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/) illustrated below.

  ![First GetBlocks Message Sent During IBD](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-getblocks.svg)

First GetBlocks [Message](https://bitcoindevelopers.org/encyclopedia/message/) Sent During [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)

In the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes field of the “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/), this new [Node](https://bitcoindevelopers.org/encyclopedia/node/) sends the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash of the only [Block](https://bitcoindevelopers.org/encyclopedia/block/) it has, the genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) (6fe2…0000 in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/)). It also sets the stop hash field to all zeroes to request a maximum-size response.

Upon [Receipt](https://bitcoindevelopers.org/encyclopedia/receipt/) of the “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) takes the first (and only) [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash and searches its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain for a [Block](https://bitcoindevelopers.org/encyclopedia/block/) with that [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash. It finds that [Block](https://bitcoindevelopers.org/encyclopedia/block/) 0 matches, so it replies with 500 [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories (the maximum response to a “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/)) starting from [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1. It sends these inventories in the “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) illustrated below.

  ![First Inv Message Sent During IBD](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-inv.svg)

First Inv [Message](https://bitcoindevelopers.org/encyclopedia/message/) Sent During [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)

Inventories are unique identifiers for information on the network. Each [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/) contains a type field and the unique identifier for an instance of the object. For blocks, the unique identifier is a hash of the [Block](https://bitcoindevelopers.org/encyclopedia/block/)’s [Header](https://bitcoindevelopers.org/encyclopedia/header/).

The [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories appear in the “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) in the same order they appear in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, so this first “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) contains inventories for blocks 1 through 501. (For example, the hash of [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1 is 4860…0000 as seen in the illustration above.)

The [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) uses the received inventories to request 128 blocks from the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) in the “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/) illustrated below.

  ![First GetData Message Sent During IBD](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-getdata.svg)

First GetData [Message](https://bitcoindevelopers.org/encyclopedia/message/) Sent During [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)

It’s important to blocks-first nodes that the blocks be requested and sent in order because each [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) references the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash of the preceding [Block](https://bitcoindevelopers.org/encyclopedia/block/). That means the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) can’t fully validate a [Block](https://bitcoindevelopers.org/encyclopedia/block/) until its parent [Block](https://bitcoindevelopers.org/encyclopedia/block/) has been received. Blocks that can’t be validated because their parents haven’t been received are called orphan blocks; a subsection below describes them in more detail.

Upon [Receipt](https://bitcoindevelopers.org/encyclopedia/receipt/) of the “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) replies with each of the blocks requested. Each [Block](https://bitcoindevelopers.org/encyclopedia/block/) is put into [Serialized block](https://bitcoindevelopers.org/encyclopedia/serialized-block/) format and sent in a separate “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/). The first “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/) sent (for [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1) is illustrated below.

  ![First Block Message Sent During IBD](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-block.svg)

First [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Message](https://bitcoindevelopers.org/encyclopedia/message/) Sent During [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)

The [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) downloads each [Block](https://bitcoindevelopers.org/encyclopedia/block/), validates it, and then requests the next [Block](https://bitcoindevelopers.org/encyclopedia/block/) it hasn’t requested yet, maintaining a queue of up to 128 blocks to download. When it has requested every [Block](https://bitcoindevelopers.org/encyclopedia/block/) for which it has an [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/), it sends another “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) requesting the inventories of up to 500 more blocks. This second “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/) contains multiple [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes as illustrated below:

  ![Second GetBlocks Message Sent During IBD](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-getblocks2.svg)

Second GetBlocks [Message](https://bitcoindevelopers.org/encyclopedia/message/) Sent During [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)

Upon [Receipt](https://bitcoindevelopers.org/encyclopedia/receipt/) of the second “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) searches its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain for a [Block](https://bitcoindevelopers.org/encyclopedia/block/) that matches one of the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes in the [Message](https://bitcoindevelopers.org/encyclopedia/message/), trying each hash in the order they were received. If it finds a matching hash, it replies with 500 [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories starting with the next [Block](https://bitcoindevelopers.org/encyclopedia/block/) from that point. But if there is no matching hash (besides the stopping hash), it assumes the only [Block](https://bitcoindevelopers.org/encyclopedia/block/) the two nodes have in common is [Block](https://bitcoindevelopers.org/encyclopedia/block/) 0 and so it sends an `inv` starting with [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1 (the same “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) seen several illustrations above).

This repeated search allows the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) to send useful inventories even if the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/)’s local [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain forked from the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/)’s local [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. This [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) detection becomes increasingly useful the closer the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) gets to the tip of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

When the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) receives the second “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/), it will request those blocks using “getdata” messages. The sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) will respond with “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” messages. Then the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) will request more inventories with another “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/)—and the cycle will repeat until the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) is synced to the tip of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. At that point, the [Node](https://bitcoindevelopers.org/encyclopedia/node/) will accept blocks sent through the regular [Block](https://bitcoindevelopers.org/encyclopedia/block/) broadcasting described in a later subsection.

#### Blocks-First Advantages & Disadvantages

The primary advantage of blocks-first [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) is its simplicity. The primary disadvantage is that the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) relies on a single sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) for all of its downloading. This has several implications:

- **Speed Limits:** All requests are made to the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/), so if the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) has limited upload bandwidth, the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) will have slow download speeds. Note: if the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) goes offline, Bitcoin Core will continue downloading from another [Node](https://bitcoindevelopers.org/encyclopedia/node/)—but it will still only download from a single sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) at a time.
- **Download Restarts:** The sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) can send a non-best (but otherwise valid) [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain to the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/). The [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) won’t be able to identify it as non-best until the initial [Block](https://bitcoindevelopers.org/encyclopedia/block/) download nears completion, forcing the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) to restart its [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain download over again from a different [Node](https://bitcoindevelopers.org/encyclopedia/node/). Bitcoin Core ships with several [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain checkpoints at various [Block](https://bitcoindevelopers.org/encyclopedia/block/) heights selected by developers to help an [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) detect that it is being fed an alternative [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain history—allowing the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) to restart its download earlier in the process.
- **Disk Fill Attacks:** Closely related to the download restarts, if the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) sends a non-best (but otherwise valid) [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, the chain will be stored on disk, wasting space and possibly filling up the disk drive with useless data.
- **High Memory Use:** Whether maliciously or by accident, the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) can send blocks out of order, creating orphan blocks which can’t be validated until their parents have been received and validated. Orphan blocks are stored in memory while they await validation, which may lead to high memory use.

All of these problems are addressed in part or in full by the headers-first [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) method used in Bitcoin Core 0.10.0.

**Resources:** The table below summarizes the messages mentioned throughout this subsection. The links in the [Message](https://bitcoindevelopers.org/encyclopedia/message/) field will take you to the reference page for that [Message](https://bitcoindevelopers.org/encyclopedia/message/).

| [Message](https://bitcoindevelopers.org/encyclopedia/message/) | From→To | Payload |
| --- | --- | --- |
| “getblocks” | [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)→Sync | One or more [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes |
| “inv” | Sync→[IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) | Up to 500 [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories (unique identifiers) |
| “getdata” | [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)→Sync | One or more [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories |
| “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” | Sync→[IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) | One [Serialized block](https://bitcoindevelopers.org/encyclopedia/serialized-block/) |

### Headers-First

Bitcoin Core 0.10.0 uses an initial [Block](https://bitcoindevelopers.org/encyclopedia/block/) download ([IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)) method called *headers-first*. The goal is to download the headers for the best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/), partially validate them as best as possible, and then download the corresponding blocks in parallel. This solves several problems with the older blocks-first [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) method.

  ![Overview Of Headers-First Method](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-headers-first-flowchart.svg)

Overview Of Headers-First Method

The first time a [Node](https://bitcoindevelopers.org/encyclopedia/node/) is started, it only has a single [Block](https://bitcoindevelopers.org/encyclopedia/block/) in its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain—the hardcoded genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) ([Block](https://bitcoindevelopers.org/encyclopedia/block/) 0). The [Node](https://bitcoindevelopers.org/encyclopedia/node/) chooses a remote [Peer](https://bitcoindevelopers.org/encyclopedia/peer/), which we’ll call the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/), and sends it the “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) illustrated below.

  ![First getheaders message](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-getheaders.svg)

First getheaders [Message](https://bitcoindevelopers.org/encyclopedia/message/)

In the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes field of the “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the new [Node](https://bitcoindevelopers.org/encyclopedia/node/) sends the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash of the only [Block](https://bitcoindevelopers.org/encyclopedia/block/) it has, the genesis [Block](https://bitcoindevelopers.org/encyclopedia/block/) (6fe2…0000 in [Internal byte order](https://bitcoindevelopers.org/encyclopedia/internal-byte-order/)). It also sets the stop hash field to all zeroes to request a maximum-size response.

Upon [Receipt](https://bitcoindevelopers.org/encyclopedia/receipt/) of the “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) takes the first (and only) [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash and searches its local best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain for a [Block](https://bitcoindevelopers.org/encyclopedia/block/) with that [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash. It finds that [Block](https://bitcoindevelopers.org/encyclopedia/block/) 0 matches, so it replies with 2,000 [Header](https://bitcoindevelopers.org/encyclopedia/header/) (the maximum response) starting from [Block](https://bitcoindevelopers.org/encyclopedia/block/) 1. It sends these [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes in the “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/) illustrated below.

  ![First headers message](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-ibd-headers.svg)

First headers [Message](https://bitcoindevelopers.org/encyclopedia/message/)

The [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) can partially validate these [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers by ensuring that all fields follow [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) and that the hash of the [Header](https://bitcoindevelopers.org/encyclopedia/header/) is below the [Target](https://bitcoindevelopers.org/encyclopedia/target/) threshold according to the [nBits](https://bitcoindevelopers.org/encyclopedia/nbits/) field. (Full validation still requires all transactions from the corresponding [Block](https://bitcoindevelopers.org/encyclopedia/block/).)

After the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) has partially validated the [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers, it can do two things in parallel:

1. **Download More Headers:** the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) can send another “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) to request the next 2,000 headers on the best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/). Those headers can be immediately validated and another batch requested repeatedly until a “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/) is received from the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) with fewer than 2,000 headers, indicating that it has no more headers to offer. As of this writing, headers sync can be completed in fewer than 200 round trips, or about 32 MB of downloaded data.

   Once the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) receives a “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/) with fewer than 2,000 headers from the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/), it sends a “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to each of its outbound peers to get their view of best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/). By comparing the responses, it can easily determine if the headers it has downloaded belong to the best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/) reported by any of its outbound peers. This means a dishonest sync [Node](https://bitcoindevelopers.org/encyclopedia/node/) will quickly be discovered even if checkpoints aren’t used (as long as the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) connects to at least one honest [Peer](https://bitcoindevelopers.org/encyclopedia/peer/); Bitcoin Core will continue to provide checkpoints in case honest peers can’t be found).
2. **Download Blocks:** While the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) continues downloading headers, and after the headers finish downloading, the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) will request and download each [Block](https://bitcoindevelopers.org/encyclopedia/block/). The [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) can use the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes it computed from the [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/) to create “getdata” messages that request the blocks it needs by their [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/). It doesn’t need to request these from the sync [Node](https://bitcoindevelopers.org/encyclopedia/node/)—it can request them from any of its full [Node](https://bitcoindevelopers.org/encyclopedia/node/) peers. (Although not all full nodes may store all blocks.) This allows it to fetch blocks in parallel and avoid having its download speed constrained to the upload speed of a single sync [Node](https://bitcoindevelopers.org/encyclopedia/node/).

   To spread the load between multiple peers, Bitcoin Core will only request up to 16 blocks at a time from a single [Peer](https://bitcoindevelopers.org/encyclopedia/peer/). Combined with its maximum of 8 outbound connections, this means headers-first Bitcoin Core will request a maximum of 128 blocks simultaneously during [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) (the same maximum number that blocks-first Bitcoin Core requested from its sync [Node](https://bitcoindevelopers.org/encyclopedia/node/)).

  ![Simulated Headers-First Download Window](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-headers-first-moving-window.svg)

Simulated Headers-First Download Window

Bitcoin Core’s headers-first mode uses a 1,024-[Block](https://bitcoindevelopers.org/encyclopedia/block/) moving download window to maximize download speed. The lowest-[Height](https://bitcoindevelopers.org/encyclopedia/height/) [Block](https://bitcoindevelopers.org/encyclopedia/block/) in the window is the next [Block](https://bitcoindevelopers.org/encyclopedia/block/) to be validated; if the [Block](https://bitcoindevelopers.org/encyclopedia/block/) hasn’t arrived by the time Bitcoin Core is ready to validate it, Bitcoin Core will wait a minimum of two more seconds for the stalling [Node](https://bitcoindevelopers.org/encyclopedia/node/) to send the [Block](https://bitcoindevelopers.org/encyclopedia/block/). If the [Block](https://bitcoindevelopers.org/encyclopedia/block/) still hasn’t arrived, Bitcoin Core will disconnect from the stalling [Node](https://bitcoindevelopers.org/encyclopedia/node/) and attempt to connect to another [Node](https://bitcoindevelopers.org/encyclopedia/node/). For example, in the illustration above, [Node](https://bitcoindevelopers.org/encyclopedia/node/) A will be disconnected if it doesn’t send [Block](https://bitcoindevelopers.org/encyclopedia/block/) 3 within at least two seconds.

Once the [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) [Node](https://bitcoindevelopers.org/encyclopedia/node/) is synced to the tip of the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, it will accept blocks sent through the regular [Block](https://bitcoindevelopers.org/encyclopedia/block/) broadcasting described in a later subsection.

**Resources:** The table below summarizes the messages mentioned throughout this subsection. The links in the [Message](https://bitcoindevelopers.org/encyclopedia/message/) field will take you to the reference page for that [Message](https://bitcoindevelopers.org/encyclopedia/message/).

| [Message](https://bitcoindevelopers.org/encyclopedia/message/) | From→To | Payload |
| --- | --- | --- |
| “getheaders” | [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)→Sync | One or more [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes |
| “headers” | Sync→[IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) | Up to 2,000 [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers |
| “getdata” | [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/)→*Many* | One or more [Block](https://bitcoindevelopers.org/encyclopedia/block/) inventories derived from [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes |
| “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” | *Many*→[IBD](https://bitcoindevelopers.org/encyclopedia/ibd/) | One [Serialized block](https://bitcoindevelopers.org/encyclopedia/serialized-block/) |

## [Block](https://bitcoindevelopers.org/encyclopedia/block/) Broadcasting

When a [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) discovers a new [Block](https://bitcoindevelopers.org/encyclopedia/block/), it broadcasts the new [Block](https://bitcoindevelopers.org/encyclopedia/block/) to its peers using one of the following methods:

- [Unsolicited block push](https://bitcoindevelopers.org/encyclopedia/unsolicited-block-push/)**:** the [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) sends a “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to each of its full [Node](https://bitcoindevelopers.org/encyclopedia/node/) peers with the new [Block](https://bitcoindevelopers.org/encyclopedia/block/). The [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) can reasonably bypass the standard relay method in this way because it knows none of its peers already have the just-discovered [Block](https://bitcoindevelopers.org/encyclopedia/block/).
- Standard [Block](https://bitcoindevelopers.org/encyclopedia/block/) Relay**:** the [Miner](https://bitcoindevelopers.org/encyclopedia/miner/), acting as a standard relay [Node](https://bitcoindevelopers.org/encyclopedia/node/), sends an “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to each of its peers (both full [Node](https://bitcoindevelopers.org/encyclopedia/node/) and [SPV](https://bitcoindevelopers.org/encyclopedia/spv/)) with an [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/) referring to the new [Block](https://bitcoindevelopers.org/encyclopedia/block/). The most common responses are:

  - Each blocks-first (BF) [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) that wants the [Block](https://bitcoindevelopers.org/encyclopedia/block/) replies with a “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/) requesting the full [Block](https://bitcoindevelopers.org/encyclopedia/block/).
  - Each headers-first (HF) [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) that wants the [Block](https://bitcoindevelopers.org/encyclopedia/block/) replies with a “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) containing the [Header](https://bitcoindevelopers.org/encyclopedia/header/) hash of the highest-[Height](https://bitcoindevelopers.org/encyclopedia/height/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) on its best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/), and likely also some headers further back on the best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/) to allow [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) detection. That [Message](https://bitcoindevelopers.org/encyclopedia/message/) is immediately followed by a “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/) requesting the full [Block](https://bitcoindevelopers.org/encyclopedia/block/). By requesting headers first, a headers-first [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) can refuse orphan blocks as described in the subsection below.
  - Each [Simplified Payment Verification](https://bitcoindevelopers.org/encyclopedia/simplified-payment-verification/) ([SPV](https://bitcoindevelopers.org/encyclopedia/spv/)) client that wants the [Block](https://bitcoindevelopers.org/encyclopedia/block/) replies with a “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/) typically requesting a [Merkle block](https://bitcoindevelopers.org/encyclopedia/merkle-block/).

  The [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) replies to each request accordingly by sending the [Block](https://bitcoindevelopers.org/encyclopedia/block/) in a “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/), one or more headers in a “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/), or the [Merkle block](https://bitcoindevelopers.org/encyclopedia/merkle-block/) and transactions relative to the [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client’s [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) in a “[MerkleBlock](https://bitcoindevelopers.org/encyclopedia/merkleblock/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/) followed by zero or more “tx” messages.
- Direct Headers Announcement**:** a relay [Node](https://bitcoindevelopers.org/encyclopedia/node/) may skip the round trip overhead of an “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) followed by `getheaders` by instead immediately sending a “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/) containing the full [Header](https://bitcoindevelopers.org/encyclopedia/header/) of the new [Block](https://bitcoindevelopers.org/encyclopedia/block/). A HF [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) receiving this [Message](https://bitcoindevelopers.org/encyclopedia/message/) will partially validate the [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) as it would during headers-first [IBD](https://bitcoindevelopers.org/encyclopedia/ibd/), then request the full [Block](https://bitcoindevelopers.org/encyclopedia/block/) contents with a “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/) if the [Header](https://bitcoindevelopers.org/encyclopedia/header/) is valid. The relay [Node](https://bitcoindevelopers.org/encyclopedia/node/) then responds to the `getdata` request with the full or filtered [Block](https://bitcoindevelopers.org/encyclopedia/block/) data in a `Block` or “[MerkleBlock](https://bitcoindevelopers.org/encyclopedia/merkleblock/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/), respectively. A HF [Node](https://bitcoindevelopers.org/encyclopedia/node/) may signal that it prefers to receive `headers` instead of `inv` announcements by sending a special “sendheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) during the connection handshake.

  This protocol for [Block](https://bitcoindevelopers.org/encyclopedia/block/) broadcasting was proposed in BIP 130 and has been implemented in Bitcoin Core since version 0.12.

By default, Bitcoin Core broadcasts blocks using direct headers announcement to any peers that have signalled with “sendheaders” and uses standard [Block](https://bitcoindevelopers.org/encyclopedia/block/) relay for all peers that have not. Bitcoin Core will accept blocks sent using any of the methods described above.

Full nodes validate the received [Block](https://bitcoindevelopers.org/encyclopedia/block/) and then advertise it to their peers using the standard [Block](https://bitcoindevelopers.org/encyclopedia/block/) relay method described above. The condensed table below highlights the operation of the messages described above (Relay, BF, HF, and [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) refer to the relay [Node](https://bitcoindevelopers.org/encyclopedia/node/), a blocks-first [Node](https://bitcoindevelopers.org/encyclopedia/node/), a headers-first [Node](https://bitcoindevelopers.org/encyclopedia/node/), and an [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) client; *any* refers to a [Node](https://bitcoindevelopers.org/encyclopedia/node/) using any [Block](https://bitcoindevelopers.org/encyclopedia/block/) retrieval method.)

| [Message](https://bitcoindevelopers.org/encyclopedia/message/) | From→To | Payload |
| --- | --- | --- |
| “inv” | Relay→*Any* | The [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/) of the new [Block](https://bitcoindevelopers.org/encyclopedia/block/) |
| “getdata” | BF→Relay | The [Inventory](https://bitcoindevelopers.org/encyclopedia/inventory/) of the new [Block](https://bitcoindevelopers.org/encyclopedia/block/) |
| “getheaders” | HF→Relay | One or more [Header](https://bitcoindevelopers.org/encyclopedia/header/) hashes on the HF [Node](https://bitcoindevelopers.org/encyclopedia/node/)’s best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/) (BHC) |
| “headers” | Relay→HF | Up to 2,000 headers connecting HF [Node](https://bitcoindevelopers.org/encyclopedia/node/)’s BHC to relay [Node](https://bitcoindevelopers.org/encyclopedia/node/)’s BHC |
| “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” | Relay→BF/HF | The new [Block](https://bitcoindevelopers.org/encyclopedia/block/) in serialized format |
| “[MerkleBlock](https://bitcoindevelopers.org/encyclopedia/merkleblock/)” | Relay→[SPV](https://bitcoindevelopers.org/encyclopedia/spv/) | The new [Block](https://bitcoindevelopers.org/encyclopedia/block/) filtered into a [Merkle block](https://bitcoindevelopers.org/encyclopedia/merkle-block/) |
| “tx” | Relay→[SPV](https://bitcoindevelopers.org/encyclopedia/spv/) | Serialized transactions from the new [Block](https://bitcoindevelopers.org/encyclopedia/block/) that match the [Bloom filter](https://bitcoindevelopers.org/encyclopedia/bloom-filter/) |

### Orphan Blocks

Blocks-first nodes may download orphan blocks—blocks whose [Previous block header hash](https://bitcoindevelopers.org/encyclopedia/previous-block-header-hash/) field refers to a [Block](https://bitcoindevelopers.org/encyclopedia/block/) [Header](https://bitcoindevelopers.org/encyclopedia/header/) this [Node](https://bitcoindevelopers.org/encyclopedia/node/) hasn’t seen yet. In other words, orphan blocks have no known parent (unlike stale blocks, which have known parents but which aren’t part of the best [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain).

  ![Difference Between Orphan And Stale Blocks](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-orphan-stale-definition.svg)

Difference Between Orphan And Stale Blocks

When a blocks-first [Node](https://bitcoindevelopers.org/encyclopedia/node/) downloads an [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/), it will not validate it. Instead, it will send a “getblocks” [Message](https://bitcoindevelopers.org/encyclopedia/message/) to the [Node](https://bitcoindevelopers.org/encyclopedia/node/) which sent the [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/); the broadcasting [Node](https://bitcoindevelopers.org/encyclopedia/node/) will respond with an “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) containing inventories of any blocks the downloading [Node](https://bitcoindevelopers.org/encyclopedia/node/) is missing (up to 500); the downloading [Node](https://bitcoindevelopers.org/encyclopedia/node/) will request those blocks with a “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/); and the broadcasting [Node](https://bitcoindevelopers.org/encyclopedia/node/) will send those blocks with a “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/). The downloading [Node](https://bitcoindevelopers.org/encyclopedia/node/) will validate those blocks, and once the parent of the former [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/) has been validated, it will validate the former [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/).

Headers-first nodes avoid some of this complexity by always requesting [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers with the “getheaders” [Message](https://bitcoindevelopers.org/encyclopedia/message/) before requesting a [Block](https://bitcoindevelopers.org/encyclopedia/block/) with the “getdata” [Message](https://bitcoindevelopers.org/encyclopedia/message/). The broadcasting [Node](https://bitcoindevelopers.org/encyclopedia/node/) will send a “headers” [Message](https://bitcoindevelopers.org/encyclopedia/message/) containing all the [Block](https://bitcoindevelopers.org/encyclopedia/block/) headers (up to 2,000) it thinks the downloading [Node](https://bitcoindevelopers.org/encyclopedia/node/) needs to reach the tip of the best [Header chain](https://bitcoindevelopers.org/encyclopedia/header-chain/); each of those headers will point to its parent, so when the downloading [Node](https://bitcoindevelopers.org/encyclopedia/node/) receives the “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/), the [Block](https://bitcoindevelopers.org/encyclopedia/block/) shouldn’t be an [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/)—all of its parents should be known (even if they haven’t been validated yet). If, despite this, the [Block](https://bitcoindevelopers.org/encyclopedia/block/) received in the “[Block](https://bitcoindevelopers.org/encyclopedia/block/)” [Message](https://bitcoindevelopers.org/encyclopedia/message/) is an [Orphan block](https://bitcoindevelopers.org/encyclopedia/orphan-block/), a headers-first [Node](https://bitcoindevelopers.org/encyclopedia/node/) will discard it immediately.

However, orphan discarding does mean that headers-first nodes will ignore orphan blocks sent by miners in an [Unsolicited block push](https://bitcoindevelopers.org/encyclopedia/unsolicited-block-push/).

## Transaction Broadcasting

In order to send a transaction to a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/), an “inv” [Message](https://bitcoindevelopers.org/encyclopedia/message/) is sent. If a `getdata` response [Message](https://bitcoindevelopers.org/encyclopedia/message/) is received, the transaction is sent using `tx`. The [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) receiving this transaction also forwards the transaction in the same manner, given that it is a valid transaction.

### Memory Pool

Full peers may keep track of unconfirmed transactions which are eligible to be included in the next [Block](https://bitcoindevelopers.org/encyclopedia/block/). This is essential for miners who will actually mine some or all of those transactions, but it’s also useful for any [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) who wants to keep track of unconfirmed transactions, such as peers serving [Unconfirmed transaction](https://bitcoindevelopers.org/encyclopedia/unconfirmed-transaction/) information to [SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients.

Because unconfirmed transactions have no permanent status in Bitcoin, Bitcoin Core stores them in non-persistent memory, calling them a memory pool or mempool. When a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) shuts down, its memory pool is lost except for any transactions stored by its [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/). This means that never-mined unconfirmed transactions tend to slowly disappear from the network as peers restart or as they purge some transactions to make room in memory for others.

Transactions which are mined into blocks that later become stale blocks may be added back into the memory pool. These re-added transactions may be re-removed from the pool almost immediately if the replacement blocks include them. This is the case in Bitcoin Core, which removes stale blocks from the chain one by one, starting with the tip (highest [Block](https://bitcoindevelopers.org/encyclopedia/block/)). As each [Block](https://bitcoindevelopers.org/encyclopedia/block/) is removed, its transactions are added back to the memory pool. After all of the stale blocks are removed, the replacement blocks are added to the chain one by one, ending with the new tip. As each [Block](https://bitcoindevelopers.org/encyclopedia/block/) is added, any transactions it confirms are removed from the memory pool.

[SPV](https://bitcoindevelopers.org/encyclopedia/spv/) clients don’t have a memory pool for the same reason they don’t relay transactions. They can’t independently verify that a transaction hasn’t yet been included in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) and that it only spends UTXOs, so they can’t know which transactions are eligible to be included in the next [Block](https://bitcoindevelopers.org/encyclopedia/block/).

## Misbehaving Nodes

Take note that for both types of broadcasting, mechanisms are in place to punish misbehaving peers who take up bandwidth and computing resources by sending false information. If a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) gets a banscore above the `-banscore=<n>` threshold, he will be banned for the number of seconds defined by `-bantime=<n>`, which is 86,400 by default (24 hours).

## Alerts

*Removed in*Bitcoin Core 0.13.0

Earlier versions of Bitcoin Core allowed developers and trusted community members to issue Bitcoin alerts to notify users of critical network-wide issues. This messaging system was retired in Bitcoin Core v0.13.0; however, internal alerts, partition detection warnings and the `-alertnotify` option features remain.