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.

[Tungbulu]

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?

I experience something similar before when I synced my node…. It gave me streams of 0s in the difficulty… I wanted to bring it up here to find out if it was normal, but I kinda forgot…

[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 the bestblockhash.
archive: bitlist.co/post/67204660

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