<p>It doesn't guarantee that block hashes are unique, because that was already guaranteed, because the previous block hash is part of the block header.</p>

<p>It does guarantee that coinbase transactions will be unique.</p>

CC BY-SA 3.0
2014-10-02T05:38:55.983Z
Can you please explain how previous block hash guarantees block hash uniqueness?
max taldykin
CC BY-SA 3.0
2014-10-02T05:42:49.287Z
Why do you think that it is not very important that there were duplicate coinbase transactions? It looks like that the sole reason of adding height is to prevent duplicate coinbase transactions.
max taldykin
CC BY-SA 3.0
2014-10-02T07:00:27.420Z
BIP-30 prevents duplicate coinbase transactions. Adding block height allows the programs be less complicated while parsing arriving blocks
amaclin
CC BY-SA 3.0
2014-10-02T07:22:27.540Z
@amaclin Thanks for pointing to [BIP-30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki). I think this is the real answer to the "Why?" part of the question (please consider adding this to your answer).
max taldykin
CC BY-SA 3.0
2014-10-02T23:32:48.660Z
It is important for coinbase transactions to be unique because duplicates can't be referred to because they have the same transaction I'd as the first. Therefore they be spent and the 25 bitcoins (currently) are lost.
Jannes
CC BY-SA 3.0
2014-10-20T02:41:23.527Z
@Jannes Sure. But that doesn't really matter. It's happened, what, once or twice in the history of Bitcoin?
Nick ODell
CC BY-SA 3.0
2014-10-20T06:33:29.860Z
It does matter. Read the accepted answer. And the reason it hasn't happens more often is because it's now impossible. Which means that it was apparently 'important' enough to fix.
Jannes
CC BY-SA 3.0
2014-10-20T17:01:09.073Z
@Jannes That's a good point. You've convinced me, and I've removed the part of my post that was wrong.
Nick ODell
CC BY-SA 3.0
2014-10-01T23:46:57.360Z
2014-10-20T16:59:17.710Z
2014-10-20T16:59:17.710Z
Nick ODell
<p>adding height guarantees unique block hashes with the probability 1 - 1/(2<sup>256</sup>) which is very close to 1</p>

<p>different coinbase scripts produce different merkle root which produce different block hashes</p>

CC BY-SA 3.0
2014-10-02T05:29:38.163Z
I don't see why this is true. We have 2^542 possible blocks (542 = 640 bits block size - 32 bits for version - 64 zeros in prev block hash) and 2^192 valid block hashes (192 = 256 - 64 zeroes). So there are 2^350 possible duplicates. How you got 1 - 1/(2^256) from this?
max taldykin
CC BY-SA 3.0
2014-10-02T05:32:54.573Z
The same is for merkle roots: different coinbase does not guarantee different merkle roots. It guarantees that you can't intentionally create blocks with equal merkle roots.
max taldykin
CC BY-SA 3.0
2014-10-02T06:56:08.297Z
There are 2^256 hashes. So the collision probability between previous and next block is 1/2^256
amaclin
CC BY-SA 3.0
2014-10-02T07:04:43.710Z
Why do you consider only previous block? And how adding height increases uniqueness probability?
max taldykin
CC BY-SA 3.0
2014-10-02T07:08:06.220Z
it does not increase/decrease probability of collision. do not read between lines
amaclin
CC BY-SA 3.0
2014-10-02T07:11:06.917Z
*"adding height guarantees unique block hashes with the probability 1 - 1/(2^256)"*. What will be that probability without height added?
max taldykin
CC BY-SA 3.0
2014-10-02T07:42:04.000Z
without height added the probability will be... hmmm... give me a pencil and a paper... are you also Russian? why do we speak in English?... OK! My calculation is done! The probability will be 1 - 1/(2^256). "guarantees" does not mean "increases to" in this context
amaclin
CC BY-SA 3.0
2014-10-02T07:53:13.217Z
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/17570/discussion-between-max-taldykin-and-amaclin).
max taldykin
CC BY-SA 3.0
2014-10-01T21:34:55.320Z
2014-10-01T21:34:55.320Z
amaclin
<p>In their comment @amaclin pointed to <a href="https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki" rel="nofollow noreferrer">BIP-30</a> which provides motivation for <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP-34</a>.</p>
<p>I still don't understand what is &quot;to better reason about plausible difficulty for not-yet-connected blocks&quot; but it seems that the sole point of BIP-34 is to prevent <em>intentional</em> creation of duplicate coinbase transactions.</p>
<p>According BIP-30 they can be used in several attacks:</p>
<blockquote>
<p>Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.</p>
</blockquote>
<p>This <a href="https://bitcoin.stackexchange.com/a/5905/5935">answer</a> by Pieter Wuille explains blockchain forking in more detail.</p>
<hr />
<p>Contrary to the explanation in <a href="https://github.com/bitcoin/bitcoin/pull/1526" rel="nofollow noreferrer">BIP-34 pull request</a>, adding block height to coinbase does not guarantee that every subsequent transaction hash is unique. It only makes harder to create transactions with same hash intentionally. There is still possibility that some unrelated transactions will clash.</p>

CC BY-SA 4.0
2014-10-02T16:08:47.267Z
2022-02-17T05:45:26.570Z
2022-02-17T05:45:26.570Z
max taldykin
<p>While reading bitcoin source I found this short comment:</p>

<pre><code>// Height first in coinbase required for block.version=2
</code></pre>

