handle historic transactions with duplicate IDs. about insight-api

[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.

[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?

[EdisonChenZX]

Is this problem solved now？