My guess would be never at all. Testnet is where new code is tested out before it is released.
It has happened on the main network. The following transaction is present in both block 91812 and 91842: http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction.
I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.
From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction.
I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.
No, those are in the past; it is too late for them. This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.
The absolute worst case for a binary tree search over 256 bits is 256 comparisons. BDB uses something better, probably a btree (I'm too lazy to look it up). After 90 million coinbases, the typical search will probably take less than 30 comparisons. Both of these numbers are trivial and won't add more than a couple of microseconds to block processing time (not counting I/O if the index isn't in memory for some bizarre reason).
