handle historic transactions with duplicate IDs.

[maraoz]

Two transactions in the blockchain have the same txid: e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468

One is here: http://blockexplorer.com/block/00000000000743f190a18c5577a3c2d2a1f610ae9601ac046a38084ccb7cd721

The other is here:
http://blockexplorer.com/block/00000000000271a2dc26e7667f8419f2e15416dc6955e5a6c6cdf3f2574dd08e

We should discuss how to handle this the best way possible on insight.

[rubensayshi]

https://github.com/bitcoin/bips/blob/master/bip-0030.mediawiki

the TX you mentioned; https://blockchain.info/tx/e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468
there's another; https://blockchain.info/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

[braydonf]

I've noticed this as well. Uniqueness has been enforced with https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki so it should not be an issue moving forward, and likely not worth handling as a special case. Current behavior is that e3bf3d07d4b0375638d5f1db5255fe07ba2c4cb067cd81b84ee974b6585fb468 is included in block #91880 as per bitcoind indexes.

[evoskuil]

This is an incorrect interpretation of BIP34 (see BIP30). Duplicate transaction hashes are perfectly valid in Bitcoin. BIP34 simply makes it less likely and very hard to produce a duplicate intentionally.

[dabura667]

how are duplicate txids handled in bitcoin core?

Many RPC calls rely on txids as the args... could someone try calling something using a duplicate txid?

[evoskuil]

Bitcoin JSON-RPC calls have no connection to consensus, and the JSON-RPC interface is only exposed locally - for a number of reasons pertaining to its insufficiency for use on the Internet. I believe they are handled in Core by exploiting the condition in BIP30 that allows a tx to exist with a duplicate hash only in the case where the preceding duplicate is fully-spent. In this case it can simply overwrite the preceding transaction. In this case the JSON-RPC interface would simply provide the latest instance. As for other services, who knows - I assume they will simply fail on the same basis.

However, same hash does not mean same tx (though this is the case of the 2 existing duplicates, masking the true nature of the problem). So in the case of a future duplication there are problems with this strategy. If there is a reorg back to a point prior to the replacement, the preceding tx has been lost and there will be problems. Also, once a replacement occurs there is no ability to recreate the preceding blocks with the replaced transactions.

The former problem can be mitigated by rebuilding the chain and attempting to avoid one of the forks. The latter problem does not impact validation, just the p2p network's ability to rebuild the chain. Ugly in either case, especially since the latter adversely impacts the former. I'm not certain about their implementation, but I'd speculate that once this happens there will be repercussions.

[EdisonChenZX]

Is this problem solved now？