<blockquote>
  <p>How do I catch the possible unconfirmed transactions, so the ones that
  got saved in the db when were first posted, but in the process were
  rejected/unconfirmed in the next 6 blocks.</p>
</blockquote>

<p>There are two ways a transaction (TXID) is first introduced by <code>walletnotify</code>:</p>

<ul>
<li>1) Acceptance in mempool</li>
<li>2) Confirmation in a block</li>
</ul>

<p>A transaction in mempool has no guarantee of being mined, and a confirmed transaction may have never been previously seen in your local mempool. Therefore, you need to be able to differentiate between the two scenarios, and only store the transactions which actually receive confirmation.</p>

<p><strong>Reorgs</strong>: Furthermore, there is no guarantee that a previously confirmed transaction receives confirmation from subsequent blocks. It is possible that subsequent blocks form a separate branch, so that your previously confirmed transaction is no longer in the strong chain. This is where incrementing confirmation with each new block as you describe will fail.</p>

<p>Better to verify the longest header chain (they must link together via prev header hash) and ensure that the transaction is included in this longest chain when computing the level of transaction confirmation. If this longest header chain reorganises, you can update the confirmations of all transactions accordingly.</p>

CC BY-SA 4.0
2019-01-26T19:34:55.010Z
So how would a transaction that was rejected or wasn't confirmed in the 'subsequent blocks' differ from the confirmed one in the output of gettransaction <txid>
zabbir
CC BY-SA 4.0
2019-01-27T08:51:19.753Z
I am not sure whether gettransaction <txid> returns transactions with confirmation field = 0. If it doesn't, that also tells you it isn't confirmed, but was accepted in your local mem-pool.
James C.
CC BY-SA 4.0
2019-01-28T04:38:34.920Z
It does, http://rgho.st/8rhMpLRsh. What if a transaction gets 2 confirmations and then gets rejected, how would it appear at gettransaction <txid> ?
zabbir
CC BY-SA 4.0
2019-01-28T06:42:54.153Z
Good question. Either 0 conf or not at all (TXID not found). The problem is you don't get any notification of a reorganisation, so you need to determine a reorganisation-event based on your header-chain, when new blocks are announced which don't extend the previous chain.
James C.
CC BY-SA 4.0
2019-01-30T13:59:13.020Z
Why would I want to catch these blocks? If transactions in them never get confirmed in my db: how would they be harmful?
zabbir
CC BY-SA 4.0
2019-01-30T14:21:01.773Z
If you have TX's stored in your database which are confirmed, they may become unconfirmed (Prevout unspent) or even invalid (Prevout already spent) during a chain reorganisation. That is why you need to recognise a chain reorganisation. This cannot be accomplished simply through tracking chain height. Different competing chains may have the same tip height.
James C.
CC BY-SA 4.0
2019-01-30T15:58:09.407Z
But what if I simply check the latest status of confirmations with gettransction <tx> for every notification of blocknotify and update all of my transactions below 6 confirmations. And stop this process for every transaction that has 6 + confs on new block. That's why I was interested how a rejected tx would appear so I can set confirmed to false in my db and it doesn't check it forever.
zabbir
CC BY-SA 4.0
2019-01-30T16:05:37.357Z
With rejected tx you mean a previously confirmed transaction which has been reorganised out of the strong chain? Assuming no deeper reorgs than 6 blocks, your 6-block window would make sense to me.
James C.
CC BY-SA 4.0
2019-01-30T16:10:15.810Z
Do reorganizations deeper 6 blocks ever happen?
zabbir
CC BY-SA 4.0
2019-01-30T16:11:56.113Z
Today? Unlikely, block propagation times down to zero, little to no orphaning and very expensive to create 6-deep competing branch. Historically? I don’t know.
James C.
CC BY-SA 4.0
2019-01-26T15:05:42.370Z
2019-01-26T15:05:42.370Z
James C.
<p>I'm catching all the deposit transactions with walletnotify and insert them into my database. Then on every blocknotify call I fetch all the transactions under 6 confirmations from the db and update them, specifically their confirmations. How do I catch the possible unconfirmed transactions, so the ones that got saved in the db when were first posted, but in the process were rejected/unconfirmed in the next 6 blocks. And also, I'm open to any recommendations on improving my existing system. Thanks </p>

