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?

2 Answers 2


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.

  • 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
    Commented Mar 16, 2016 at 15:28
  • 1
    @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
    Commented Mar 16, 2016 at 15:36
  • 3
    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. Commented Mar 22, 2016 at 6:07

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.


  • 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
    Commented Mar 22, 2016 at 11:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.