Also, it's important to take note of the motivation behind not banning duplicate tx hashes outright. Doing so would require that spent tx hashes are retained forever. A pruning node will have no way of knowing whether a new tx duplicates the hash of a preceding tx. Any implementation that does retain such hashes and dismisses new txs on that basis would fork against pruning nodes. e On 11/16/2016 04:43 PM, Eric Voskuil wrote: >> This means that all future transactions will have different txids... > rules do guarantee it. > > No, it means that the chance is small, there is a difference. > > If there is an address collision, someone may lose some money. If there > is a tx hash collision, and implementations handle this differently, it > will produce a chain split. As such this is not something that a node > can just dismiss. If they do they are implementing a hard fork. > > e > > On 11/16/2016 04:31 PM, Tier Nolan via bitcoin-dev wrote: >> >> >> On Thu, Nov 17, 2016 at 12:10 AM, Eric Voskuil via bitcoin-dev >> > > wrote: >> >> Both of these cases resulted from exact duplicate txs, which BIP34 now >> precludes. However nothing precludes different txs from having the same >> hash. >> >> >> The only way to have two transactions have the same txid is if their >> parents are identical, since the txids of the parents are included in a >> transaction. >> >> Coinbases have no parents, so it used to be possible for two of them to >> be identical. >> >> Duplicate outputs weren't possible in the database, so the later >> coinbase transaction effectively overwrote the earlier one. >> >> The happened for two coinbases. That is what the exceptions are for. >> >> Neither of the those coinbases were spent before the overwrite >> happened. I don't even think those coinbases were spent at all. >> >> This means that every activate coinbase transaction has a unique hash >> and all new coinbases will be unique. >> >> This means that all future transactions will have different txids. >> >> There might not be an explicit rule that says that txids have to be >> unique, but barring a break of the hash function, they rules do >> guarantee it. >