<p>Two different blocks were mined at height 494676, i.e. two different blocks both naming the same previous block as their parent.  <a href="https://blockchain.info/block/000000000000000000262fc4538bf7cbfa3552f4370d494a70805c20cdf0c330" rel="nofollow noreferrer">One of them</a> has a hash starting 262f and <a href="https://blockchain.info/block/0000000000000000006d0d160c67e34273d46f1f29d8abe1139bb8c266b919a0" rel="nofollow noreferrer">the other</a> is 6d0d.  Both of them included the 9c7b transaction.  This happens normally from time to time; for instance, it could be that 262f was mined first, but it wasn't relayed to the other miner fast enough, so they kept trying blocks with the previous parent and ended up mining 6d0d.  Or it could be that they were coincidentally mined very close to the same time.  The timestamp on 6d0d is 56 seconds later, but timestamps are not guaranteed to be accurate.</p>
<p>Only one of the two can be included into &quot;the&quot; eventual blockchain, so following this, miners creating new blocks had to make a decision as to which of the two to name as parent.  262f won, so 6d0d is now stale and is not part of the main blockchain; Bitcoin nodes won't consider it part of the authentic transaction ledger, and the miner who created it can't spend the block reward.</p>

CC BY-SA 4.0
2018-02-18T19:05:29.373Z
2023-10-20T15:14:26.807Z
2023-10-20T15:14:26.807Z
Nate Eldredge
<p>There is a strange tx</p>
<p><code>9c7b0d0423af64e81c4b850bae781e41077586a9e3328f5048f8367c6e4a8212</code></p>
<p>that is shown as confirmed twice in the blockchain.info database.</p>
<p>Blockchain.info information is truly interesting. Is it a bug or what is this?</p>
<p><a href="https://i.sstatic.net/ybMUN.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ybMUN.png" alt="Screenshot of blockchain.info transaction overview that shows tx 9c7b…8212 to be included in two blocks that both have height 494676" /></a></p>

<blockchain.info><confirmations><stale-block>
Transaction listed as confirmed in two blocks on blockchain.info
Denis Leonov
# Transaction listed as confirmed in two blocks on blockchain.info

(Asked by: username_0 on 2018-02-18)

There is a strange tx

`9c7b0d0423af64e81c4b850bae781e41077586a9e3328f5048f8367c6e4a8212`

that is shown as confirmed twice in the blockchain.info database.

Blockchain.info information is truly interesting. Is it a bug or what is this?

[![Screenshot of blockchain.info transaction overview that shows tx 9c7b…8212 to be included in two blocks that both have height 494676](https://i.sstatic.net/ybMUN.png)](https://i.sstatic.net/ybMUN.png)

**Tags:** blockchain.info, confirmations, stale-block


---

## 1 answers

### Answer by username_1 on 2018-02-18. Score: 4 | Accepted answer

Two different blocks were mined at height 494676, i.e. two different blocks both naming the same previous block as their parent. [One of them](https://blockchain.info/block/000000000000000000262fc4538bf7cbfa3552f4370d494a70805c20cdf0c330) has a hash starting 262f and [the other](https://blockchain.info/block/0000000000000000006d0d160c67e34273d46f1f29d8abe1139bb8c266b919a0) is 6d0d. Both of them included the 9c7b transaction. This happens normally from time to time; for instance, it could be that 262f was mined first, but it wasn't relayed to the other miner fast enough, so they kept trying blocks with the previous parent and ended up mining 6d0d. Or it could be that they were coincidentally mined very close to the same time. The timestamp on 6d0d is 56 seconds later, but timestamps are not guaranteed to be accurate.

Only one of the two can be included into "the" eventual blockchain, so following this, miners creating new blocks had to make a decision as to which of the two to name as parent. 262f won, so 6d0d is now stale and is not part of the main blockchain; Bitcoin nodes won't consider it part of the authentic transaction ledger, and the miner who created it can't spend the block reward.


---

