<p>Nodes follow the chain with the most <em>cumulative</em> work, not the lowest hash of the latest block (which would be most work for the current block).</p>

CC BY-SA 4.0
2020-07-29T10:24:12.853Z
Ah yes, good point - so translating the lowest hash into a measurable unit to represent work, and summing them as blocks are appended to the chain(s) will give me an idea of how much work has gone into each tip?
Michael Fletcher
CC BY-SA 4.0
2020-07-29T10:27:54.973Z
Precisely - the formal term is `chainwork`, you can see how it is calculated [here](https://learnmeabitcoin.com/technical/longest-chain) and [here](https://bitcoin.stackexchange.com/q/26869/7272).
Raghav Sood
CC BY-SA 4.0
2020-07-29T10:29:08.217Z
Thanks man. In regard to following the 'longest' chain, is my example potentially an attack vector? are there any other security flaws by following the longest chain?
Michael Fletcher
CC BY-SA 4.0
2020-07-29T10:38:37.060Z
Yes, a sufficiently motivated attacker could build a chain with increasingly lower difficulty and just mine enough blocks to be longer than the current mainnet chain - ASICs would make short work of mining as many blocks as you want on top of an early Bitcoin block as long as the difficulty was kept low
Raghav Sood
CC BY-SA 4.0
2020-07-29T10:41:47.897Z
The key difference of that against the question is that the difficulty on that chain would still increase unless blocks are mined at exactly the right rate - mining a chain from genesis to be longer than the current one will still take a while, since you can't go super fast without increasing the difficulty, as that would violate other consensus rules and make your chain invalid
Raghav Sood
CC BY-SA 4.0
2020-07-29T10:57:04.073Z
I'm guessing in that scenario, the bad actor could just change the timestamp of bad blocks being synchronized and your node would have no way of telling the difference right? And would assume the difficulty = 1.
Michael Fletcher
CC BY-SA 4.0
2020-07-29T10:59:24.507Z
Provided the timestamps match the timestamp consensus rules (Block N's timestamp must be within +/- 2 hours of the median timestamps of the previous 11 blocks), yes, you could fake timestamps on a privately mined chain. However, it would still take you inordinately long to mine the 600k+ blocks you need to beat the current chain. It's not impossible, but it would usually be more practical to pick a recent block as the starting point for your private chain and lower the difficulty to speed up your mining
Raghav Sood
CC BY-SA 4.0
2020-07-29T11:00:30.403Z
I understand now. Thanks very much for your answers.
Michael Fletcher
CC BY-SA 4.0
2020-07-29T10:15:02.877Z
2020-07-29T10:15:02.877Z
Raghav Sood
<p>I'm reading mixed things online - some saying to follow the longest chain, and some say to follow the chain with the most work. But I'm not convinced of the former.</p>
<p>If the node follows the longest chain, what is to stop the scenario of a bad actor sending a completely false chain to my node with a really easy target of 1? The chain could be longer than the main chain, and I can't see any consensus mechanisms preventing that chain from technically being invalid.</p>
<p>If following the chain with the most work is the way to go, then how can we verify most work? Is it just a case of following the chain with the lowest integer value for its hash (as my understanding is that the hash needs to be below an ever-increasing target, and shrinks in size as more miners join the chain)?</p>
<p>Any guidance would be much appreciated.</p>

<consensus><best-chain>
Should a node follow the longest chain, or the chain with most work while syncing?
Michael Fletcher
# Should a node follow the longest chain, or the chain with most work while syncing?

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

I'm reading mixed things online - some saying to follow the longest chain, and some say to follow the chain with the most work. But I'm not convinced of the former.

If the node follows the longest chain, what is to stop the scenario of a bad actor sending a completely false chain to my node with a really easy target of 1? The chain could be longer than the main chain, and I can't see any consensus mechanisms preventing that chain from technically being invalid.

If following the chain with the most work is the way to go, then how can we verify most work? Is it just a case of following the chain with the lowest integer value for its hash (as my understanding is that the hash needs to be below an ever-increasing target, and shrinks in size as more miners join the chain)?

Any guidance would be much appreciated.

**Tags:** consensus, best-chain


---

## 1 answers

### Answer by username_1 on 2020-07-29. Score: 2 | Accepted answer

Nodes follow the chain with the most *cumulative* work, not the lowest hash of the latest block (which would be most work for the current block).

> **Comments:**
> **username_0**: Ah yes, good point - so translating the lowest hash into a measurable unit to represent work, and summing them as blocks are appended to the chain(s) will give me an idea of how much work has gone into each tip?  
> **username_1**: Precisely - the formal term is `chainwork`, you can see how it is calculated [here](https://learnmeabitcoin.com/technical/longest-chain) and [here](https://bitcoin.stackexchange.com/q/26869/7272).  
> **username_0**: Thanks man. In regard to following the 'longest' chain, is my example potentially an attack vector? are there any other security flaws by following the longest chain?  
> **username_1**: Yes, a sufficiently motivated attacker could build a chain with increasingly lower difficulty and just mine enough blocks to be longer than the current mainnet chain - ASICs would make short work of mining as many blocks as you want on top of an early Bitcoin block as long as the difficulty was kept low  
> **username_1**: The key difference of that against the question is that the difficulty on that chain would still increase unless blocks are mined at exactly the right rate - mining a chain from genesis to be longer than the current one will still take a while, since you can't go super fast without increasing the difficulty, as that would violate other consensus rules and make your chain invalid  
> **username_0**: I'm guessing in that scenario, the bad actor could just change the timestamp of bad blocks being synchronized and your node would have no way of telling the difference right? And would assume the difficulty = 1.  
> **username_1**: Provided the timestamps match the timestamp consensus rules (Block N's timestamp must be within +/- 2 hours of the median timestamps of the previous 11 blocks), yes, you could fake timestamps on a privately mined chain. However, it would still take you inordinately long to mine the 600k+ blocks you need to beat the current chain. It's not impossible, but it would usually be more practical to pick a recent block as the starting point for your private chain and lower the difficulty to speed up your mining  
> **username_0**: I understand now. Thanks very much for your answers.  

---

