<p>It will only ever not be present for the genesis block.</p>

<p>A block is not added to the block index until all its ancestors are in there too.</p>

<p>The block index is conceptually a tree: every block can have multiple decendents but only one ancestor. A reorganization is switching from one branch of the tree to another, and does not affect this.</p>

<p>Orphan blocks (in the meaning of blocks without known parent) don't exist anymore since Bitcoin Core 0.10 (we only download blocks after validating their headers, so the parent is never unknown), and even before that, orphan blocks were just stored in a queue in memory and not actually added to the index until their parents were found.</p>

CC BY-SA 3.0
2015-08-10T11:00:23.973Z
2015-08-10T11:00:23.973Z
Pieter Wuille
<p>Does the getblock(hash) RPC call always return a "previousblockhash" field and if not: under what conditions does it not return this?</p>

<p>Background: many algorithms suggest using this field as a way to step back in the blockchain when an orphan or reorganization occurs but the C++ code would indicate this field isn't always present.</p>

<pre><code>if (blockindex-&gt;pprev)
        result.push_back(Pair("previousblockhash", blockindex-&gt;pprev-&gt;GetBlockHash().GetHex()));
</code></pre>

<p>Would that be due to chain reorganizations and orphans? Can anyone explain what dynamics would make this check fail and what the next step would be if it does?</p>

CC BY-SA 3.0
2015-08-08T10:53:20.667Z
Do you really mean orphan blocks, or rather stale blocks? A block can never become an orphan, Bitcoin Core can not connect a block without its previous existing.
Claris
CC BY-SA 3.0
2015-08-08T11:05:22.650Z
I guess stale block might be the term I'm after then. Good observation
Matthew Roberts
CC BY-SA 3.0
2015-08-10T14:06:30.483Z
@Bitcoin Nice analysis, but it's not correct. `getblockheader` was indeed added because `getblock` can fail when a block is pruned, but even then, the index entries remain. See my answer.
Pieter Wuille
CC BY-SA 3.0
2015-08-10T14:10:43.803Z
@PieterWuille Right, that makes a lot more sense.
Claris
<json-rpc>
Is "previousblockhash" always returned from getblock RPC calls?
Matthew Roberts
# Is "previousblockhash" always returned from getblock RPC calls?

(Asked by: username_0 on 2015-08-08)

Does the getblock(hash) RPC call always return a "previousblockhash" field and if not: under what conditions does it not return this?

Background: many algorithms suggest using this field as a way to step back in the blockchain when an orphan or reorganization occurs but the C++ code would indicate this field isn't always present.

```
if (blockindex->pprev)
        result.push_back(Pair("previousblockhash", blockindex->pprev->GetBlockHash().GetHex()));

```

Would that be due to chain reorganizations and orphans? Can anyone explain what dynamics would make this check fail and what the next step would be if it does?

**Tags:** json-rpc

> **Comments:**
> **username_1**: Do you really mean orphan blocks, or rather stale blocks? A block can never become an orphan, Bitcoin Core can not connect a block without its previous existing.  
> **username_0**: I guess stale block might be the term I'm after then. Good observation  
> **username_2**: @Bitcoin Nice analysis, but it's not correct. `getblockheader` was indeed added because `getblock` can fail when a block is pruned, but even then, the index entries remain. See my answer.  
> **username_1**: @username_2 Right, that makes a lot more sense.  

---

## 1 answers

### Answer by username_2 on 2015-08-10. Score: 2 | Accepted answer

It will only ever not be present for the genesis block.

A block is not added to the block index until all its ancestors are in there too.

The block index is conceptually a tree: every block can have multiple decendents but only one ancestor. A reorganization is switching from one branch of the tree to another, and does not affect this.

Orphan blocks (in the meaning of blocks without known parent) don't exist anymore since Bitcoin Core 0.10 (we only download blocks after validating their headers, so the parent is never unknown), and even before that, orphan blocks were just stored in a queue in memory and not actually added to the index until their parents were found.


---

