3

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.

Improve this question
1

2 Answers 2

Reset to default
4

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.

Improve this answer
6
  • 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 ♦
    Commented Sep 17, 2020 at 14:52
  • 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 ♦
    Commented Sep 17, 2020 at 14:52
  • 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
    Commented Sep 17, 2020 at 17:57
  • @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
    Commented Sep 17, 2020 at 17:57
  • @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 ♦
    Commented Sep 17, 2020 at 18:14
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?). 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 .

  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.

Improve this answer
0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.