Still trying to write a function to properly create a coinbase transaction and the only thing I can't seem to get a hold on is..... How to get the block height provided by getblocktemplate into the coinbase transaction? - which I create using the createrawtransaction rpc command. But the thing is, by calling the createrawtransaction and doing

[{"txid":"0000000000000000000000000000000000000000000000000000000000000000","vout":2147483647}]{" insert address ":6.25000000}

, I'd get a processed hash which is to be added as transaction 0 within the list of transactions before building the merklehash.

This is great but this wouldn't be a valid coinbase transaction as the block height is missing!! - Which is needed as the first 8 bytes of the scriptsig within the coinbase transaction.

So it got me thinking, What if the data field after the address field is where I insert the blocks height?

While reading the Official Bitcoin Developer RPC API Reference, I came across a parameter within the createrawtransaction rpc command -- The key must be "data", the value is hex-encoded data and I thought maybe this is where I ought to fill in the height data .... which I would grab from here and maybe somehow parse it with this ; after which I then take the hexadecimal hash and insert it within the data field.

  • Note that Bitcoin doesn't have anything official. The website bitcoin.org is an information site about various aspects of the protocol and implementations, but the RPC documentation you're referring to is specifically that of the Bitcoin Core implementation. Dec 10, 2021 at 23:16

1 Answer 1


The requirement of encoding the block height in the coinbase transaction is specified in BIP34. You may want to read the actual documentation there.

Specifically, it requires the scriptSig of the coinbase's (only) transaction input to start with a push of the height, encoded as a little-endian number. For current mainnet blocks (with height above 65535), the first 4 bytes of the scriptSig have to be [0x03, height % 256, (height >> 8) % 256, height >> 16].

It is not done as an additional output (as a data output would imply), and is not possible directly using createrawtransaction, which is aimed towards general-purpose transactions, not coinbases. Coinbases are generally constructed by mining software.

  • 1
    That's correct. You have to do several other things too, like creating a witness commitment as described in BIP141 if you accept segwit transactions, for example. Dec 10, 2021 at 22:23
  • 1
    The first byte has to be 0x03. The second byte has to have value (height modulo 256). The third byte has to have value (height shifted down by 8 bits, then modulo 256), etc. Dec 10, 2021 at 22:42
  • 1
    That's the same thing. Yes, it is 0x03 plus the 3-byte little endian encoding of the height. Dec 10, 2021 at 22:48
  • 1
    I explained it in my answer. You push the 3-byte value (height % 256, (height >> 8) % 256, height >> 16), which means prepending it with 0x03. Dec 10, 2021 at 23:06
  • 1
    It is also equivalent to pushing the 4-byte LE encoding of the height but with the last byte removed (which will be zero until block 16777215; after that a 4-byte push will be needed, but that's only going to happen in 320 years). Dec 10, 2021 at 23:20

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