<p>I know you're looking for some magic constant, but it doesn't exist.  Your code needs to deal with reorgs of any depth back to the genesis block.</p>

<p>This may seem like a annoyance of dealing with the block chain, but it's how payments have always worked.  Even if some guy pays you with a suitcase full of verified gold bars, a court order can compel you to return those bars at any later point.  (For example, it's fairly common for the court to order stolen property returned to its previous owner without any compensation to its current owner even if the current owner didn't know it was stolen when he bought it.  This notably happens occasionally with art stolen 70 years ago during WWII.)</p>

<p>If you really want to take a shortcut and leave dealing with long reorgs up to some future programmer or database admin, then any arbitrary constant will do.  This is why many high-value sites require six confirmations---not because six is the correct value, but because approximately one hour of confirmations is a nice arbitrary value.</p>

CC BY-SA 3.0
2014-12-07T21:54:56.693Z
Thanks David. Do you believe that a grand fork like this one: https://bitcoin.org/en/alert/2013-03-11-chain-fork is likely to ever happen again?
Doug Peters
CC BY-SA 3.0
2014-12-07T23:21:42.200Z
I'd be surprised if it doesn't happen again as we move into an era where miners use alternative full node implementations, block subsidies drop, and new variables like side chains are introduced.  The remarkable thing to me is that we manage to maintain consensus as well as we do---that's really a credit to the hard work of the Bitcoin Core developers.
David A. Harding
CC BY-SA 3.0
2014-12-08T09:03:30.473Z
Definitely we will see long forks. Especially if the difficulty will fall. Lower values of difficulty/hashrate give lower cost for double-spending attacks.
amaclin
CC BY-SA 3.0
2014-12-07T19:08:54.693Z
2014-12-07T19:08:54.693Z
David A. Harding
<p>When my service detects a <code>conflicted</code> transaction (either <code>sent</code> or <code>received</code>) it rollbacks everything that was logically built upon this transaction. The "problem" is that transactions can go from category <code>conflicted</code> to <code>sent/received</code> if a <a href="https://en.bitcoin.it/wiki/Chain_Reorganization" rel="nofollow noreferrer">blockchain reorganization</a> happens, so my question is how long (how many blocks) should my service wait in order to be positive that a <code>conflicted</code> transaction will never  get included into a block?</p>

<p>I have found this question to be helpful: <a href="https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date/">What is the longest blockchain fork that has been orphaned to date?</a> </p>

CC BY-SA 3.0
2014-12-07T17:12:06.013Z
What probability do you want? In fact there is only one transaction in the blockchain which can not be overwriten by reorganization. It is coinbase transaction in block #0
amaclin
CC BY-SA 3.0
2014-12-07T17:28:31.653Z
@amaclin according to http://bitcoin.stackexchange.com/a/4638/14319 there has never been a fork longer than 4 blocks except for the [March 12 2013 blockchain fork](https://bitcoin.org/en/alert/2013-03-11-chain-fork) which was 31 blocks long but according to my understanding it is unlikely to happen again, is that correct? All I'm looking for is a "safe" number of blocks after which a chain reorg is unlikely to happen.
Doug Peters
<doublespend><chain-reorganization>
Conflicted transactions in blockchain reorganizations
Doug Peters
# Conflicted transactions in blockchain reorganizations

(Asked by: username_0 on 2014-12-07)

When my service detects a `conflicted` transaction (either `sent` or `received`) it rollbacks everything that was logically built upon this transaction. The "problem" is that transactions can go from category `conflicted` to `sent/received` if a [blockchain reorganization](https://en.bitcoin.it/wiki/Chain_Reorganization) happens, so my question is how long (how many blocks) should my service wait in order to be positive that a `conflicted` transaction will never get included into a block?

I have found this question to be helpful: [What is the longest blockchain fork that has been orphaned to date?](https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date/)

**Tags:** doublespend, chain-reorganization

> **Comments:**
> **username_1**: What probability do you want? In fact there is only one transaction in the blockchain which can not be overwriten by reorganization. It is coinbase transaction in block #0  
> **username_0**: @username_1 according to http://bitcoin.stackexchange.com/a/4638/14319 there has never been a fork longer than 4 blocks except for the [March 12 2013 blockchain fork](https://bitcoin.org/en/alert/2013-03-11-chain-fork) which was 31 blocks long but according to my understanding it is unlikely to happen again, is that correct? All I'm looking for is a "safe" number of blocks after which a chain reorg is unlikely to happen.  

---

## 1 answers

### Answer by username_2 on 2014-12-07. Score: 2 | Accepted answer

I know you're looking for some magic constant, but it doesn't exist. Your code needs to deal with reorgs of any depth back to the genesis block.

This may seem like a annoyance of dealing with the block chain, but it's how payments have always worked. Even if some guy pays you with a suitcase full of verified gold bars, a court order can compel you to return those bars at any later point. (For example, it's fairly common for the court to order stolen property returned to its previous owner without any compensation to its current owner even if the current owner didn't know it was stolen when he bought it. This notably happens occasionally with art stolen 70 years ago during WWII.)

If you really want to take a shortcut and leave dealing with long reorgs up to some future programmer or database admin, then any arbitrary constant will do. This is why many high-value sites require six confirmations---not because six is the correct value, but because approximately one hour of confirmations is a nice arbitrary value.

> **Comments:**
> **username_0**: Thanks username_2. Do you believe that a grand fork like this one: https://bitcoin.org/en/alert/2013-03-11-chain-fork is likely to ever happen again?  
> **username_2**: I'd be surprised if it doesn't happen again as we move into an era where miners use alternative full node implementations, block subsidies drop, and new variables like side chains are introduced.  The remarkable thing to me is that we manage to maintain consensus as well as we do---that's really a credit to the hard work of the Bitcoin Core developers.  
> **username_1**: Definitely we will see long forks. Especially if the difficulty will fall. Lower values of difficulty/hashrate give lower cost for double-spending attacks.  

---

