<p><a href="http://bitcoin.org/bitcoin.pdf" rel="nofollow noreferrer">According to the Satoshi paper</a>, the following applies:</p>

<blockquote>
  <p>The steps to run the network are as follows: </p>
  
  <p>1) New transactions are
  broadcast to all nodes. </p>
  
  <p>2) Each node collects new transactions into a
  block. </p>
  
  <p>3) Each node works on finding a difficult proof-of-work for its
  block. </p>
  
  <p>4) When a node finds a proof-of-work, it broadcasts the block
  to all nodes.</p>
  
  <p>5) Nodes accept the block only if all transactions in it
  are valid and not already spent. </p>
  
  <p>6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. </p>
  
  <p>Nodes always consider the longest chain to be the correct one and will keep working
  on extending it. If two nodes broadcast different versions of the next
  block simultaneously, some nodes may receive one or the other first.
  In that case, they work on the first one they received, but save the
  other branch in case it becomes longer. The tie will be broken when
  the next proofof- work is found and one branch becomes longer; the
  nodes that were working on the other branch will then switch to the
  longer one.</p>
</blockquote>

<p>That pretty much sums it up. If you have more valid blocks, you win until someone comes along with more valid blocks. </p>

CC BY-SA 4.0
2021-01-23T00:48:47.057Z
This is what the paper said and this is what the original Satoshi code did, but this is no longer correct. If you always pick the longest chain then there are some relatively easy attacks that work by making long and easy chains. In 2016 the bitcoin core code switched to using the "most work" chain, which is not necessarily the longest. Here is the commit...
https://github.com/bitcoin/bitcoin/commit/e86756193ebdbf71504e2a1a8db43e38d57f9673
bigjosh
CC BY-SA 3.0
2011-09-13T08:51:20.693Z
2011-10-14T21:26:17.327Z
2011-10-14T21:26:17.327Z
Gary
<p>Gary's answer is not entirely correct. When comparing two chains, their total "scores" are compared.
Each block counts as (2^256 / block_target); this is the expected/average number of attempts that were necessary to create it.</p>

<p>Obviously, within one series of 2016 blocks, the difficulties are all equal, so for most small reorganizations, the score will tell you the same thing as just counting the number of blocks. However, as an attacker may well try to rewrite blocks that cross the multiple-of-2016-boundary, you need to take this into account. The actual rule always favors the chains which required the most "work".</p>

CC BY-SA 3.0
2017-03-06T01:09:34.313Z
Thanks Peter. I was confused as I initially read your answer as "this is the expected **divided by** average..." That is a minor point tho. Your answer seems to be at odds with @NickOdells answer here: http://bitcoin.stackexchange.com/questions/37273/how-is-a-blockchain-split-resolved?noredirect=1&lq=1, which claims there is not a score, but a series of rules set out in CBlockIndexWorkComparator.
Alex Millar
CC BY-SA 3.0
2018-01-03T11:01:21.327Z
This answer only elaborates on the first criterion in CBlockIndexWorkComparator. The others are just for tie-breaking.
Pieter Wuille
CC BY-SA 4.0
2018-08-28T14:43:31.987Z
Why isn't the block hash used to calculate work done?
JBaczuk
CC BY-SA 4.0
2018-08-28T15:13:45.537Z
@JBaczuk Because among the set of acceptable hashes, every hash is equally likely. Counting some as more than others would simply introduce additional variance (where one branch, without merit, randomly would count more than another). The only practical effect would be seeing far more forks, and needing more confirmations to be sure a transaction made it in.
Pieter Wuille
CC BY-SA 3.0
2011-09-13T09:15:10.730Z
2011-09-13T09:15:10.730Z
Pieter Wuille
<p>Is it only the block height or is it the effort that went into the forks? In other words: does this decision account for different difficulties?</p>

<blockchain><security><blockchain-fork><best-chain>
How does a client decide which is the longest block chain if there is a fork?
kermit
# How does a client decide which is the longest block chain if there is a fork?

(Asked by: username_0 on 2011-09-13)

Is it only the block height or is it the effort that went into the forks? In other words: does this decision account for different difficulties?

**Tags:** blockchain, security, blockchain-fork, best-chain


---

## 2 answers

### Answer by username_3 on 2011-09-13. Score: 28 | Accepted answer

username_1's answer is not entirely correct. When comparing two chains, their total "scores" are compared.
Each block counts as (2^256 / block\_target); this is the expected/average number of attempts that were necessary to create it.

Obviously, within one series of 2016 blocks, the difficulties are all equal, so for most small reorganizations, the score will tell you the same thing as just counting the number of blocks. However, as an attacker may well try to rewrite blocks that cross the multiple-of-2016-boundary, you need to take this into account. The actual rule always favors the chains which required the most "work".

> **Comments:**
> **username_4**: Thanks Peter. I was confused as I initially read your answer as "this is the expected **divided by** average..." That is a minor point tho. Your answer seems to be at odds with @NickOdells answer here: http://bitcoin.stackexchange.com/questions/37273/how-is-a-blockchain-split-resolved?noredirect=1&lq=1, which claims there is not a score, but a series of rules set out in CBlockIndexWorkComparator.  
> **username_3**: This answer only elaborates on the first criterion in CBlockIndexWorkComparator. The others are just for tie-breaking.  
> **username_5**: Why isn't the block hash used to calculate work done?  
> **username_3**: @username_5 Because among the set of acceptable hashes, every hash is equally likely. Counting some as more than others would simply introduce additional variance (where one branch, without merit, randomly would count more than another). The only practical effect would be seeing far more forks, and needing more confirmations to be sure a transaction made it in.  

---

### Answer by username_1 on 2011-09-13. Score: 6

[According to the Satoshi paper](http://bitcoin.org/bitcoin.pdf), the following applies:

> The steps to run the network are as follows:
>
> 1) New transactions are
> broadcast to all nodes.
>
> 2) Each node collects new transactions into a
> block.
>
> 3) Each node works on finding a difficult proof-of-work for its
> block.
>
> 4) When a node finds a proof-of-work, it broadcasts the block
> to all nodes.
>
> 5) Nodes accept the block only if all transactions in it
> are valid and not already spent.
>
> 6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
>
> Nodes always consider the longest chain to be the correct one and will keep working
> on extending it. If two nodes broadcast different versions of the next
> block simultaneously, some nodes may receive one or the other first.
> In that case, they work on the first one they received, but save the
> other branch in case it becomes longer. The tie will be broken when
> the next proofof- work is found and one branch becomes longer; the
> nodes that were working on the other branch will then switch to the
> longer one.

That pretty much sums it up. If you have more valid blocks, you win until someone comes along with more valid blocks.

> **Comments:**
> **username_2**: This is what the paper said and this is what the original Satoshi code did, but this is no longer correct. If you always pick the longest chain then there are some relatively easy attacks that work by making long and easy chains. In 2016 the bitcoin core code switched to using the "most work" chain, which is not necessarily the longest. Here is the commit... https://github.com/bitcoin/bitcoin/commit/e86756193ebdbf71504e2a1a8db43e38d57f9673  

---

