<p>The <code>nLockTime</code> value can't be set to the height of the block it's included in. This is because the locktime check (<code>IsFinalTx()</code>) is performed for all transactions in a block, including the coinbase transaction. And the <code>nLockTime</code> value represents the last block at which a transaction is invalid, not the first block at which it is valid.</p>
<p>Of course this can be dealt with, for instance by using <code>height - 1</code> as the <code>nLockTime</code> value or by requiring that the <code>nSequence</code> field of the coinbase transaction's input be set to the maximum value. However this added complexity might have played a role in the decision to not use this method at the time.</p>

CC BY-SA 4.0
2024-11-08T18:49:19.793Z
Interesting, I don't think I considered this when writing my answer here.
Pieter Wuille
CC BY-SA 4.0
2024-11-08T16:19:05.007Z
2024-11-08T16:19:05.007Z
Antoine Poinsot
<p>That would have made perfect sense, and I see no reason why that wouldn't have been the superior way of doing it.</p>

<p>However, as far as I remember, nobody suggested this at the time.</p>

CC BY-SA 4.0
2018-06-06T14:10:41.760Z
2018-06-06T14:10:41.760Z
Pieter Wuille
<p>At some point in 2011/12 miners started using custom mining algorithms ignoring the best practise to mine to a different new public key (hash) for each subsequent block. This lead to a lack of uniqueness of the coinbase transaction id and <a href="https://bitcoin.stackexchange.com/a/38998/32356">destroyed some bitcoins forever</a>.</p>

<p>So it became mandatory with BIP34/v2 blocks to put the height of a block in a special encoded format into the coinbase transaction's input "script".</p>

<p>But why not use existing datastructures like the coinbase transaction's very own locktime field?</p>

<consensus><implementation><bip-34>
Why was BIP34 (Block v2, Height in Coinbase) not implemented via the coinbase tx's locktime or nSequence?
Felix Weis
# Why was BIP34 (Block v2, Height in Coinbase) not implemented via the coinbase tx's locktime or nSequence?

(Asked by: username_0 on 2018-06-06)

At some point in 2011/12 miners started using custom mining algorithms ignoring the best practise to mine to a different new public key (hash) for each subsequent block. This lead to a lack of uniqueness of the coinbase transaction id and [destroyed some bitcoins forever](https://bitcoin.stackexchange.com/a/38998/32356).

So it became mandatory with BIP34/v2 blocks to put the height of a block in a special encoded format into the coinbase transaction's input "script".

But why not use existing datastructures like the coinbase transaction's very own locktime field?

**Tags:** consensus, implementation, bip-34


---

## 2 answers

### Answer by username_2 on 2018-06-06. Score: 9 | Accepted answer

That would have made perfect sense, and I see no reason why that wouldn't have been the superior way of doing it.

However, as far as I remember, nobody suggested this at the time.


---

### Answer by username_1 on 2024-11-08. Score: 3

The `nLockTime` value can't be set to the height of the block it's included in. This is because the locktime check (`IsFinalTx()`) is performed for all transactions in a block, including the coinbase transaction. And the `nLockTime` value represents the last block at which a transaction is invalid, not the first block at which it is valid.

Of course this can be dealt with, for instance by using `height - 1` as the `nLockTime` value or by requiring that the `nSequence` field of the coinbase transaction's input be set to the maximum value. However this added complexity might have played a role in the decision to not use this method at the time.

> **Comments:**
> **username_2**: Interesting, I don't think I considered this when writing my answer here.  

---

