Strange value for difficulty in getblockchaininfo

[NotATether]

I'm not sure whether this is a bug or a feature of Bitcoin Core, but apparently when the initial block download finishes syncing, it sometimes emits a hardcoded or dummy value for difficulty?

{
  "chain": "main",
  "blocks": 970155,
  "headers": 970155,
  "bestblockhash": "000000000000000000008b15de051d9225324208a7ab0f167e92aab766fa33ef",
  "difficulty": 123456789012345.67,
  "time": 1791281477,
  "mediantime": 1791276922,
  "verificationprogress": 1,
  "initialblockdownload": true,
  "chainwork": "000000000000000000000000000000000000000000000000000000a83d7655dde2f94d7e2e0",
  "size_on_disk": 2491382915,
  "pruned": true,
  "pruneheight": 558358,
  "automatic_pruning": true,
  "prune_target_size": 6463886300,
  "warnings": [
  ]
}

This person's node had normal difficulty difficulty and chainwork values previously. This chainwork has slightly more zeroes that puts it over 64 chars, and in fact I have observed some other people's chainwork values, and they also have more or less zeroes than the 64-character length. So what gives?

[LoyceV]

I'm not sure whether this is a bug or a feature of Bitcoin Core, but apparently when the initial block download finishes syncing, it sometimes emits a hardcoded or dummy value for difficulty?

 "difficulty": 123456789012345.67,

~ I have observed some other people's chainwork values, and they also have more or less zeroes than the 64-character length. So what gives?

Could it be they're faking this data to get Merit without running a node? I wouldn't assume this data is correct without reproducing it.

[Cookdata]

This does not look like a bug, but since you said the previous reports of difficulty are normal, I don't know how to describe it.  A fully synced verification is supposed to be false if the initial block download has reached the chain tip, but I noticed the output shows true. You can see the blocks, and the headers are synced to the tip at 970155, while the verification is true. I'm not sure what to call this, probably a bug from another implementation, maybe this is not core.

Another thing about the difficulty is that the numbers looks too strange, like a typical integers 12345679-012345.67. I also verified the block hash, I don't know why the block hash from his report and the block hash from my block header are not returning the same difficulty and chainwork.

Code:

{
  "hash": "000000000000000000008b15de051d9225324208a7ab0f167e92aab766fa33ef",
  "confirmations": 197,
  "height": 970155,
  "version": 646217728,
  "versionHex": "26848000",
  "merkleroot": "c4e834db3a42428668162ee1599349c5fa7bf485e193c5236e5c60838e3cc817",
  "time": 1791277877,
  "mediantime": 1791275059,
  "nonce": 1073445946,
  "bits": "17021ef0",
  "target": "000000000000000000021ef00000000000000000000000000000000000000000",
  "difficulty": 132716002350731.3,
  "chainwork": "00000000000000000000000000000000000000014d33450abbc365f0f1251c80",
  "nTx": 3730,
  "previousblockhash": "0000000000000000000050051cd434e56fbeeeb47c9e4fec153d66244c95963a",
  "nextblockhash": "000000000000000000019fbf2a8327e183e680c92237da28624e0bf7f6f32662"
}

We have the same block height and block hash, but not the same difficulty and chain work. This report doesn't look like a bug.

[BlackHatCoiner]

If Core started emitting that as a "dummy value", miners would be the first to notice. The pruneheight neither makes sense. 558358 means roughly ~400k blocks kept on disk, crammed into 2.49 GB (size_on_disk). That doesn't make any sense at all.

It seems like someone's terrible at editing screenshots to earn merits.

[Cricktor]

This is from one of my archival nodes which has been running for years (not years of uptime, of course):

Code:

$ bitcoin rpc getblockchaininfo
{
  "chain": "main",
  "blocks": 970382,
  "headers": 970382,
  "bestblockhash": "000000000000000000019ea373aecab3b1714e714f9fbde6a26ac1a0bc49b0e8",
  "bits": "17021ef0",
  "target": "000000000000000000021ef00000000000000000000000000000000000000000",
  "difficulty": 132716002350731.3,
  "time": 1791402763,
  "mediantime": 1791397762,
  "verificationprogress": 1,
  "initialblockdownload": false,
  "chainwork": "00000000000000000000000000000000000000014d9e4d61ba1561c1ac5586e8",
  "size_on_disk": 882250696933,
  "pruned": false,
  "warnings": [
  ]
}

I don't know what to say, if some merit leechers in "run a node challenges" actually fake and edit values and screenshots without brain. It's a sad world...

[nc50lc]

It seems like someone's terrible at editing screenshots to earn merits.

The screenshot in the OP doesn't look bad  
His AI tool did a pretty good job on it aside from inconsistent arrow designs.

But these "Day 11" and "Day 12" report's screenshot have so many badly warped strings that it's undoubtedly edited (suspiciously AI-edited):

->Weird symbol after the 0's in bestblockhash.
archive: bitlist.co/post/67204660

->The zeroes are warped and misaligned with the rest of the characters.
archive: bitlist.co/post/67206008

[NotATether]

The screenshot in the OP doesn't look bad  
His AI tool did a pretty good job on it aside from inconsistent arrow designs.

But these "Day 11" and "Day 12" report's screenshot have so many badly warped strings that it's undoubtedly edited (suspiciously AI-edited):

->Weird symbol after the 0's in bestblockhash.
archive: bitlist.co/post/67204660

->The zeroes are warped and misaligned with the rest of the characters.
archive: bitlist.co/post/67206008

Thanks, I knew something was suspicious when my Grok Bot warned me about some discrepancies, but I wanted to confirm with you guys first.

That settles the matter. I'm locking the thread now. Thanks to everyone for their input.