<p>You can use the <code>rawblock</code> interface in order to determine whether there was a reorg.</p>

<p>Every time you receive a new block, you decode the block, in particular the block header. Then you store in your database each block and its previous block.</p>

<p>When you receive a block which shares the same previous block as another block that you have already received, then you know that a reorg has/is occurring.</p>

CC BY-SA 3.0
2018-01-12T22:33:39.767Z
2018-01-12T22:33:39.767Z
Ava Chow
<p>I'm not sure how ZeroMQ works specifically but if you receive a new block notification from bitcoind and you don't have it you have to retrieve the details of that block (<code>getblock</code>).  Check if it's the best block. </p>

<p>Then check if you have the previous block (using the previousblockhash from the details of the block above) and retrieve that until you have the previous block in your db or the previous block is the genesis block.</p>

<p>Every block you add in the process you need to check if you have other blocks at the same height and delete them or flag them as not belonging to the best chain.</p>

CC BY-SA 3.0
2017-05-11T13:56:38.070Z
2017-05-11T13:56:38.070Z
Louis
<p>I have my own bitcoind server (bitcoin core) and receive transaction data from the bitcoind via ZMQ. Then the transactions are stored into my database for data analytics or statics.</p>

<p>[bitcoind] --> (bitcoin transactions via ZMQ) --> [store into my DB]</p>

<p>Normally, it works well but sometimes blockchain will be re-organized when multiple chains are detected. At that time, I have to update my database as well. My question is how to detect the reorganization event from bitcoind server. Or do you have any good ideas for this.</p>

<p>FYI,</p>

<ul>
<li><p>I'm listening new block generation notification via ZMQ.</p></li>
<li><p>The main reason why I have my own database is seeing Colored coin transactions and Counterparty transaction.</p></li>
</ul>

<hr>

<p>Update 1</p>

<p>It seems that I can subscribe only four channels; hashblock, hashtx, rawblock and rawtx. It may be impossible to know the reorganization via ZMQ. I may have to confirm when I receive newblock notification wether fork exists or not..</p>

<hr>

<p>Update 2</p>

<p>I may have to call getchaintips RPC when every time I receive a new transaction notification.</p>

<p><a href="https://bitcoin.stackexchange.com/questions/44437/how-to-detect-a-fork-with-bitcoin-cli?rq=1">How to detect a fork with bitcoin-cli?</a></p>

<hr>

<p>Update 3</p>

<p>My understanding is that I need the following process to reorganize MY OWN Database.</p>

<p>getchaintips RPC's response</p>

<pre><code>{
    "height": 420561,
    "hash": "000000000000000001cb02590846299c91794e9b9f422513cff4b9c1dd5c62a",
    "branchlen": 0,
    "status": "active"
},
{
    "height": 419698,
    "hash": "000000000000000004a3a78750438d0491b6335cbbe9c15099a6e55b6943e51a",
    "branchlen": 1,
    "status": "valid-headers"
},
{
    "height": 418868,
    "hash": "000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805",
    "branchlen": 1,
    "status": "valid-fork"
},
</code></pre>

<ol>
<li>Call getchaintips when I receive a new tx notification.</li>
<li>Compare the two hashes. One is status is at "valid-fork" and another is stored hash at the same height in my own database. (As above response, height=418868, hash=000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805)</li>
<li>If the two hashes are different, delete all records from valid-fork's height and fetch transactions from the hight to the height of active status(As above response, height=420561), then insert them into to my own database.</li>
</ol>

<hr>

<p>Update 4</p>

<p>It seems that Counterparty detects reorganizations in the following source code. I think I can see it as reference.</p>

<p><a href="https://github.com/CounterpartyXCP/counterparty-lib/blob/5498d891ffec270c64a5804a4273962d2c759fa5/counterpartylib/lib/blocks.py#L1074" rel="nofollow noreferrer">https://github.com/CounterpartyXCP/counterparty-lib/blob/5498d891ffec270c64a5804a4273962d2c759fa5/counterpartylib/lib/blocks.py#L1074</a></p>

<chain-reorganization><counterparty><indiesquare>
How to detect reorganization from bitcoind via ZMQ?
zono
# How to detect reorganization from bitcoind via ZMQ?

(Asked by: username_0 on 2017-04-21)

I have my own bitcoind server (bitcoin core) and receive transaction data from the bitcoind via ZMQ. Then the transactions are stored into my database for data analytics or statics.

[bitcoind] --> (bitcoin transactions via ZMQ) --> [store into my DB]

Normally, it works well but sometimes blockchain will be re-organized when multiple chains are detected. At that time, I have to update my database as well. My question is how to detect the reorganization event from bitcoind server. Or do you have any good ideas for this.

FYI,

* I'm listening new block generation notification via ZMQ.
* The main reason why I have my own database is seeing Colored coin transactions and Counterparty transaction.

---

Update 1

It seems that I can subscribe only four channels; hashblock, hashtx, rawblock and rawtx. It may be impossible to know the reorganization via ZMQ. I may have to confirm when I receive newblock notification wether fork exists or not..

---

Update 2

I may have to call getchaintips RPC when every time I receive a new transaction notification.

[How to detect a fork with bitcoin-cli?](https://bitcoin.stackexchange.com/questions/44437/how-to-detect-a-fork-with-bitcoin-cli?rq=1)

---

Update 3

My understanding is that I need the following process to reorganize MY OWN Database.

getchaintips RPC's response

```
{
    "height": 420561,
    "hash": "000000000000000001cb02590846299c91794e9b9f422513cff4b9c1dd5c62a",
    "branchlen": 0,
    "status": "active"
},
{
    "height": 419698,
    "hash": "000000000000000004a3a78750438d0491b6335cbbe9c15099a6e55b6943e51a",
    "branchlen": 1,
    "status": "valid-headers"
},
{
    "height": 418868,
    "hash": "000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805",
    "branchlen": 1,
    "status": "valid-fork"
},

```

1. Call getchaintips when I receive a new tx notification.
2. Compare the two hashes. One is status is at "valid-fork" and another is stored hash at the same height in my own database. (As above response, height=418868, hash=000000000000000000ba1d7d93ad1c7f04fb4a430fdee67c44fbdd3236f2b805)
3. If the two hashes are different, delete all records from valid-fork's height and fetch transactions from the hight to the height of active status(As above response, height=420561), then insert them into to my own database.

---

Update 4

It seems that Counterparty detects reorganizations in the following source code. I think I can see it as reference.

<https://github.com/CounterpartyXCP/counterparty-lib/blob/5498d891ffec270c64a5804a4273962d2c759fa5/counterpartylib/lib/blocks.py#L1074>

**Tags:** chain-reorganization, counterparty, indiesquare


---

## 2 answers

### Answer by username_1 on 2018-01-12. Score: 3

You can use the `rawblock` interface in order to determine whether there was a reorg.

Every time you receive a new block, you decode the block, in particular the block header. Then you store in your database each block and its previous block.

When you receive a block which shares the same previous block as another block that you have already received, then you know that a reorg has/is occurring.


---

### Answer by username_2 on 2017-05-11. Score: 0

I'm not sure how ZeroMQ works specifically but if you receive a new block notification from bitcoind and you don't have it you have to retrieve the details of that block (`getblock`). Check if it's the best block.

Then check if you have the previous block (using the previousblockhash from the details of the block above) and retrieve that until you have the previous block in your db or the previous block is the genesis block.

Every block you add in the process you need to check if you have other blocks at the same height and delete them or flag them as not belonging to the best chain.


---

