0

I'm sending this json to bitcoind server running in regtest mode:

{"jsonrpc": 2.0,
 "id": "cumainer",
 "method": "submitblock",
 "params": ["000000200f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206a2db7dd515bcb1592ad65c2d5963e217120876d742f7b10d77d1a481017f4fb1ffff7f20a228fa6462a200000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff00000000010000000000000001000000000000000000000000a228fa64"] 
}

First 80 bytes are my block header, 1 meaning the number of transactions and my coinbase transaction in raw hex.

My regtest server is fresh and it has only one block.

For some reason I always get "high-hash" result from the server. However if I take first 80 bytes (block header size) of my "params" string and double hash it I get a string with few zeros at the beggining. getblocktemplate request gives me the first difficulty (0x207fffff = the easiest one) and I'm sending it back in little endian order as stated on submitblock reference (I actually tried sending in big-endian too).

So the double sha256 hash of my block header is clearly smaller than the target. What does this error mean then ? What I am doing wrong ? Is it the byte order? Maybe the problem is actually with the merkle root hash ?

1 Answer 1

2

I tried to make sense of the data you submitted:

000000200f9188f13cb7b2c71f2a335e3a4fc328bf5beb436012afca590b1a11466e2206a2db7dd515bcb1592ad65c2d5963e217120876d742f7b10d77d1a481017f4fb1ffff7f20a228fa6462a200000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff00000000010000000000000001000000000000000000000000a228fa64

Here's how far I got before giving up

Hex Should be Concerns
00000020 block version? Digit order looks reversed!
0f9188f13cb7b2c7 1f2a335e3a4fc328 bf5beb436012afca 590b1a11466e2206 ID of prior block
a2db7dd515bcb159 2ad65c2d5963e217 120876d742f7b10d 77d1a481017f4fb1 merkle root
ffff7f20 timestamp This looks wrong! Looks like target bits in wrong place
a228fa64 target bits Probably misplaced timestamp or nonce?
62a20000 nonce Could be a valid timestamp in wrong place?
01 block contains 1 transaction
01000000 tx version
01 tx has one input
0000000000000000 0000000000000000 0000000000000000 0000000000000000 referenced txid (all 0 for coinbase input)
ffffffff vout index (for coinbase input)
00 length of unlocking script What about BIP34?
00000001 sequence? Normally ffffffff
00 number of outputs Can't be zero!
00000000 Locktime
00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 Surplus data?
a228fa64 Repeat of data in target bits! So potentially intended as a locktime?

Maybe I am mistaken but that data doesn't look right to me

I recommend reading

2
  • The vout index for a coinbase input actually has to be 0xffffffff. Sep 9, 2023 at 12:22
  • @Pieter thanks for pointing that out, answer corrected accordingly Sep 9, 2023 at 14:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.