<p>Yes, there is still a need to wait for confirmations.</p>
<p>Even in the absence of active attackers, there are many reasons the Bitcoin network could diverge, such as:</p>
<ol>
<li>Large scale internet routing issues - we've already seen these with BGP routes being incorrectly broadcast, leaving large chunks of the internet temporarily inaccessible from other large chunks. In such a scenario, if miners are isolated into one of the two groups, each isolated group will advance the network without any visibility into the blocks being produced by the other side until the two networks are merged</li>
<li>Implementation bugs - although Bitcoin nodes generally just run Bitcoin Core, different implementations of the same Bitcoin Protocol can occasionally result in consensus bugs that result in everyone on one implementation rejecting blocks from the others. This has resulted in a few forks on other chains with multiple common implementations, such as ethereum.</li>
<li>Just normal mining - the very nature of mining means that sooner or later, two miners will produce block N simultaneously. This results in a split chain until the next block is mined, at which point only the block that is included in the <code>prevBlock</code> for the new block is retained.</li>
</ol>

CC BY-SA 4.0
2020-07-11T14:58:47.137Z
2020-07-11T14:58:47.137Z
Raghav Sood
<p>As described in the Bitcoin paper, the Bitcoin network may temporarily diverge, or &quot;fork,&quot; as nodes may work on different blockchains.
The network reconverges, however, as a node will always continue working on the longest blockchain it learns about.
This opens up the network for history reversal, since transactions that are part of a discarded blockchain might not be part of the longer, universally accepted one.
This is typically discussed in the context of an attack scenario.
E.g., many vandors wait for a transaction to be confirmed six times until accepting it as payment.
This is presumably due to the Bitcoin paper stating that, assuming an attacker controls 10% of the network's processing power, waiting for six confirmations puts the attacker's success probability in the order of 0.1%.
However, in a scenario that assumes the absence of attackers, would there still be the need to wait for some number of confirmations?
After all, history reversal is an intrinsic part of proof of work -- facilitating network convergence -- even if it is not abused in order to double spend, right?</p>

<security><proof-of-work><confirmations><attack><whitepaper>
Is history reversal a concern if the absence of attackers is assumed?
pygumby
# Is history reversal a concern if the absence of attackers is assumed?

(Asked by: username_0 on 2020-07-11)

As described in the Bitcoin paper, the Bitcoin network may temporarily diverge, or "fork," as nodes may work on different blockchains.
The network reconverges, however, as a node will always continue working on the longest blockchain it learns about.
This opens up the network for history reversal, since transactions that are part of a discarded blockchain might not be part of the longer, universally accepted one.
This is typically discussed in the context of an attack scenario.
E.g., many vandors wait for a transaction to be confirmed six times until accepting it as payment.
This is presumably due to the Bitcoin paper stating that, assuming an attacker controls 10% of the network's processing power, waiting for six confirmations puts the attacker's success probability in the order of 0.1%.
However, in a scenario that assumes the absence of attackers, would there still be the need to wait for some number of confirmations?
After all, history reversal is an intrinsic part of proof of work -- facilitating network convergence -- even if it is not abused in order to double spend, right?

**Tags:** security, proof-of-work, confirmations, attack, whitepaper


---

## 1 answers

### Answer by username_1 on 2020-07-11. Score: 1 | Accepted answer

Yes, there is still a need to wait for confirmations.

Even in the absence of active attackers, there are many reasons the Bitcoin network could diverge, such as:

1. Large scale internet routing issues - we've already seen these with BGP routes being incorrectly broadcast, leaving large chunks of the internet temporarily inaccessible from other large chunks. In such a scenario, if miners are isolated into one of the two groups, each isolated group will advance the network without any visibility into the blocks being produced by the other side until the two networks are merged
2. Implementation bugs - although Bitcoin nodes generally just run Bitcoin Core, different implementations of the same Bitcoin Protocol can occasionally result in consensus bugs that result in everyone on one implementation rejecting blocks from the others. This has resulted in a few forks on other chains with multiple common implementations, such as ethereum.
3. Just normal mining - the very nature of mining means that sooner or later, two miners will produce block N simultaneously. This results in a split chain until the next block is mined, at which point only the block that is included in the `prevBlock` for the new block is retained.


---

