Proving collisions on Bitcoin addresses without discovery of the private key? If there is a private key that leads to a collision on an address, it is possible to show that the private key is not the one used previously, even though they have a collision on the address?

Specifically, if there was a collision on one of the Satoshi-owned early blocks, could it be challenged, to show that the person who got it didn't have the initial private key? Specifically, if they signed the same script that was used originally, wouldn't it generate a different signature, while the original owner would be able to reproduce the original signature?

Thanks,
David
To phrase the question in my own words: Can you prove that a transaction output was unlocked with a different private key than originally intended?

Short answer: You can or can't, depending on the situation.



A standard transaction output script works like this:


Assume that the stack starts with two items, with the public key on top and the signature below.
Duplicate the public key (topmost item).
Compute its hash.
Push the expected hash, which is the payee's address (20-byte SHA-256 + RIPEMD-160 hash).
Compare and assert that the top two items are equal.
Restore the stack to the initial state, and use the two items to check the signature.


A standard transaction input script works like this:


Push the signature.
Push the public key (this is now at the top of the stack).




Because of this underlying mechanism, here are the implications:


If an output to a specific address has never been spent before, then the public key has never been seen by the Bitcoin network. Thus the first time that a valid public key shows up (whose SHA-256 + RIPEMD-160 hash matches), it is indistinguishably as valid as any other public key that has the same hash (which is extremely unlikely to find one, of course).
If an output to a specific address has been spent before, then the network has recorded one or more public keys that were used to spend that address. The Bitcoin/blockchain protocol does not mandate that the public key must be the same; in other words there is no notion of "key pinning". Although it is plausible for an individual miner's Bitcoin client to enforce key pinning, I don't expect this to be a feature that becomes implemented.