<p>Yes, there are a few different ways this can happen, and in nearly all instances this occurring is of little significance. </p>

<p>First the most common scenario where that happens: When a client receives a block it first will verify the block before relaying it.  A node that performs this slowly (especially if running pre-v0.8 software) may be many seconds behind other nodes.   So while one node might verify a block and increment the number of confirmations for a transaction, another node would still be working on verifying it and would show one fewer confirmations.   Within seconds the count should become equal for the transaction on both nodes.</p>

<p>Another scenario is much more rare -- where the blockchain has forked, and a transaction will show a number of confirmations that varies between the count on one side of the fork versus the number of confirmations on the other side.  <a href="http://www.bitcoinmoney.com/post/47048259653" rel="nofollow">This scenario actually happened</a> on March 11th, 2013 where nodes running the v0.8 client would show a transaction as having a certain number of confirmations and at the same time a node running a pre-v0.8 client might show a lower number of confirmations.  When the forks converged, after the pre-v0.8 side attained "longest chain" status, both client versions then displayed the same count.</p>

<p>The possibility of there being a problem exists where there are several confirmations showing for a transaction on one node but no confirmations on another.  This could mean the funds for the transaction could be vulnerable to a double spend attack, or that such an attack had already occurred. But the scenario you describe, with at least one confirmation on both nodes, is likely simply just a propagation delay.</p>

CC BY-SA 3.0
2013-04-05T03:13:26.787Z
2013-04-05T03:13:26.787Z
Stephen Gornick
<p>In 99% of cases, it's because a miner has mined a block that has propagated through to the website and it hasn't reached the client yet. In the other 1% of times, it's because there has been a block chain fork and there are two block chains that are valid. Both possibilities are temporary things (almost always) and will fix themselves when the next block gets mined or sooner.</p>

CC BY-SA 3.0
2013-04-05T01:28:18.227Z
2013-04-05T03:39:12.780Z
2013-04-05T03:39:12.780Z
lurf jurv
<p>Is there ever a situation where some bitcoin client thinks a transaction has 3 confirmations and another bitcoin client (or website) thinks a transaction has 4 confirmations, for example?</p>

<confirmations>
Is there any discrepency on Confirmations?
themirror
# Is there any discrepency on Confirmations?

(Asked by: username_0 on 2013-04-05)

Is there ever a situation where some bitcoin client thinks a transaction has 3 confirmations and another bitcoin client (or website) thinks a transaction has 4 confirmations, for example?

**Tags:** confirmations


---

## 2 answers

### Answer by username_1 on 2013-04-05. Score: 3

Yes, there are a few different ways this can happen, and in nearly all instances this occurring is of little significance.

First the most common scenario where that happens: When a client receives a block it first will verify the block before relaying it. A node that performs this slowly (especially if running pre-v0.8 software) may be many seconds behind other nodes. So while one node might verify a block and increment the number of confirmations for a transaction, another node would still be working on verifying it and would show one fewer confirmations. Within seconds the count should become equal for the transaction on both nodes.

Another scenario is much more rare -- where the blockchain has forked, and a transaction will show a number of confirmations that varies between the count on one side of the fork versus the number of confirmations on the other side. [This scenario actually happened](http://www.bitcoinmoney.com/post/47048259653) on March 11th, 2013 where nodes running the v0.8 client would show a transaction as having a certain number of confirmations and at the same time a node running a pre-v0.8 client might show a lower number of confirmations. When the forks converged, after the pre-v0.8 side attained "longest chain" status, both client versions then displayed the same count.

The possibility of there being a problem exists where there are several confirmations showing for a transaction on one node but no confirmations on another. This could mean the funds for the transaction could be vulnerable to a double spend attack, or that such an attack had already occurred. But the scenario you describe, with at least one confirmation on both nodes, is likely simply just a propagation delay.


---

### Answer by username_2 on 2013-04-05. Score: 2

In 99% of cases, it's because a miner has mined a block that has propagated through to the website and it hasn't reached the client yet. In the other 1% of times, it's because there has been a block chain fork and there are two block chains that are valid. Both possibilities are temporary things (almost always) and will fix themselves when the next block gets mined or sooner.


---

