nBits

[manuelra]

Suppose that a bad miner (who intends to attack the network) sucessfully mines a block for which the found hash has several zeros more than the current required POW effort. If this miner sets the nBits field on the mined block header to a value much higher than the current POW target, but compatible with hash it has found for that block AND that block is the 2016th at a given target level, what will the other nodes do?

a) reject that block because its header contains an incorrect difficulty level value
b) accept that block and choose a very hard difficulty level - which will decay only after having a hard time minning the next 2016 blocks, a process that will likely take substancially more than 2 weeks

Notes:

• GetNextWorkRequired uses nBits from the latest block to compute the new difficulty level;
• Apparently CheckProofOfWork checks the hash against the nBits field within the block itself, not against a locally computed dificulty target at a given height - which would be independent of the node which published the block;
• I did not check whether the code checks that nBits is checked against such a locally computed difficulty target

See https://github.com/bitcoin/bitcoin/blob/57b34599b2deb179ff1bd97ffeab91ec9f904d85/src/pow.cpp for details.

Edit: the target effort will not increase by more that 4x, as coded within GetNextWorkRequired

[1715158708]

1715158708

[1715158708]

1715158708

[piotr_n]

Suppose that a bad miner (who intends to attack the network) sucessfully mines a block for which the found hash has several zeros more than the current required POW effort. If this miner sets the nBits field on the mined block header to a value much higher than the current POW target, but compatible with hash it has found for that block AND that block is the 2016th at a given target level, what will the other nodes do?

The bits field must have the exact expected value, otherwise the block gets rejected (ignored) by the nodes.
Harder or lighter - doesn't matter, it would be still invalid.

[ArcCsch]

The difficulty is hashed with the block, so if the attacker changes the difficulty, the hash would change (avalanche effect) and it would be back to square one.
The PoW is invalidated by changing any of the confirmed data, and this includes nBits.
This feature was included intentionally to prevent this.

[dreamhouse]

The current block hash depends on the previous block hash, so even you solve one with higher diff you won't be able to "save" it for the next block, as your hash will be rejected.

[DannyHamilton]

- snip -
The bits field must have the exact expected value, otherwise the block gets rejected (ignored) by the nodes.
Harder or lighter - doesn't matter, it would be still invalid.

That's what I assumed, but I hadn't taken the time to go find the lines of code in Core that make that comparison.  Since you seem to have found it, can you link to it here please, and save me the time of searching for it?

[piotr_n]

- snip -
The bits field must have the exact expected value, otherwise the block gets rejected (ignored) by the nodes.
Harder or lighter - doesn't matter, it would be still invalid.

That's what I assumed, but I hadn't taken the time to go find the lines of code in Core that make that comparison.  Since you seem to have found it, can you link to it here please, and save me the time of searching for it?

I saw it long ago, needing to know how to implement it inside my shit.

It's moved all around the code base ever since, but look for the place where GetNextWorkRequired() is called from.

ATM it's in file validation.cpp:

Code:

bool ContextualCheckBlockHeader(const CBlockHeader& block, CValidationState& state, const Consensus::Params& consensusParams, const CBlockIndex* pindexPrev, int64_t nAdjustedTime)
{
    const int nHeight = pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1;
    // Check proof of work
    if (block.nBits != GetNextWorkRequired(pindexPrev, &block, consensusParams))
        return state.DoS(100, false, REJECT_INVALID, "bad-diffbits", false, "incorrect proof of work");