<p>First, a quick clarification: assuming two chains both have valid blocks, it's the chain with the most proof of work that wins, not necessarily the chain with the most blocks.</p>

<p>Second, thanks for the psuedocode.  It's always nice answering a question written in clear code.</p>

<p>The answer is that we want nodes to be able to agree on the best block chain based entirely on the data in the block chain.  That is, there should be no external state.</p>

<p>Why?  Because different nodes might have different external state.  Let's say an attacker manages to partition the network so that everyone in Europe is working on one chain and everyone in North America is working on a different chain:</p>

<pre><code>        /--&gt; C  -&gt; D  -&gt; E  -&gt; F  -&gt; G  Europe Chain
A -&gt; B -
        \--&gt; C` -&gt; D` -&gt; E` -&gt; F`       North America Chain
</code></pre>

<p>Because these two forks are more than 3 blocks different, even when full networking is restored, your code prevents nodes and miners in North America from switching over to the stronger European chain---meaning the network will remained forked forever.</p>

<p>I find it useful to always ask myself, "how will new nodes that are downloading the block chain for the first time come to consensus with currently active nodes in a trustless manner?"</p>

CC BY-SA 3.0
2015-01-18T01:00:03.490Z
Is your first statement really true?  Not how I understood it ... I understood that if there are two equal length blocks that two miners solve at the same time, then it forks, until the next block is solved, and the longest is the winner, so temporary forks are something that can happen and is expected, but the odds of the fork happening is very low, and exponentially lower chance them both co-existing for every block added.
Richard Anthony Hein
CC BY-SA 3.0
2015-01-18T01:16:09.910Z
Proof of work is calculated based on the target difficulty, not the header hash.  (Of course, the hash must be `<=` the target for the block to be valid.)  That means two blocks with the same parent will have the same proof of work, unless they're at a difficulty change boundary.  If we didn't have difficulty changes, it would be correct to say the longest fork wins.  As you say, accidental forks are fairly common but long accidental forks (>2 blocks) are extremely rare.
David A. Harding
CC BY-SA 3.0
2015-01-18T01:22:12.273Z
Good point about nodes only being able to verify the constraints I suggested if it received block announcements in real time (in contrast to when downloading the chain afterward). Also, good point about difficulty changes, so +1 to this answer too.
Will
CC BY-SA 3.0
2015-01-18T12:23:47.463Z
@DavidA.Harding: Wouldn't even at a difficulty change boundary two blocks of the same height with a common parent have the same target? I think you would need to have a fork of at least two blocks length to have blocks at the same height with different targets.
Murch
CC BY-SA 3.0
2015-01-18T13:25:59.003Z
@Murch er, you are correct.  I guess I didn't think that one through well enough.  Thanks!
David A. Harding
CC BY-SA 3.0
2015-01-18T00:20:57.097Z
2015-01-18T00:20:57.097Z
David A. Harding
<p>This sort of exists with <a href="https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints">checkpoints</a>.  The Bitcoin Core source contains a list of hashes of blocks at particular heights, and the standard client will refuse any chain that doesn't contain those blocks at those heights, so it won't accept a fork that diverges before the latest checkpoint.  Periodically the Bitcoin Core maintainers will add to this list, to include some more relatively recent (but not too recent) blocks.</p>

<p>To get a sense for how recent, the latest checkpoint in the git repository for Bitcoin Core is at height 295000 (mined in April 2014), and the current height is 339431.  So it won't accept any fork that tries to reverse more than 44431 blocks, or about 9 months of work.  Feel better now? :-)</p>

CC BY-SA 3.0
2015-01-18T04:23:26.413Z
While what you said is true, Bitcoin Core's checkpoints are mainly an artifact of the blocks-first download method employed in the 0.9.x series and before.  With blocks-first, it's easy to feed a new node a valid-but-not-strongest chain with hundreds of gigabytes of useless transactions.  With the new Bitcoin Core 0.10.0 headers-first method, that's no longer an issue and checkpoints aren't so important.  It might even be possible to replace them with a chain-agnostic total-proof-of-work (chainwork) check.
David A. Harding
CC BY-SA 3.0
2015-02-10T04:51:04.713Z
@DavidA.Harding, The checkpoints also serve to speed up signature verification (as scripts before the last checkpoint are not checked). Even with headers-first synchronization, the checkpoints are still useful to determine when to skip signature checking.
morsecoder
CC BY-SA 3.0
2015-01-18T04:01:20.850Z
2015-01-18T04:01:20.850Z
2017-04-13T12:47:33.583Z
Nate Eldredge
<blockquote>
  <p>My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?</p>
