<p>Blocks that are not yet confirmed look this way, so just wait a bit then try again.  Continue checking for x amount of time before declaring it an orphan.  </p>

<p>There may even be other blocks that have not been assigned a place in the blockchain that are ahead of it.  Most blocks are confirmed pretty quickly, but others can take several minutes.  </p>

<p>So far we haven't yet seen clearance times measured in hours.  And if the block size is increased simultaneously with the doubling of the work factor this summer (the first since 2012) we may well see ever longer clearance times.  So as  you encounter these blocks they may be in the pipeline for confirmation.  </p>

<p>If you are operating as a full node you will notice them coming through.  If you can't confirm then your node won't answer at all.  If you are looking at the stream directly be sure to look at when your node chooses to confirm or not.</p>

<p>In other words, don't think you need to do anything manually.  Your node knows what to do.</p>

<p>Cheers</p>

CC BY-SA 3.0
2016-03-22T11:32:09.273Z
Is it possible that you're confusing "confirmed" with "validated"? Confirmation has a very specific meaning in the context of blocks and what you’re describing doesn't match it.
Murch
CC BY-SA 3.0
2016-03-22T04:54:35.313Z
2016-03-22T05:01:49.943Z
2016-03-22T05:01:49.943Z
SDsolar
<p>The Bitcoin client used to download blocks without necessarily knowing if they could connect it to their current chain. If it couldn't connect a block to the genesis block, it would just keep it in memory. This was a waste of memory (up to 750 MB could be used up before it started dropping blocks) and bandwidth (if you drop a block that you need, that wastes bandwidth)</p>

<p>It does something smarter now, though. It builds a chain of block headers to the current tip of the chain, <em>then</em> downloads the block contents. Not only is this simpler, and more resource efficient, it also allows you to download multiple blocks in parallel. Blocks are written to disk as soon as they're downloaded.</p>

<p>Since there's no way that you will receive a block that you didn't ask for, the current Bitcoin client will drop the block and permanently disconnect from the peer that sent it.</p>

CC BY-SA 3.0
2016-03-16T15:28:40.837Z
thanks this is interesting - but my question (perhaps poorly phrased) is different: if i am one of the nodes that maintain the blockchain and I happen to receive a block which i cannot attach to my chain, what do I do with it?
user123933
CC BY-SA 3.0
2016-03-16T15:36:18.133Z
@user123933 Assuming you're running a recent version of Bitcoin, you never asked for it in the first place, so throw it away. If you're running an older version, keep up to 750 of them in memory so that you can attach them later.
Nick ODell
CC BY-SA 3.0
2016-03-22T06:07:26.227Z
Recent versions will actually disconnect and ban peers that repeatedly give them block(header)s with unknown parent. If they follow the protocol, this will never happen, so there is no need to "deal" with it at all.
Pieter Wuille
CC BY-SA 3.0
2016-03-16T14:22:15.027Z
2016-03-22T15:08:08.887Z
2016-03-22T15:08:08.887Z
Nick ODell
<p>Suppose I am a node in the Bitcoin protocol and I receive a block that does not point to any  block in my current chain. Should I keep it on the side, waiting for missing intermediate ones? Should I propagate it? Should I just erase it?</p>

<synchronization><nodes><orphaned-blocks>
How should a node deal with a block that is not connected to the chain?
user123933
# How should a node deal with a block that is not connected to the chain?

(Asked by: username_0 on 2016-03-16)

Suppose I am a node in the Bitcoin protocol and I receive a block that does not point to any block in my current chain. Should I keep it on the side, waiting for missing intermediate ones? Should I propagate it? Should I just erase it?

**Tags:** synchronization, nodes, orphaned-blocks


---

## 2 answers

### Answer by username_3 on 2016-03-16. Score: 3 | Accepted answer

The Bitcoin client used to download blocks without necessarily knowing if they could connect it to their current chain. If it couldn't connect a block to the genesis block, it would just keep it in memory. This was a waste of memory (up to 750 MB could be used up before it started dropping blocks) and bandwidth (if you drop a block that you need, that wastes bandwidth)

It does something smarter now, though. It builds a chain of block headers to the current tip of the chain, *then* downloads the block contents. Not only is this simpler, and more resource efficient, it also allows you to download multiple blocks in parallel. Blocks are written to disk as soon as they're downloaded.

Since there's no way that you will receive a block that you didn't ask for, the current Bitcoin client will drop the block and permanently disconnect from the peer that sent it.

> **Comments:**
> **username_0**: thanks this is interesting - but my question (perhaps poorly phrased) is different: if i am one of the nodes that maintain the blockchain and I happen to receive a block which i cannot attach to my chain, what do I do with it?  
> **username_3**: @username_0 Assuming you're running a recent version of Bitcoin, you never asked for it in the first place, so throw it away. If you're running an older version, keep up to 750 of them in memory so that you can attach them later.  
> **username_4**: Recent versions will actually disconnect and ban peers that repeatedly give them block(header)s with unknown parent. If they follow the protocol, this will never happen, so there is no need to "deal" with it at all.  

---

### Answer by username_1 on 2016-03-22. Score: -3

Blocks that are not yet confirmed look this way, so just wait a bit then try again. Continue checking for x amount of time before declaring it an orphan.

There may even be other blocks that have not been assigned a place in the blockchain that are ahead of it. Most blocks are confirmed pretty quickly, but others can take several minutes.

So far we haven't yet seen clearance times measured in hours. And if the block size is increased simultaneously with the doubling of the work factor this summer (the first since 2012) we may well see ever longer clearance times. So as you encounter these blocks they may be in the pipeline for confirmation.

If you are operating as a full node you will notice them coming through. If you can't confirm then your node won't answer at all. If you are looking at the stream directly be sure to look at when your node chooses to confirm or not.

In other words, don't think you need to do anything manually. Your node knows what to do.

Cheers

> **Comments:**
> **username_2**: Is it possible that you're confusing "confirmed" with "validated"? Confirmation has a very specific meaning in the context of blocks and what you’re describing doesn't match it.  

---

