Why is my block being rejected for having "high hash"?

[Coding Enthusiast]

Using bitcoin core 0.21.0 on RegTest.
Block #101 with the default RegTest target of 0x207fffff
Full header is

Code:

00000020c21aa3b43d104b5db7eb46d90430308b668b4edebdd23d72ba6cfc685601f1666769ae0d507824c9b1220f02db880618240a6b5dff17c1319a443eadd4b218e7a76c3360ffff7f2000000000

Hash versus target:

Code:

6f295fbd976fd8dd1668bf4ba82b8e7b2089c3497cf3f9dc4a61beb519992958
7fffff0000000000000000000000000000000000000000000000000000000000

50279827699679515341806937817482573096355300064251967888806579886749916932440
57896037716911750921221705069588091649609539881711309849342236841432341020672

This block is being rejected by core with a short message only saying "high-hash".

[NotATether]

The high-hash message comes from CheckBlockHeader().

Your block's target is less the difficulty so there's some other reasons why PoW checking can fail like if the difficulty became negative or zero (definitely neither are the case here) or overflowed the arith_uint256 type.

What were the previous difficulties before this block was mined, does the debug.log give you that information?

[Coding Enthusiast]

What were the previous difficulties before this block was mined,

Difficulty does not change on RegTest due to fPowNoRetargeting in chainparams being true.

[NotATether]

What were the previous difficulties before this block was mined,

Difficulty does not change on RegTest due to fPowNoRetargeting in chainparams being true.

The only other explanation I can find for this is your target (7fffff0000000000000000000000000000000000000000000000000000000000) is greater than powLimit in chainparams (00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff).

Again, this is RegTest not MainNet/TestNet.

D'oh! I keep forgetting that regtest has separate chainparams. 

[Coding Enthusiast]

The only other explanation I can find for this is your target (7fffff0000000000000000000000000000000000000000000000000000000000) is greater than powLimit in chainparams (00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff).

Again, this is RegTest not MainNet/TestNet.

[j2002ba2]

Using bitcoin core 0.21.0 on RegTest.
Block #101 with the default RegTest target of 0x207fffff
Full header is

Code:

00000020c21aa3b43d104b5db7eb46d90430308b668b4edebdd23d72ba6cfc685601f1666769ae0d507824c9b1220f02db880618240a6b5dff17c1319a443eadd4b218e7a76c3360ffff7f2000000000

Hash versus target:

Code:

6f295fbd976fd8dd1668bf4ba82b8e7b2089c3497cf3f9dc4a61beb519992958
7fffff0000000000000000000000000000000000000000000000000000000000

50279827699679515341806937817482573096355300064251967888806579886749916932440
57896037716911750921221705069588091649609539881711309849342236841432341020672

This block is being rejected by core with a short message only saying "high-hash".

The hash should be big-endian, what you showed is little-endian.

The hash of the header you presented is:

Code:

58299919b5be614adcf9f37c49c389207b8e2ba84bbf6816ddd86f97bd5f296f

Investigating further, looks like you represented both previous block hash and merkle tree hash as little-endian.

Proper block header would be:

Code:

0000002066f1015668fc6cba723dd2bdde4e8b668b303004d946ebb75d4b103db4a31ac2e718b2d4ad3e449a31c117ff5d6b0a24180688db020f22b1c92478500dae6967a76c3360ffff7f2000000000

with hash:

Code:

809aaeb27a59de0964d3990c5e4a9f7476af154aa6acc8371fcf7571fc9b7f30

EDIT:
Got it wrong. Still think endianness is the reason somehow.

[Coding Enthusiast]

I'm certain that I'm treating the hashes (as byte arrays) correctly when endianness is involved. I reversed the representation in OP to match the target for comparison. Example from MainNet (https://blockchair.com/bitcoin/block/671722)
Hash versus target:

Code:

00000000000000000008c90b8dee0008278ca56789f139f9ff7be2f977ec417f
0000000000000000000cf4e30000000000000000000000000000000000000000

 841467685476732827911127349510066616063651554981069183
1240994654795328278613867476210548386499304408689410048

If the hash is treated as big-endian the value becomes:

Code:

57560208875972853161925838977827675218798852263361504163342752395230296670208

Which is bigger than target.

[j2002ba2]

Looks like "version", "time", "bits", and "nonce" are correct.

hashPrevBlock and hashMerkleRoot have to be little endian.

Maybe there's a problem with switching endianness, i.e. reversing the string representation instead of bytes.

What is the previous block header, and the merkle tree?

[Coding Enthusiast]

Block header for block 100 mined by core itself:

Code:

00000020c791d05aa2685427efbed5aca7e34f489ef6d58ee3e91bf6b67c00dbfbeb740ce7b88553a2c45b2cdcd40cbdc9383c5416b04eafdf0dce0416811996f3ffebe9a76c3360ffff7f2001000000

Full block 101 mined by me:

Code:

00000020c21aa3b43d104b5db7eb46d90430308b668b4edebdd23d72ba6cfc685601f1666769ae0d507824c9b1220f02db880618240a6b5dff17c1319a443eadd4b218e7a76c3360ffff7f200000000002020000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff020165ffffffff010000000000000000266a24aa21a9ed7449fade047d4b8d52203c5c4e3a012f3c0d3575c6a52d21c9e9ac939276f2c8012000000000000000000000000000000000000000000000000000000000000000006500000002000000000101d511b7b4b2ec6f5b10701477f84176a55d64fa34651b736ff76b584713ef63060000000000ffffffff010000000000000000000247304402207e21cd1011c8e85fbd53f9fa8dbb66d2273b4a5e8d613aebd4087fb5d5ccd617022079ac2221cf6f94543b2578dd769572f4eed1d3d1fa9c6becd38cdd97879d3013012103b22377af55fb3e741fbda2de0c534cdc963ab9480c3890a8b739266e45af2d2b00000000

The code that was used:
https://gist.github.com/Coding-Enthusiast/ce0bcb3baa565f7dc88d94dc96406f2a

I shut down my Ubuntu and the chain was lost (running in VM since I don't have it installed). Starting from scratch, all the blocks I'm mining today (from block 1 to 11) are accepted without any problem now! You can see block 11 has a similar hash as the block in OP.

Code:

11 6ffbdf74bc56e1194c7b2ff21144a61eb17cb47c18814e79f259e8d6df11b47a
10 1a9e839826f491d53eb941f6d87f0d3db55686c7e42a2298f5791c00b65b5fd2
09 4bb35dfe7036de27ae175c5af3f0f25c072594f54e9c8d6ef2221969bfc2de8e
08 4f33a75fd579977c66ed89c7e550da46d413812cf9e129c6996ca8395362789b
07 6d4d097851286dc8a400d2a37db04f4cd2155636ab4967fd3eccbef7d77dcf53
06 0a441c697df49738f4509ea96b548f4191cc17896f166846e11277cb3c136ba9
05 77fdf3ac36f2db6dd0df7e037bb67fb2e9330741ed05e334ebc89f515232325c
04 31105e4aff1fb26365799956361a5288337675c4ecc0a24af7e4cc95e32f0415
03 3b4dc8350c5750005b12879015b444d747809142b3ae03b406c5ca587585ebc9
02 1f868d7146d6b85ae46adc4fe009428d0a462e49e13f7d22a8aba12645e52961
01 398b265b84c00da9cb55bf680ab2dd8130062eeff42e13136717fbea0f179070
00 0f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206

[j2002ba2]

Looks like it fails when you include transaction other than coinbase. Witness commitment must be wrong.