</blockquote>

<p>Because <em>you can't prove that</em> to nodes that weren't on the network at the time of the attack. Which means that either:</p>

<ul>
<li><p>It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it will lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.</p></li>
<li><p>If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.</p></li>
</ul>

<blockquote>
  <p>If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?</p>
</blockquote>

<p>A 51% attack can double-spend outputs with <em>any number of confirmations.</em> The oft-quoted 6 confirmations figure comes from <a href="https://bitcoin.org/bitcoin.pdf">the Bitcoin paper</a>, where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.</p>

CC BY-SA 3.0
2015-01-18T01:16:05.307Z
Your first point is a good one. A node would only be able to verify the constraints I suggested if it received block announcements in real time. However, It's not immediately apparent to me that `"you're now expanding the circle of people you trust to the people relaying the chain"`. And by that I mean: aren't you already (in the bitcoin network as it exists today) extending trust to relaying nodes anyway? I thought that this trust issue already existed, but that it poses no problem given the incentives of nodes to keep the network as a whole in a healthy state.
Will
CC BY-SA 3.0
2015-01-18T01:18:37.057Z
Also, I'm not sure what your 2nd paragraph is supposed to refute about the sentence of mine you quoted. Either way your answer as it stands is much appreciated though. :)
Will
CC BY-SA 3.0
2015-01-18T02:40:52.603Z
@Will `aren't you already extending trust to relaying nodes` Very little. They can avoid telling you about blocks, but as soon as you connect to one node that isn't cooperating in the embargo, you'll download the best chain.
Nick ODell
CC BY-SA 3.0
2015-01-18T00:17:16.043Z
2015-01-18T02:36:26.110Z
2015-01-18T02:36:26.110Z
Nick ODell
<p>In Bitcoin's proof-of-work system, consensus on which chain of blocks should be considered the "true" block chain is based only(?) on which chain is longer.</p>

<p>Accordingly, to quote a nicely written <a href="https://bitcoin.stackexchange.com/a/25121/19556">answer</a> by Nate Eldredge, a typical 51% attack would look like this:</p>

<blockquote>
  <ol>
  <li><p>Attacker privately starts mining their own chain, which diverges from the main chain at some block N.</p></li>
  <li><p>Attacker deposits coins to your business, sending them from address A. Call this transaction X.</p></li>
  <li><p>Attacker inserts in his own chain a transaction X' which conflicts with X; typically X' sends the coins from address A to another address belonging to the attacker.</p></li>
  <li><p>Attacker waits for several confirmations of transaction X, in blocks N+1, ..., N+6 (replace 6 with however many confirmations your business wants) of the main chain.</p></li>
  <li><p>Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.</p></li>
  <li><p>Attacker releases his own chain, which now has blocks up to, say, N+50. Being longer, this chain is accepted by the network. This chain doesn't contain the transaction X but instead X', so you don't have the coins you thought you did.</p></li>
  </ol>
  
  <p>Notice that up until Step 6, everything on the network looks completely normal; only the attacker knows what is going on.</p>
</blockquote>

<p>My question then is: why doesn't bitcoin specify a <em>maximum duration of time</em> and/or a <em>maximum number of confirmations</em>, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?</p>

<p>To summarize this idea in pseudocode:</p>

<pre><code>CUTOFF_TIME = 1200 # seconds
CUTOFF_CONFIRMATIONS = 3

is_acceptable_block(new_block, parent_block):
    if not is_valid_block(new_block):
        return false

    if is_first_child(new_block, parent_block):
        return true

    old_block = get_first_child(parent_block)

    if age_difference(new_block, old_block) &gt; CUTOFF_TIME:
        return false

    if child_chain_length(old_block) &gt; CUTOFF_CONFIRMATIONS:
        return false

    return child_chain_length(new_block) &gt; child_chain_length(old_block)
