<p>The requirement of encoding the block height in the coinbase transaction is specified in <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP34</a>. You may want to read the actual documentation there.</p>
<p>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 &gt;&gt; 8) % 256, height &gt;&gt; 16].</p>
<p>It is not done as an additional output (as a data output would imply), and is not possible directly using <code>createrawtransaction</code>, which is aimed towards general-purpose transactions, not coinbases. Coinbases are generally constructed by mining software.</p>

CC BY-SA 4.0
2021-12-10T22:21:28.853Z
I am creating a mining software. So what you're saying is that I have to manually push the block height (little endian) into the scriptsig of the coinbase transaction.?
AncientTides
CC BY-SA 4.0
2021-12-10T22:23:02.857Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-12-10T22:35:35.340Z
Thanks.... I'm guessing it won't be a pain to create a witness ? I wish these functionalities were more portable.
AncientTides
CC BY-SA 4.0
2021-12-10T22:37:43.353Z
`the first 4 bytes of the scriptSig have to be [0x03, height % 256, (height >> 8) % 256, height >> 16].` This threw me off..... Could you elaborate on this better?
AncientTides
CC BY-SA 4.0
2021-12-10T22:42:14.580Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-12-10T22:45:03.197Z
jeez.... I thought it was just - first byte 0x03 then remaining 3 bytes little endian of block height.... Now it makes sense....

So if I follow these steps I won't have any issues ?  THANKSSSSS.......
AncientTides
CC BY-SA 4.0
2021-12-10T22:48:14.847Z
That's the same thing. Yes, it is 0x03 plus the 3-byte little endian encoding of the height.
Pieter Wuille
CC BY-SA 4.0
2021-12-10T22:59:45.747Z
So you're saying that if I **`shift the first 4 bytes of the scriptSig by [0x03, height % 256, (height >> 8) % 256, height >> 16]`** ....... it would be the exact same thing as simply inserting **`0x03`** + **`blockheight data`** (in little endian) ?? Won't the hex of block height be 4 bytes?
AncientTides
CC BY-SA 4.0
2021-12-10T22:59:45.817Z
So you're saying that if I **`shift the first 4 bytes of the scriptSig by [0x03, height % 256, (height >> 8) % 256, height >> 16]`** ....... it would be the exact same thing as simply inserting **`0x03`** + **`blockheight data`** (in little endian) ?? Won't the hex of block height be 4 bytes?
AncientTides
CC BY-SA 4.0
2021-12-10T23:03:29.530Z
You have to use 3-byte little endian encoding of the height, not 4-byte, as prescribed by BIP34.
Pieter Wuille
CC BY-SA 4.0
2021-12-10T23:04:21.310Z
Any idea how to do that?
AncientTides
CC BY-SA 4.0
2021-12-10T23:06:49.667Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-12-10T23:20:42.727Z
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).
Pieter Wuille
CC BY-SA 4.0
2021-12-10T23:39:48.423Z
It's all clear now. Thanks so much
AncientTides
CC BY-SA 4.0
2021-12-10T22:11:30.443Z
2021-12-10T22:16:39.380Z
2021-12-10T22:16:39.380Z
Pieter Wuille
<p>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 <strong><code>getblocktemplate</code></strong> into the coinbase transaction?  - which I create using the <strong><code>createrawtransaction</code></strong> rpc command. But the thing is, <strong>by calling the <strong><code>createrawtransaction</code></strong> and doing</strong></p>
<pre><code>[{&quot;txid&quot;:&quot;0000000000000000000000000000000000000000000000000000000000000000&quot;,&quot;vout&quot;:2147483647}]{&quot; insert address &quot;:6.25000000}
</code></pre>
<p><strong>, I'd get a processed hash which is to be added as <strong>transaction 0</strong> within the list of transactions before building the merklehash.</strong></p>
<p>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.</p>
<p>So it got me thinking, What if the <strong><a href="https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data" rel="nofollow noreferrer">data field</a></strong>  after the address field is where I insert the blocks height?</p>
<p>While reading the Official <strong><a href="https://developer.bitcoin.org/index.html" rel="nofollow noreferrer">Bitcoin Developer RPC API Reference</a></strong>, I came across a parameter within the <strong><code>createrawtransaction</code></strong> rpc command -- <strong><a href="https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data" rel="nofollow noreferrer">The key must be &quot;data&quot;, the value is hex-encoded data</a></strong> and I thought maybe this is where I ought to fill in the height data .... which I would grab from <strong><a href="https://developer.bitcoin.org/reference/rpc/getblocktemplate.html#:%7E:text=%22height%22%20%3A%20n%2C%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20(numeric)%20The%20height%20of%20the%20next%20block" rel="nofollow noreferrer">here</a></strong> and maybe somehow parse it with <strong><a href="https://developer.bitcoin.org/reference/rpc/getblocktemplate.html#:%7E:text=%22coinbaseaux%22%20%3A%20%7B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20(json%20object)%20data%20that%20should%20be%20included%20in%20the%20coinbase%27s%20scriptSig%20content" rel="nofollow noreferrer">this</a></strong> ; after which I then take the hexadecimal hash and insert it within the <strong><a href="https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data" rel="nofollow noreferrer">data field</a></strong>.</p>

