<blockquote>
<p>However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.</p>
</blockquote>
<p>The Bitcoin network's backbone is spanned by fully validating nodes (&quot;full nodes&quot;). This type of Bitcoin client participates in the peer-to-peer network by unilaterally validating and enforcing all rules of the Bitcoin protocol. They rely on their peers to provide information, but can individually assess the validity thereof. Each and every full node has parsed the complete blockchain from scratch to converge to the network's current state.</p>
<p>The difficulty target of Bitcoin blocks is updated every 2016 blocks. Hereby the new difficulty is a function of the time the previous difficulty period took and the previous difficulty. If the previous 2015 blocks were found in less time than a fortnight, the difficulty increases and if the blocks took longer the difficulty decreases (see <a href="https://bitcoin.stackexchange.com/a/5840/5406">How is difficulty calculated?</a>). Since each full node processed the complete blockchain from the genesis block, they are aware of and have validated the difficulty and timestamps of the previous blocks. Hence, each node knows exactly which difficulty to expect for the next block. Therefore, an attacker's &quot;forged&quot; blockchain tip with a long-chain of low-difficulty blocks would not match the expected difficulty statement and thus be found invalid by every full node in the network. Since full nodes don't relay invalid information, the attacker's chain would also not be broadcast beyond his peers.</p>
<p>Further, &quot;longest chain&quot; is a bit of a misnomer, actually the best chain tip is determined by the highest accumulated difficulty. If e.g. an attacker would fork off from the Genesis Block and mine 1,000,000 blocks with the minimum difficulty, their chain would be &quot;longer&quot;, but have less total difficulty and would not be consider. Besides, the attacker would also need to fake the timestamps or any nodes that tried to follow the chain would expect a different difficulty after the first retarget, and this causes problems further down the road when full nodes don't accept blocks with timestamps that are more than two hours in the future.</p>
<blockquote>
<p>I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.</p>
</blockquote>
<p>The scenario has been covered extensively in <a href="/questions/tagged/best-chain" class="post-tag" title="show questions tagged &#39;best-chain&#39;" rel="tag">best-chain</a>.</p>
<ol>
<li>Full nodes that freshly join the network validate the complete blockchain unilaterally (only depending on finding <em>a single</em> source of correct data)</li>
<li>Full nodes sync only the block headers first, which already must fulfill the required difficulty and must adhere to the difficulty retargeting rules</li>
<li>The &quot;longest-chain&quot; rule is an imprecise moniker for what is happening, it's actually &quot;most total work&quot;¹</li>
<li>Light clients can check block headers for self-consistency, could do just a block header sync (each block header is 80 B, so altogether about ~50 MiB today), will ask multiple peers for their best chaintip.</li>
<li>Invalid blocks are not propagated on the network, so light clients benefit from the &quot;herd immunity&quot; of full nodes and are unlikely to be fooled except in conjuction with a highly targeted eclipse attack.</li>
</ol>
<hr />
<p>¹ Actually, this was a bug in the original implementation that really only checked the height which was fixed by replacing it with total work.</p>

CC BY-SA 4.0
2020-09-17T18:45:31.693Z
2020-09-17T18:45:31.693Z
Murch
<p>It isn't strictly the longest chain that is chosen, it is the chain that has accumulated the most work (proof of work).</p>
<p>The reason miners can't fake the difficulty is that every node checks the difficulty of every new block. An attacker who faked this would never be able to spend the proceeds and would become isolated from other nodes as a known bad node.</p>
<p>Nodes that freshly joined do know the current difficulty. It is simple to calculate, I think you only need check a few peer nodes to find a relatively small amount of block-header data from the blockchain. That takes very little time.</p>
<blockquote>
<p>The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks.</p>
</blockquote>
<p>So, (hat tip to Murch for clarifying comment) as the difficulty only changes every 2016 blocks and block headers contain a timestamp and the difficulty target, you just need the headers of a few blocks prior to the block being checked. This is a tiny fraction of the ~650,000 blocks created so far in the blockchain and so takes negligible effort compared to syncing a local copy of the full blockchain.</p>
<p>Even if newly joined nodes were ignorant, the vast majority of nodes are not newly joined and would result in the faked block being completely useless and irrelevant due to being independently checked and rejected by virtually all nodes.</p>
<p>Miners are producing a kind of hash of a set of data. The carefully chosen mathematical functions make this hash extremely expensive and time-consuming to create but extremely cheap and quick to verify.</p>

