Two non-consecutive blocks with the same coinbase tx. How is this possible?

[Vlad.Sas]

Found this tweet here: https://twitter.com/const_quary/status/1689001050865340417

And i checked mempool.space for the specified blocks: https://mempool.space/block/00000000000271a2dc26e7667f8419f2e15416dc6955e5a6c6cdf3f2574dd08e and https://mempool.space/block/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721

How can two blocks have the same coinbase tx and be so far spread out? Can anyone explain what happened here? Is this the result of some early bitcoin experiments?

[1714493365]

1714493365

[1714493365]

1714493365

[1714493365]

1714493365

[1714493365]

1714493365

[hosseinimr93]

This was possible before implementation of BIP34, but it's no longer possible.

Before implementation of BIP34, two coinbase transactions could be completely same as each other and could have the same transaction hash.
With implementing BIP34, the scriptsig of any coinbase transaction must contain the block height. As a result, it's no longer possible that two coinbase transactions are identical.

It may worth mentioning that coinbase transactions of blocks number 91722 and 91880 are not only transactions that have the same ID. Coinbase transactions in blocks number 91812 and 91842 are also identical.

[Vlad.Sas]

Ah i see. Thank you both. I found the answer. It was because block height wasn't yet required to be placed in the coinbase tx. Wild west of old bitcoin network haha.

[DaveF]

Would not call it the wild west, most like a project in it's early development.
Lots of things within the protocol have matured over time and things that would work / could happen back then no longer can.

So long as things keep changing we will keep seeing things like this. In 15 years there will probably be a post about something that happened in block 802360 with someone trying to figure out how that happened, not knowing that it was changed in a BIP that was implemented in 2030

-Dave

[o_e_l_e_o]

Before implementation of BIP34, two coinbase transactions could be completely same as each other and could have the same transaction hash.

Minor addition: Prior to the implementation of BIP34, we already had BIP30. BIP30 already prevented two coinbase transactions from having identical transaction hashes unless the first one had been fully spent, which would have prevented the issue here of 100 BTC being destroyed.