7

The next difficulty to solve a block is determined from how fast blocks were solved before it. In addition, the difficulty only changes once every two weeks or so.

So, couldn't every node keep track of the expected difficulty and not need to have it in each block header? Or is there a reason nodes need to be communicating the current difficulty in each block? Not that it would be a major savings, or anything, it just seems strange that this is included when it's just a function of all the other pieces of a chain.

Maybe it's because calculating nBits would take a long time eventually if you had to go through all the block headers every time you wanted to calculate the next difficulty?

Vojtěch Strnad
  • 8,292
  • 2
  • 12
  • 40
morsecoder
  • 14,168
  • 2
  • 42
  • 94

1 Answers1

3

Recall from the Nakamoto Whitepaper that for Simplified Payment Verification (SPV) clients, security is measured mainly by the amount of work done to secure a particular transaction. SPV nodes can't use past headers alone to verify that an incoming payment is valid, so there's technically not much need to store past headers[1].

Of course, if you're not going to store all the headers, you need some way to measure difficulty for the headers you do have---and nBits provides that.

Note that storing recent headers can increase an SPV client's security by allowing it to calculate proper difficulty for later headers. This ensures an attacker trying to lie to the client has to create proper-difficulty blocks. Still, a complete headers chain isn't needed here, so nBits is still useful as a starting value.

[1] But BitcoinJ and all other SPV clients I know about still do store complete headers. At a guess, the reason they do is to help them detect chain re-organizations (reorgs) that would render a previously-received payment invalid.

David A. Harding
  • 11,906
  • 2
  • 46
  • 72
  • so there's technically not much need to store past headers What about unconfirmed transactions? You need to look into past blocks to confirm that their inputs are valid. – Nick ODell Dec 23 '14 at 22:16
  • 2
    An essential part of verifying inputs are valid is ensuring that the input (previous output) hasn't been spent yet on the block chain. SPV clients are incapable of doing that since they don't process the complete block chain. SPV clients can only verify the unspentness of inputs for which they control the private keys (wallet transactions), so they're completely dependent on their full node peers for information about unconfirmed non-wallet transactions---if all their peers lie, the SPV client can be fooled. – David A. Harding Dec 23 '14 at 23:08
  • Added a new paragraph to my answer describing how a partial headers chain can be superior security to not storing a headers chain, and why this still means nBits is useful. – David A. Harding Dec 23 '14 at 23:17
  • 1
    doc says a spv client downloads the headers of blocks, but not full blocks; if they download block headers then they can calculate difficulty by themselves; i still dont see why it should be included as a block header field; and nothing mentions how to validate that field; – Cyker Nov 07 '18 at 17:58
  • 1
    A small update: for clients that follow headers-first synchronization (introduced in Bitcoin Core 0.10), the nBits value in headers isn't actually useful anymore (it's always known before a header or block is received already). – Pieter Wuille Nov 08 '18 at 09:09