CC BY-SA 4.0
2020-09-17T14:52:07.337Z
Nit: It's implied, but you could be more explicit: One of the block header elements is the difficulty target. A block which doesn't fulfill its own difficulty statement is trivially invalid just from its own header. Since the difficulty can only change every 2016 blocks, for 2015 blocks out 2016 it's sufficient to compare with the previous block's difficulty statement and only for the first block in a new difficulty period you'd need to check the timestamps of the first and the last block in the period.
Murch
CC BY-SA 4.0
2020-09-17T14:52:54.643Z
So, strictly speaking, you could calculate the new difficulty statement from at most two block headers (If you already know/trust that the blocks are both part of the best chain). And the nitty part was supposed to be that the block won't just become stale, but would actually be rejected as invalid by any full node and even most light clients.
Murch
CC BY-SA 4.0
2020-09-17T17:57:22.007Z
Thanks to you both :)
@Murch I see your point, but: As an attacker I'd just choose any difficulty target on my forged blockchain to make my blocks consistent.
Max Beikirch
CC BY-SA 4.0
2020-09-17T17:57:25.753Z
@RedGrittyBrick Well, as a large attacker I suppose I can trick new nodes into believing *my* difficulty (if the first peer nodes the fresh node sees are mine).
But - of course, if the length of a chain is defined as the sum of the individual blocks' difficulty - then the attacker needs to match the average difficulty of the network. Else, he will not be able to get a longer chain.
Max Beikirch
CC BY-SA 4.0
2020-09-17T18:14:16.453Z
@MaxBeikirch: The difficulty is inductively dependent on the previous difficulty and the timestamps of the blocks. Nodes don't trust other nodes to tell them what to check, rather each and every node will unilaterally find and enforce the difficulty they expect (as well as all other consensus rules of the Bitcoin protocol).
Murch
CC BY-SA 4.0
2020-09-17T18:17:52.060Z
If you choose any other difficulty than the specific difficulty that is currently the correct one, your block will appear invalid to all fully validating nodes. They'll reject your block and ban your node for sending invalid data. Anyway it wouldn't help you, because the best-chain is determined by total proof of work and not by count of blocks.
Murch
CC BY-SA 4.0
2020-09-17T13:43:39.967Z
2020-09-17T15:21:58.290Z
2020-09-17T15:21:58.290Z
RedGrittyBrick
<p>by the longest-chain-rule, the chain with the most blocks is considered to be the main chain in Bitcoin. I understand that an adversary needs to have more than 50% of the network's computing power in order to create its chains faster than the rest of the network. Those chains become the main chain under the longest-chain-rule.</p>
<p>However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.</p>
<p>I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.</p>

CC BY-SA 4.0
2020-09-17T14:54:51.570Z
Possible duplicate of https://bitcoin.stackexchange.com/q/25170/5406, also see: [tag:best-chain]
Murch
<difficulty><best-chain>
Bitcoin: Why can the difficulty parameter not be ignored?
Max Beikirch
# Bitcoin: Why can the difficulty parameter not be ignored?

(Asked by: username_0 on 2020-09-17)

by the longest-chain-rule, the chain with the most blocks is considered to be the main chain in Bitcoin. I understand that an adversary needs to have more than 50% of the network's computing power in order to create its chains faster than the rest of the network. Those chains become the main chain under the longest-chain-rule.

However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.

I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.

**Tags:** difficulty, best-chain

> **Comments:**
> **username_1**: Possible duplicate of https://bitcoin.stackexchange.com/q/25170/5406, also see: [tag:best-chain]  

---

## 2 answers

### Answer by username_2 on 2020-09-17. Score: 4 | Accepted answer

It isn't strictly the longest chain that is chosen, it is the chain that has accumulated the most work (proof of work).

The reason miners can't fake the difficulty is that every node checks the difficulty of every new block. An attacker who faked this would never be able to spend the proceeds and would become isolated from other nodes as a known bad node.

Nodes that freshly joined do know the current difficulty. It is simple to calculate, I think you only need check a few peer nodes to find a relatively small amount of block-header data from the blockchain. That takes very little time.

> The difficulty is adjusted every 2016 blocks based on the time it took to find the previous 2016 blocks.

So, (hat tip to username_1 for clarifying comment) as the difficulty only changes every 2016 blocks and block headers contain a timestamp and the difficulty target, you just need the headers of a few blocks prior to the block being checked. This is a tiny fraction of the ~650,000 blocks created so far in the blockchain and so takes negligible effort compared to syncing a local copy of the full blockchain.

Even if newly joined nodes were ignorant, the vast majority of nodes are not newly joined and would result in the faked block being completely useless and irrelevant due to being independently checked and rejected by virtually all nodes.

Miners are producing a kind of hash of a set of data. The carefully chosen mathematical functions make this hash extremely expensive and time-consuming to create but extremely cheap and quick to verify.

