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