<p>(From <a href="https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L338" rel="noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L338</a>).</p>

<p>Why this is required? Does it prevent some misuse or attack?</p>

<p>I found that this change was introduced in <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="noreferrer">BIP-0034</a>. In relevant <a href="https://github.com/bitcoin/bitcoin/pull/1526" rel="noreferrer">pull request</a> it is justified by following points:</p>

<blockquote>
  <p>Putting the height in the coinbase is desired for at least two reasons:</p>
  
  <ol>
  <li>It guarantees that every subsequent block and transaction hash is unique.</li>
  <li>It can be used to better reason about plausible difficulty for not-yet-connected blocks.</li>
  </ol>
</blockquote>

<p>But for me this explains nothing: I don't see how adding height <em>guarantees</em> unique block hashes and I don't understand what is "plausible difficulty for not-yet-connected blocks".</p>

<protocol>
Why block height is required in coinbase?
max taldykin
# Why block height is required in coinbase?

(Asked by: username_0 on 2014-10-01)

While reading bitcoin source I found this short comment:

```
// Height first in coinbase required for block.version=2

```

(From <https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L338>).

Why this is required? Does it prevent some misuse or attack?

I found that this change was introduced in [BIP-0034](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki). In relevant [pull request](https://github.com/bitcoin/bitcoin/pull/1526) it is justified by following points:

> Putting the height in the coinbase is desired for at least two reasons:
>
> 1. It guarantees that every subsequent block and transaction hash is unique.
> 2. It can be used to better reason about plausible difficulty for not-yet-connected blocks.

But for me this explains nothing: I don't see how adding height *guarantees* unique block hashes and I don't understand what is "plausible difficulty for not-yet-connected blocks".

**Tags:** protocol


---

## 3 answers

### Answer by username_0 on 2014-10-02. Score: 6 | Accepted answer

In their comment @username_2 pointed to [BIP-30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki) which provides motivation for [BIP-34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki).

I still don't understand what is "to better reason about plausible difficulty for not-yet-connected blocks" but it seems that the sole point of BIP-34 is to prevent *intentional* creation of duplicate coinbase transactions.

According BIP-30 they can be used in several attacks:

> Recently, an attack that exploits the reference implementation's dealing with duplicate transactions was described and demonstrated. It allows reverting fully-confirmed transactions to a single confirmation, making them vulnerable to become unspendable entirely. Another attack is possible that allows forking the block chain for a subset of the network.

This [answer](https://bitcoin.stackexchange.com/a/5905/5935) by Pieter Wuille explains blockchain forking in more detail.

---

Contrary to the explanation in [BIP-34 pull request](https://github.com/bitcoin/bitcoin/pull/1526), adding block height to coinbase does not guarantee that every subsequent transaction hash is unique. It only makes harder to create transactions with same hash intentionally. There is still possibility that some unrelated transactions will clash.


---

### Answer by username_1 on 2014-10-01. Score: 3

It doesn't guarantee that block hashes are unique, because that was already guaranteed, because the previous block hash is part of the block header.

It does guarantee that coinbase transactions will be unique.

> **Comments:**
> **username_0**: Can you please explain how previous block hash guarantees block hash uniqueness?  
> **username_0**: Why do you think that it is not very important that there were duplicate coinbase transactions? It looks like that the sole reason of adding height is to prevent duplicate coinbase transactions.  
> **username_2**: BIP-30 prevents duplicate coinbase transactions. Adding block height allows the programs be less complicated while parsing arriving blocks  
> **username_0**: @username_2 Thanks for pointing to [BIP-30](https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki). I think this is the real answer to the "Why?" part of the question (please consider adding this to your answer).  
> **username_3**: It is important for coinbase transactions to be unique because duplicates can't be referred to because they have the same transaction I'd as the first. Therefore they be spent and the 25 bitcoins (currently) are lost.  
> **username_1**: @username_3 Sure. But that doesn't really matter. It's happened, what, once or twice in the history of Bitcoin?  
> **username_3**: It does matter. Read the accepted answer. And the reason it hasn't happens more often is because it's now impossible. Which means that it was apparently 'important' enough to fix.  
> **username_1**: @username_3 That's a good point. You've convinced me, and I've removed the part of my post that was wrong.  

---

### Answer by username_2 on 2014-10-01. Score: 0

adding height guarantees unique block hashes with the probability 1 - 1/(2256) which is very close to 1

different coinbase scripts produce different merkle root which produce different block hashes

> **Comments:**
> **username_0**: I don't see why this is true. We have 2^542 possible blocks (542 = 640 bits block size - 32 bits for version - 64 zeros in prev block hash) and 2^192 valid block hashes (192 = 256 - 64 zeroes). So there are 2^350 possible duplicates. How you got 1 - 1/(2^256) from this?  
> **username_0**: The same is for merkle roots: different coinbase does not guarantee different merkle roots. It guarantees that you can't intentionally create blocks with equal merkle roots.  
> **username_2**: There are 2^256 hashes. So the collision probability between previous and next block is 1/2^256  
> **username_0**: Why do you consider only previous block? And how adding height increases uniqueness probability?  
> **username_2**: it does not increase/decrease probability of collision. do not read between lines  
> **username_0**: *"adding height guarantees unique block hashes with the probability 1 - 1/(2^256)"*. What will be that probability without height added?  
> **username_2**: without height added the probability will be... hmmm... give me a pencil and a paper... are you also Russian? why do we speak in English?... OK! My calculation is done! The probability will be 1 - 1/(2^256). "guarantees" does not mean "increases to" in this context  
> **username_0**: Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/17570/discussion-between-max-username_0-and-username_2).  

---

