search

bitpay / insight-api

The bitcoin blockchain API powering Insight
https://github.com/bitpay/insight
591 stars 1.04k forks source link

handle historic transactions with duplicate IDs. #42

Open maraoz opened 10 years ago

maraoz commented 10 years ago

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 commented 10 years ago

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 commented 8 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 5 years ago

Is this problem solved now？