CC BY-SA 4.0
2021-12-10T23:16:04.043Z
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.
Pieter Wuille
<json-rpc><bitcoin-cli><createrawtransaction><getblocktemplate><height>
What exactly is the data required when creating a coinbase transaction? How do I insert the blocks height into the coinbase transaction?
AncientTides
# What exactly is the data required when creating a coinbase transaction? How do I insert the blocks height into the coinbase transaction?

(Asked by: username_0 on 2021-12-10)

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](https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data)** after the address field is where I insert the blocks height?

While reading the Official **[Bitcoin Developer RPC API Reference](https://developer.bitcoin.org/index.html)**, I came across a parameter within the **`createrawtransaction`** rpc command -- **[The key must be "data", the value is hex-encoded data](https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data)** and I thought maybe this is where I ought to fill in the height data .... which I would grab from **[here](https://developer.bitcoin.org/reference/rpc/getblocktemplate.html#:%7E:text=%22height%22%20%3A%20n%2C%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20(numeric)%20The%20height%20of%20the%20next%20block)** and maybe somehow parse it with **[this](https://developer.bitcoin.org/reference/rpc/getblocktemplate.html#:%7E:text=%22coinbaseaux%22%20%3A%20%7B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20(json%20object)%20data%20that%20should%20be%20included%20in%20the%20coinbase%27s%20scriptSig%20content)** ; after which I then take the hexadecimal hash and insert it within the **[data field](https://developer.bitcoin.org/reference/rpc/createrawtransaction.html#:%7E:text=%22data%22%3A%20%22hex%22%2C%20%20%20%20%20%20%20%20(string%2C%20required)%20A%20key%2Dvalue%20pair.%20The%20key%20must%20be%20%22data%22%2C%20the%20value%20is%20hex%2Dencoded%20data)**.

**Tags:** json-rpc, bitcoin-cli, createrawtransaction, getblocktemplate, height

> **Comments:**
> **username_1**: 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.  

---

## 1 answers

### Answer by username_1 on 2021-12-10. Score: 2 | Accepted answer

The requirement of encoding the block height in the coinbase transaction is specified in [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki). 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.

> **Comments:**
> **username_0**: I am creating a mining software. So what you're saying is that I have to manually push the block height (little endian) into the scriptsig of the coinbase transaction.?  
> **username_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.  
> **username_0**: Thanks.... I'm guessing it won't be a pain to create a witness ? I wish these functionalities were more portable.  
> **username_0**: `the first 4 bytes of the scriptSig have to be [0x03, height % 256, (height >> 8) % 256, height >> 16].` This threw me off..... Could you elaborate on this better?  
> **username_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.  
> **username_0**: jeez.... I thought it was just - first byte 0x03 then remaining 3 bytes little endian of block height.... Now it makes sense....  So if I follow these steps I won't have any issues ?  THANKSSSSS.......  
> **username_1**: That's the same thing. Yes, it is 0x03 plus the 3-byte little endian encoding of the height.  
> **username_0**: So you're saying that if I **`shift the first 4 bytes of the scriptSig by [0x03, height % 256, (height >> 8) % 256, height >> 16]`** ....... it would be the exact same thing as simply inserting **`0x03`** + **`blockheight data`** (in little endian) ?? Won't the hex of block height be 4 bytes?  
> **username_0**: So you're saying that if I **`shift the first 4 bytes of the scriptSig by [0x03, height % 256, (height >> 8) % 256, height >> 16]`** ....... it would be the exact same thing as simply inserting **`0x03`** + **`blockheight data`** (in little endian) ?? Won't the hex of block height be 4 bytes?  
> **username_1**: You have to use 3-byte little endian encoding of the height, not 4-byte, as prescribed by BIP34.  
> **username_0**: Any idea how to do that?  
> **username_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.  
> **username_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).  
> **username_0**: It's all clear now. Thanks so much  

---

