user109863: 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.

user5406: 
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?). 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.

Full nodes that freshly join the network validate the complete blockchain unilaterally (only depending on finding a single source of correct data)
Full nodes sync only the block headers first, which already must fulfill the required difficulty and must adhere to the difficulty retargeting rules
The "longest-chain" rule is an imprecise moniker for what is happening, it's actually "most total work"¹
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.
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.

user13866: 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 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.
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.

109863: <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>
 5406: <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>
 13866: <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>
