Is it possible to iterate over all blocks, incl orphans, with the RPC api?

[CuriousCarl]

I'm trying to iterate over all blocks, incl orphans, via the rpc api.

First, these are my assumptions. Please tell if these are correct:

• Orphaned blocks are valid blocks.
• Orphaned blocks contains valid transactions.
• The transactions in an orphaned blocks can only be found in that orphaned block.

In order to iterate over all blocks in the longest chain you could use these commands:

Code:

getblockcount
getblockhash <index>
getblock <hash>

But what about all the orphans? They are not part of the longest chain, right? You can get any block if you know the hash with "getblock". But how do you discover the hash of the orphans in the first place?

Is there a way to discover the orphans via rpc?

[1715197075]

1715197075

[1715197075]

1715197075

[1715197075]

1715197075

[1715197075]

1715197075

[1715197075]

1715197075

[shorena]

I'm trying to iterate over all blocks, incl orphans, via the rpc api.

First, these are my assumptions. Please tell if these are correct:

Orphaned blocks are valid blocks.

correct.

Orphaned blocks contains valid transactions.

correct.

The transactions in an orphaned blocks can only be found in that orphaned block.

Nope. A transaction from an orphaned block usually gets rebroadcasted by the client or directly included in the competing block by the other miner.

In order to iterate over all blocks in the longest chain you could use these commands:

Code:

getblockcount
getblockhash <index>
getblock <hash>

But what about all the orphans? They are not part of the longest chain, right? You can get any block if you know the hash with "getblock". But how do you discover the hash of the orphans in the first place?

Is there a way to discover the orphans via rpc?

There is a list here[1] or start bitcoind with printblocktree. This will AFAIK only work on forks your client witnessed. I know of no RPC call, but maybe someone else does.

You can run bitcoin -printblocktree then look in debug.log to see any chain splits your client observed. My copy has seen three throughout its lifetime, all of them only a single block long.

[1] https://blockchain.info/orphaned-blocks

[domob]

You can also use getchaintips.  Call getblock on all the block hashes returned, and then go from each block onward to its parent.  That way, you can indeed iterate all blocks (including orphans) that your node knows about.

[DannyHamilton]

- snip -
you can indeed iterate all blocks (including orphans) that your node knows about.

The underlined part is very important.

In most cases your node won't ever even hear about the orphaned blocks.  You won't know that they ever existed.

[CuriousCarl]

Nope. A transaction from an orphaned block usually gets rebroadcasted by the client or directly included in the competing block by the other miner.

Oooooh. This puts things in a new perspective. It makes orphans much less important than I thought. Their transactions will (well, there's no guarantee but mostly) end up in other blocks. Now the rpc api makes more sense.

Thanks.

[azeteki]

It seems you've mostly figured this out now, but let's deconstruct a bit.

• Orphaned blocks are valid blocks.
• Orphaned blocks contains valid transactions.
• The transactions in an orphaned blocks can only be found in that orphaned block.

I think a better way to understand this would be to consider an orphaned block to have previously been a valid block, but no longer.

If the longest chain is at 300K, and there's e.g. an orphaned block 200,001, at this point it's almost totally irrelevant.

Any transactions included within it have almost certainly either been relocated into another block within the main chain, or simply replaced (inputs spent out from under them).

Consider that a transaction that exists only in orphaned blocks, but not in the main chain, is an unconfirmed transaction. If it never makes its' way into the main chain, it 'didn't happen', as far as the canonical state is concerned. The recipient, if they're aware of such, has good incentive to rebroadcast until the tx is confirmed again.

Aside from curiosity purposes, the only reason I can think of to worry about non-main-chain blocks is very close to the tip of the main chain - it's possible that they have not made it in to the main chain yet.

[CuriousCarl]

Consider that a transaction that exists only in orphaned blocks, but not in the main chain, is an unconfirmed transaction. If it never makes its' way into the main chain, it 'didn't happen', as far as the canonical state is concerned.

This is a nice explanation.

Thanks.

[DeathAndTaxes]

I think a better way to understand this would be to consider an orphaned block to have previously been a valid block, but no longer.

Terminology is important.  A orphaned valid block never becomes invalid.  Any client will see it as valid and that is not going change (one exception would be if another longer chain double spends the txn in the orphaned block).

However a valid block isn't all that matters.  For a confirmation to have any weight it must be not just in a valid block but in a valid block which is part of the longest chain.

If the longest chain is at 300K, and there's e.g. an orphaned block 200,001, at this point it's almost totally irrelevant.

True a chain which is 90K blocks behind the main chain is probably irrelevant but it isn't invalid.  Invalid has a specific meaning in the Bitcoin network.

Aside from curiosity purposes, the only reason I can think of to worry about non-main-chain blocks is very close to the tip of the main chain - it's possible that they have not made it in to the main chain yet.

Once again terminology matters.  A non-main-chain block is never going to make it into the longest chain (unless the inferior chain becomes longer and thus becomes the longest chain via a reorg) I assume what you mean is that "it is very possible that transactions in the orphaned block may not have made it into the main (longest) chain".