<transactions><development><payment><block>
How do I catch the unconfirmed transactions?
zabbir
# How do I catch the unconfirmed transactions?

(Asked by: username_0 on 2019-01-26)

I'm catching all the deposit transactions with walletnotify and insert them into my database. Then on every blocknotify call I fetch all the transactions under 6 confirmations from the db and update them, specifically their confirmations. How do I catch the possible unconfirmed transactions, so the ones that got saved in the db when were first posted, but in the process were rejected/unconfirmed in the next 6 blocks. And also, I'm open to any recommendations on improving my existing system. Thanks

**Tags:** transactions, development, payment, block


---

## 1 answers

### Answer by username_1 on 2019-01-26. Score: 0 | Accepted answer

> How do I catch the possible unconfirmed transactions, so the ones that
> got saved in the db when were first posted, but in the process were
> rejected/unconfirmed in the next 6 blocks.

There are two ways a transaction (TXID) is first introduced by `walletnotify`:

* 1) Acceptance in mempool
* 2) Confirmation in a block

A transaction in mempool has no guarantee of being mined, and a confirmed transaction may have never been previously seen in your local mempool. Therefore, you need to be able to differentiate between the two scenarios, and only store the transactions which actually receive confirmation.

**Reorgs**: Furthermore, there is no guarantee that a previously confirmed transaction receives confirmation from subsequent blocks. It is possible that subsequent blocks form a separate branch, so that your previously confirmed transaction is no longer in the strong chain. This is where incrementing confirmation with each new block as you describe will fail.

Better to verify the longest header chain (they must link together via prev header hash) and ensure that the transaction is included in this longest chain when computing the level of transaction confirmation. If this longest header chain reorganises, you can update the confirmations of all transactions accordingly.

> **Comments:**
> **username_0**: So how would a transaction that was rejected or wasn't confirmed in the 'subsequent blocks' differ from the confirmed one in the output of gettransaction <txid>  
> **username_1**: I am not sure whether gettransaction <txid> returns transactions with confirmation field = 0. If it doesn't, that also tells you it isn't confirmed, but was accepted in your local mem-pool.  
> **username_0**: It does, http://rgho.st/8rhMpLRsh. What if a transaction gets 2 confirmations and then gets rejected, how would it appear at gettransaction <txid> ?  
> **username_1**: Good question. Either 0 conf or not at all (TXID not found). The problem is you don't get any notification of a reorganisation, so you need to determine a reorganisation-event based on your header-chain, when new blocks are announced which don't extend the previous chain.  
> **username_0**: Why would I want to catch these blocks? If transactions in them never get confirmed in my db: how would they be harmful?  
> **username_1**: If you have TX's stored in your database which are confirmed, they may become unconfirmed (Prevout unspent) or even invalid (Prevout already spent) during a chain reorganisation. That is why you need to recognise a chain reorganisation. This cannot be accomplished simply through tracking chain height. Different competing chains may have the same tip height.  
> **username_0**: But what if I simply check the latest status of confirmations with gettransction <tx> for every notification of blocknotify and update all of my transactions below 6 confirmations. And stop this process for every transaction that has 6 + confs on new block. That's why I was interested how a rejected tx would appear so I can set confirmed to false in my db and it doesn't check it forever.  
> **username_1**: With rejected tx you mean a previously confirmed transaction which has been reorganised out of the strong chain? Assuming no deeper reorgs than 6 blocks, your 6-block window would make sense to me.  
> **username_0**: Do reorganizations deeper 6 blocks ever happen?  
> **username_1**: Today? Unlikely, block propagation times down to zero, little to no orphaning and very expensive to create 6-deep competing branch. Historically? I don’t know.  

---

