But since "sends" on both forks look identical, and old clients are still talking to new clients, the two forks essentially cross-contaminate each other (beneficially) with each other's unconfirmed transactions, which results in every unconfirmed transaction that would be considered valid by both clients making it into both forks independently.
What if I don't publish the transaction in which I spend an old coin, but wait until I can mine a block containing the transaction for myself. I'm an evil mining pool operator in this example, say, so that won't take too long. I make sure there are some multi-sig transactions in the block too.
I publish the block, spending the coin on the new chain, but the old chain rejects the block, since it contains multi-sig transactions. Then I can spend the same coin again on the old chain.
Your beneficial cross-contamination idea only works if everyone's playing fair...
I think this is a realistic enough attack that it makes BIP 22 unworkable.
I agree with your assessment. You might win the award for the first serious argument against BIP 22 (at least from the set of those that I understand the ramifications of).
A mitigating factor is that this could be protected against by creating an optional patch to the new
client that ensures that, upon receiving a block, the individual transactions are relayed to old
clients (as determined by version number). This patch would not need to be a part of the production code base, nor would it need to be run by everybody - as just a few individuals running it would be sufficient for such transactions from the new branch to get relayed to the old branch. It would also not need to be permanent, being completely discardable and forgettable once consensus was that people actively expecting to receive bitcoins from the public via old clients was sufficiently small. The relay patch is admittedly far less elegant than the simple piece of code I proposed for BIP 22 (the simplicity being a hallmark feature), the flipside being that its ugliness is temporary and not a permanent part of the protocol that must be implemented forever.
Other mitigating factors include the fact that any transaction on the old chain is unlikely to ever see six confirmations until long after receiving them.
Gavin's call still, of course. I will be just as tickled to see BIP 16 move into place, ultimately I just want to see multisig happen but don't care how it gets done, and BIP 16 is more than good enough for me.