> **Comments:**
> **username_1**: Nit: It's implied, but you could be more explicit: One of the block header elements is the difficulty target. A block which doesn't fulfill its own difficulty statement is trivially invalid just from its own header. Since the difficulty can only change every 2016 blocks, for 2015 blocks out 2016 it's sufficient to compare with the previous block's difficulty statement and only for the first block in a new difficulty period you'd need to check the timestamps of the first and the last block in the period.  
> **username_1**: So, strictly speaking, you could calculate the new difficulty statement from at most two block headers (If you already know/trust that the blocks are both part of the best chain). And the nitty part was supposed to be that the block won't just become stale, but would actually be rejected as invalid by any full node and even most light clients.  
> **username_0**: Thanks to you both :) @username_1 I see your point, but: As an attacker I'd just choose any difficulty target on my forged blockchain to make my blocks consistent.  
> **username_0**: @username_2 Well, as a large attacker I suppose I can trick new nodes into believing *my* difficulty (if the first peer nodes the fresh node sees are mine). But - of course, if the length of a chain is defined as the sum of the individual blocks' difficulty - then the attacker needs to match the average difficulty of the network. Else, he will not be able to get a longer chain.  
> **username_1**: @username_0: The difficulty is inductively dependent on the previous difficulty and the timestamps of the blocks. Nodes don't trust other nodes to tell them what to check, rather each and every node will unilaterally find and enforce the difficulty they expect (as well as all other consensus rules of the Bitcoin protocol).  
> **username_1**: If you choose any other difficulty than the specific difficulty that is currently the correct one, your block will appear invalid to all fully validating nodes. They'll reject your block and ban your node for sending invalid data. Anyway it wouldn't help you, because the best-chain is determined by total proof of work and not by count of blocks.  

---

### Answer by username_1 on 2020-09-17. Score: 3

> However, that implies that the adversary sticks to the network's difficulty setting. If it didn't, it could create longer chains using much less computing power.

The Bitcoin network's backbone is spanned by fully validating nodes ("full nodes"). This type of Bitcoin client participates in the peer-to-peer network by unilaterally validating and enforcing all rules of the Bitcoin protocol. They rely on their peers to provide information, but can individually assess the validity thereof. Each and every full node has parsed the complete blockchain from scratch to converge to the network's current state.

The difficulty target of Bitcoin blocks is updated every 2016 blocks. Hereby the new difficulty is a function of the time the previous difficulty period took and the previous difficulty. If the previous 2015 blocks were found in less time than a fortnight, the difficulty increases and if the blocks took longer the difficulty decreases (see [How is difficulty calculated?](https://bitcoin.stackexchange.com/a/5840/5406)). Since each full node processed the complete blockchain from the genesis block, they are aware of and have validated the difficulty and timestamps of the previous blocks. Hence, each node knows exactly which difficulty to expect for the next block. Therefore, an attacker's "forged" blockchain tip with a long-chain of low-difficulty blocks would not match the expected difficulty statement and thus be found invalid by every full node in the network. Since full nodes don't relay invalid information, the attacker's chain would also not be broadcast beyond his peers.

Further, "longest chain" is a bit of a misnomer, actually the best chain tip is determined by the highest accumulated difficulty. If e.g. an attacker would fork off from the Genesis Block and mine 1,000,000 blocks with the minimum difficulty, their chain would be "longer", but have less total difficulty and would not be consider. Besides, the attacker would also need to fake the timestamps or any nodes that tried to follow the chain would expect a different difficulty after the first retarget, and this causes problems further down the road when full nodes don't accept blocks with timestamps that are more than two hours in the future.

> I wonder: Why is this setting (an adversary ignoring the difficulty and mining a long chain) not considered? Nodes that freshly join the network don't know about the difficulty and, according to the longest-chain-rule, must choose the adversary's chain.

The scenario has been covered extensively in [best-chain](/questions/tagged/best-chain "show questions tagged 'best-chain'").

1. Full nodes that freshly join the network validate the complete blockchain unilaterally (only depending on finding *a single* source of correct data)
2. Full nodes sync only the block headers first, which already must fulfill the required difficulty and must adhere to the difficulty retargeting rules
3. The "longest-chain" rule is an imprecise moniker for what is happening, it's actually "most total work"¹
4. Light clients can check block headers for self-consistency, could do just a block header sync (each block header is 80 B, so altogether about ~50 MiB today), will ask multiple peers for their best chaintip.
5. Invalid blocks are not propagated on the network, so light clients benefit from the "herd immunity" of full nodes and are unlikely to be fooled except in conjuction with a highly targeted eclipse attack.

---

¹ Actually, this was a bug in the original implementation that really only checked the height which was fixed by replacing it with total work.


---

