<blockquote>
<p>What will happen to the index entry for the abandoned block?</p>
</blockquote>
<p>Nothing. The block index contains information about the available blocks and branches, and their validity. It does not contain any information about which chain is actually currently considered active by the node. That information is in the chainstate database (which also holds the UTXO set).</p>
<blockquote>
<p>Will it remain in the database?</p>
</blockquote>
<p>Yes. It is a valid block.</p>
<blockquote>
<p>How these flags or other fields will be set then to mark this block as abandoned?</p>
</blockquote>
<p>Nothing changes.</p>
<blockquote>
<p>Is there any easy answer to the question of which branch to follow when traversing the index database or do I need to visit every branch to the very last leaf and choose the longest sequence each time?</p>
</blockquote>
<p>That's a possibility. An alternative is also looking at the chainstate database.</p>

CC BY-SA 4.0
2022-06-20T12:18:44.667Z
2022-06-20T12:18:44.667Z
Pieter Wuille
<p>I'm trying to understand block validity flags, and what happens when a branch occurs.
I found a block status flags in the bitcoin core source code:</p>
<pre><code>enum BlockStatus : uint32_t {

    BLOCK_VALID_UNKNOWN      =    0,
    BLOCK_VALID_RESERVED     =    1,
    BLOCK_VALID_TREE         =    2,
    BLOCK_VALID_TRANSACTIONS =    3,
    BLOCK_VALID_CHAIN        =    4,
    BLOCK_VALID_SCRIPTS      =    5,

    BLOCK_VALID_MASK         =   BLOCK_VALID_RESERVED | BLOCK_VALID_TREE | BLOCK_VALID_TRANSACTIONS |
                                 BLOCK_VALID_CHAIN | BLOCK_VALID_SCRIPTS,

    BLOCK_HAVE_DATA          =    8, //!&lt; full block available in blk*.dat
    BLOCK_HAVE_UNDO          =   16, //!&lt; undo data available in rev*.dat
    BLOCK_HAVE_MASK          =   BLOCK_HAVE_DATA | BLOCK_HAVE_UNDO,

    BLOCK_FAILED_VALID       =   32, //!&lt; stage after last reached validness failed
    BLOCK_FAILED_CHILD       =   64, //!&lt; descends from failed block
    BLOCK_FAILED_MASK        =   BLOCK_FAILED_VALID | BLOCK_FAILED_CHILD,

    BLOCK_OPT_WITNESS        =   128, //!&lt; block data in blk*.dat was received with a witness-enforcing client
    BLOCK_ASSUMED_VALID      =   256,
};
</code></pre>
<p>Supposing that block arrives, the node validates it successfully. I suppose that block status is set to 5 (BLOCK_VALID_SCRIPTS) in this case. Then it is stored in the block index database.
Now another sequence of two valid blocks arrives starting at the same height as the block above. I assume that the working node will consider this sequence as the active branch and the previous block will be abandoned.
What will happen to the index entry for the abandoned block? Will it remain in the database? How these flags or other fields will be set then to mark this block as abandoned?
Is there any easy answer to the question of which branch to follow when traversing the index database or do I need to visit every branch to the very last leaf and choose the longest sequence each time?</p>

<bitcoin-core><blockchain><block><bitcoin-core-development>
How are validity flags in block index set in concurrent blocks when one of them is chosen?
ardabro
# How are validity flags in block index set in concurrent blocks when one of them is chosen?

(Asked by: username_0 on 2022-06-20)

I'm trying to understand block validity flags, and what happens when a branch occurs.
I found a block status flags in the bitcoin core source code:

```
enum BlockStatus : uint32_t {

    BLOCK_VALID_UNKNOWN      =    0,
    BLOCK_VALID_RESERVED     =    1,
    BLOCK_VALID_TREE         =    2,
    BLOCK_VALID_TRANSACTIONS =    3,
    BLOCK_VALID_CHAIN        =    4,
    BLOCK_VALID_SCRIPTS      =    5,

    BLOCK_VALID_MASK         =   BLOCK_VALID_RESERVED | BLOCK_VALID_TREE | BLOCK_VALID_TRANSACTIONS |
                                 BLOCK_VALID_CHAIN | BLOCK_VALID_SCRIPTS,

    BLOCK_HAVE_DATA          =    8, //!< full block available in blk*.dat
    BLOCK_HAVE_UNDO          =   16, //!< undo data available in rev*.dat
    BLOCK_HAVE_MASK          =   BLOCK_HAVE_DATA | BLOCK_HAVE_UNDO,

    BLOCK_FAILED_VALID       =   32, //!< stage after last reached validness failed
    BLOCK_FAILED_CHILD       =   64, //!< descends from failed block
    BLOCK_FAILED_MASK        =   BLOCK_FAILED_VALID | BLOCK_FAILED_CHILD,

    BLOCK_OPT_WITNESS        =   128, //!< block data in blk*.dat was received with a witness-enforcing client
    BLOCK_ASSUMED_VALID      =   256,
};

```

Supposing that block arrives, the node validates it successfully. I suppose that block status is set to 5 (BLOCK\_VALID\_SCRIPTS) in this case. Then it is stored in the block index database.
Now another sequence of two valid blocks arrives starting at the same height as the block above. I assume that the working node will consider this sequence as the active branch and the previous block will be abandoned.
What will happen to the index entry for the abandoned block? Will it remain in the database? How these flags or other fields will be set then to mark this block as abandoned?
Is there any easy answer to the question of which branch to follow when traversing the index database or do I need to visit every branch to the very last leaf and choose the longest sequence each time?

**Tags:** bitcoin-core, blockchain, block, bitcoin-core-development


---

## 1 answers

### Answer by username_1 on 2022-06-20. Score: 6 | Accepted answer

> What will happen to the index entry for the abandoned block?

Nothing. The block index contains information about the available blocks and branches, and their validity. It does not contain any information about which chain is actually currently considered active by the node. That information is in the chainstate database (which also holds the UTXO set).

> Will it remain in the database?

Yes. It is a valid block.

> How these flags or other fields will be set then to mark this block as abandoned?

Nothing changes.

> Is there any easy answer to the question of which branch to follow when traversing the index database or do I need to visit every branch to the very last leaf and choose the longest sequence each time?

That's a possibility. An alternative is also looking at the chainstate database.


---

