The transactions I am talking about is: d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

And this is not the only example. The 2nd one being: e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468

I am sure it everyone expects each Bitcoin transaction to be unique since the existential purpose of Bitcoin is to solve the double-spending problem.

Even more, everyone knows that the TX ID, is the (double) hash of the transaction data, and one propriety hash function has is that every time you feed it a different input, it gives you a completely different output.

But at the same time, the same input gives the same output everytime.

So this means that we are either:

In fact what exactly are we hashing?

TX in pic: c1b4e695098210a31fe02abffe9005cffc051bbe86ff33e173155bcbdc5821e3 source: https://learnmeabitcoin.com/explorer/transaction/c1b4e695098210a31fe02abffe9005cffc051bbe86ff33e173155bcbdc5821e3

Well, a transaction is made of inputs, outputs and some other data. Most of the time at least one of these fields is different, so we always end up with a different TX ID.

But the TXs in question are not normal TXs, they are coinbase transactions and coinbase transactions have one very special propriety: they create money out of thin air. This means that when a miner pays himself, there is no input, as the money comes from nowhere. (technically this is not true there is exactly 1 input there, and it's always the same thing but we can treat it as non-existent)

So in the culprit transactions, there is no input(or its the same one always), they both pay to the same output(in this case it pays to a bare pubKey) so when we hash the data we get the exact same TX ID.

You can imagine that this was seen as a problem, and something was done to solve it. The 1st attempt was BIP30, which introduced a new rule. Blocks are not allowed to contain a TX with the same ID as a previously non-spent TX in the current chain, and of course, the BIP had the edge case above exempt from the rule. While this helped it did not solve the problem.

Later(not that much later though) BIP34 introduced a new rule. Each coinbase TX is to include the height of the block. As each height of each block is different, this guarantees that each coinbase TX ID will be unique. The blocks that have such coinbase TXs, are called version2 blocks, and the older ones version1. The last version 1 block was 227,835, and it was mined on 3 March 2024.

Well, that a more difficult question to answer than you can imagine, we can just say now it's kinda working. However before the above patches were added, I would say yes, it was broken, and the reason I am using the word "broken", is because it did not do what we wanted it to.

Now, you prolly are thinking: Ok, but if this has no severe consequences, why is this is problem?

Well it could lead to 2 very problematic things:

The 2nd attack is not as lickly and there are quite a bunch of if, but still, we could not have this being a possibility on the Bitcoin network.