Quote from: DannyHamilton on June 06, 2014, 10:59:50 PM

Quote from: vertak on June 06, 2014, 10:18:38 PM

I know this thread is old, but I came to it first, and then found an example of a transaction hash being in multiple non-forked blocks in the block chain. The blocks that contain the transaction with hash

d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

are 91812 and 91842. As long as the previous transaction outputs have all been spent, this double transaction hash is considered valid. If any of the addresses that received BTC from the transaction in block number 91812 hadn't spent their coins yet, this would be invalid.

This is a known bug in the early days of bitcoin. I don't think it is possible any longer to have 2 coinbase transactions with the same transaction hash.

It wasn't a bug, but the initial design.

BerkeleyDB that was used by the project back then had no problems handling records with non-unique keys.
After Satoshi had left, guys who took over the development replaced BerkeleyDB with LevelDB. And LevelDB only works with unique keys.
Whoever made the decision back then apparently did not care about handling non-unique IDs anymore (in reality only coinbase could have non-unique IDs), so they essentially changed the block chain protocol at that point. Which was a good decision, IMHO, since there were only 2 txs like this while the architectural complication of keeping it backward compatible wouldn't rather be worth these 100 BTC, for which most likely nobody has a key anyway.

It is not a fist time when I read misinformation about this had being an alleged bug.
You guys better get your records straight, because in fact it was not a bug - such was the initial design and the original implementation had no problems whatsoever with handling same TX IDs.
Then in blocks version 2 they started to require a block height value inside the coinbase, which makes it now impossible to replicate a previous TXID, even if the miner had really wanted to.