</code></pre>

<p>If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?</p>

<blockchain><doublespend><blockchain-fork><majority-attack>
Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)
Will
# Why doesn't bitcoin place additional constraints on competing block chain forks, other than length of chain? (e.g., time and confirmation count)

(Asked by: username_0 on 2015-01-17)

In Bitcoin's proof-of-work system, consensus on which chain of blocks should be considered the "true" block chain is based only(?) on which chain is longer.

Accordingly, to quote a nicely written [answer](https://bitcoin.stackexchange.com/a/25121/19556) by username_4 username_4, a typical 51% attack would look like this:

> 1. Attacker privately starts mining their own chain, which diverges from the main chain at some block N.
> 2. Attacker deposits coins to your business, sending them from address A. Call this transaction X.
> 3. Attacker inserts in his own chain a transaction X' which conflicts with X; typically X' sends the coins from address A to another address belonging to the attacker.
> 4. Attacker waits for several confirmations of transaction X, in blocks N+1, ..., N+6 (replace 6 with however many confirmations your business wants) of the main chain.
> 5. Once there have been enough confirmations to satisfy you, you deliver goods or services to attacker.
> 6. Attacker releases his own chain, which now has blocks up to, say, N+50. Being longer, this chain is accepted by the network. This chain doesn't contain the transaction X but instead X', so you don't have the coins you thought you did.
>
> Notice that up until Step 6, everything on the network looks completely normal; only the attacker knows what is going on.

My question then is: why doesn't bitcoin specify a *maximum duration of time* and/or a *maximum number of confirmations*, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

To summarize this idea in pseudocode:

```
CUTOFF_TIME = 1200 # seconds
CUTOFF_CONFIRMATIONS = 3

is_acceptable_block(new_block, parent_block):
    if not is_valid_block(new_block):
        return false

    if is_first_child(new_block, parent_block):
        return true

    old_block = get_first_child(parent_block)

    if age_difference(new_block, old_block) > CUTOFF_TIME:
        return false

    if child_chain_length(old_block) > CUTOFF_CONFIRMATIONS:
        return false

    return child_chain_length(new_block) > child_chain_length(old_block)

```

If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

**Tags:** blockchain, doublespend, blockchain-fork, majority-attack


---

## 3 answers

### Answer by username_6 on 2015-01-18. Score: 9 | Accepted answer

> My question then is: why doesn't bitcoin specify a maximum duration of time and/or a maximum number of confirmations, after which a competing/forking block is rejected even if it's backed by a longer chain of (secretly premined) child blocks?

Because *you can't prove that* to nodes that weren't on the network at the time of the attack. Which means that either:

* It's possible for an attacker to create a new chain, and if enough nodes join the network while the new chain is the best one, it username_0 lead to a situation where half of the nodes believe that one chain is the best, and half think the other chain is the best.
* If you make new nodes trust old nodes when they say that the best chain isn't the real chain, you're now expanding the circle of people you trust to the people relaying the chain, in addition to the people mining it. Before, if two nodes thought different chains were best, you could download both and say with certainty that one was better than the other. If you implemented this change, you would need to decide which node was more trustworthy.

> If this would be viable, then the 51% attack scenario described above would become much harder; and as a result, the amount of time/confirmations to wait for before a transaction can be safely believed would decrease, right?

A 51% attack can double-spend outputs with *any number of confirmations.* The oft-quoted 6 confirmations figure comes from [the Bitcoin paper](https://bitcoin.org/bitcoin.pdf), where Satoshi calculates that an attacker with 10% of the network hashpower would have less than a 0.1% chance to catch up.

> **Comments:**
> **username_0**: Your first point is a good one. A node would only be able to verify the constraints I suggested if it received block announcements in real time. However, It's not immediately apparent to me that `"you're now expanding the circle of people you trust to the people relaying the chain"`. And by that I mean: aren't you already (in the bitcoin network as it exists today) extending trust to relaying nodes anyway? I thought that this trust issue already existed, but that it poses no problem given the incentives of nodes to keep the network as a whole in a healthy state.  
> **username_0**: Also, I'm not sure what your 2nd paragraph is supposed to refute about the sentence of mine you quoted. Either way your answer as it stands is much appreciated though. :)  
> **username_6**: @username_0 `aren't you already extending trust to relaying nodes` Very little. They can avoid telling you about blocks, but as soon as you connect to one node that isn't cooperating in the embargo, you'll download the best chain.  

---

### Answer by username_1 on 2015-01-18. Score: 8

First, a quick clarification: assuming two chains both have valid blocks, it's the chain with the most proof of work that wins, not necessarily the chain with the most blocks.

Second, thanks for the psuedocode. It's always nice answering a question written in clear code.

The answer is that we want nodes to be able to agree on the best block chain based entirely on the data in the block chain. That is, there should be no external state.

Why? Because different nodes might have different external state. Let's say an attacker manages to partition the network so that everyone in Europe is working on one chain and everyone in North America is working on a different chain:

```
        /--> C  -> D  -> E  -> F  -> G  Europe Chain
A -> B -
        \--> C` -> D` -> E` -> F`       North America Chain

```

Because these two forks are more than 3 blocks different, even when full networking is restored, your code prevents nodes and miners in North America from switching over to the stronger European chain---meaning the network username_0 remained forked forever.

I find it useful to always ask myself, "how username_0 new nodes that are downloading the block chain for the first time come to consensus with currently active nodes in a trustless manner?"

> **Comments:**
> **username_2**: Is your first statement really true?  Not how I understood it ... I understood that if there are two equal length blocks that two miners solve at the same time, then it forks, until the next block is solved, and the longest is the winner, so temporary forks are something that can happen and is expected, but the odds of the fork happening is very low, and exponentially lower chance them both co-existing for every block added.  
> **username_1**: Proof of work is calculated based on the target difficulty, not the header hash.  (Of course, the hash must be `<=` the target for the block to be valid.)  That means two blocks with the same parent username_0 have the same proof of work, unless they're at a difficulty change boundary.  If we didn't have difficulty changes, it would be correct to say the longest fork wins.  As you say, accidental forks are fairly common but long accidental forks (>2 blocks) are extremely rare.  
> **username_0**: Good point about nodes only being able to verify the constraints I suggested if it received block announcements in real time (in contrast to when downloading the chain afterward). Also, good point about difficulty changes, so +1 to this answer too.  
> **username_3**: @username_1: Wouldn't even at a difficulty change boundary two blocks of the same height with a common parent have the same target? I think you would need to have a fork of at least two blocks length to have blocks at the same height with different targets.  
> **username_1**: @username_3 er, you are correct.  I guess I didn't think that one through well enough.  Thanks!  

---

### Answer by username_4 on 2015-01-18. Score: 1

This sort of exists with [checkpoints](https://bitcoin.stackexchange.com/questions/1797/what-are-checkpoints). The Bitcoin Core source contains a list of hashes of blocks at particular heights, and the standard client username_0 refuse any chain that doesn't contain those blocks at those heights, so it won't accept a fork that diverges before the latest checkpoint. Periodically the Bitcoin Core maintainers username_0 add to this list, to include some more relatively recent (but not too recent) blocks.

To get a sense for how recent, the latest checkpoint in the git repository for Bitcoin Core is at height 295000 (mined in April 2014), and the current height is 339431. So it won't accept any fork that tries to reverse more than 44431 blocks, or about 9 months of work. Feel better now? :-)

> **Comments:**
> **username_1**: While what you said is true, Bitcoin Core's checkpoints are mainly an artifact of the blocks-first download method employed in the 0.9.x series and before.  With blocks-first, it's easy to feed a new node a valid-but-not-strongest chain with hundreds of gigabytes of useless transactions.  With the new Bitcoin Core 0.10.0 headers-first method, that's no longer an issue and checkpoints aren't so important.  It might even be possible to replace them with a chain-agnostic total-proof-of-work (chainwork) check.  
> **username_5**: @username_1, The checkpoints also serve to speed up signature verification (as scripts before the last checkpoint are not checked). Even with headers-first synchronization, the checkpoints are still useful to determine when to skip signature checking.  

---

