<p>Recall from the <a href="https://bitcoin.org/bitcoin.pdf" rel="nofollow">Nakamoto Whitepaper</a> 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].  </p>

<p>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.</p>

<p>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.</p>

<p>[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.</p>

CC BY-SA 3.0
2014-12-23T22:16:19.667Z
`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
CC BY-SA 3.0
2014-12-23T23:08:58.833Z
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
CC BY-SA 3.0
2014-12-23T23:17:21.963Z
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
CC BY-SA 4.0
2018-11-07T17:58:01.183Z
[doc](https://bitcoin.org/en/operating-modes-guide#simplified-payment-verification-spv) 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
CC BY-SA 4.0
2018-11-08T09:09:29.440Z
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
CC BY-SA 3.0
2014-12-23T21:58:56.460Z
2014-12-23T23:16:00.080Z
2014-12-23T23:16:00.080Z
David A. Harding
<p>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. </p>

<p>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? <strong>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.</strong> </p>

<p>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?</p>

<difficulty><block-header>
Is it necessary for blocks to record the nBits difficulty parameter?
morsecoder
# Is it necessary for blocks to record the nBits difficulty parameter?

(Asked by: username_0 on 2014-12-23)

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?

**Tags:** difficulty, block-header


---

## 1 answers

### Answer by username_1 on 2014-12-23. Score: 3 | Accepted answer

Recall from the [Nakamoto Whitepaper](https://bitcoin.org/bitcoin.pdf) 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.

> **Comments:**
> **username_2**: `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.  
> **username_1**: 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.  
> **username_1**: 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.  
> **username_3**: [doc](https://bitcoin.org/en/operating-modes-guide#simplified-payment-verification-spv) 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;  
> **username_4**: 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).  

---

