I suppose it could be looking for some form of "gavin_pubkey somebody_else_pubkey CHECKMULTISIG ... with the attacker using somebody_else_pubkey to force the collision, but, again, trivial contract protocol tweaks ("send along a proof you have the private key corresponding to the public key" or "everybody pre-commits pubkeys they'll use at protocol start") would protect against that.

Adding an extra 12 bytes to every segwit to prevent an attack that takes 2^80 computation and 2^80 storage, is unlikely to be a problem in practice, and is trivial to protect against is the wrong tradeoff to make."

20 bytes instead of 32 bytes is a savings of almost 40%, which is significant.

The general question I'd like to raise on this list is:

Should we be worried, today, about collision attacks against RIPEMD160 (our 160-bit hash)?

Mounting a successful brute-force collision attack would require at least O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin POW has computed more SHA256 hashes than that). But it also requires O(2^80) storage, which is utterly infeasible (there is something on the order of 2^35 bytes of storage in the entire world).  Even assuming doubling every single year (faster than Moore's Law), we're four decades away from an attacker with THE ENTIRE WORLD's storage capacity being able to mount a collision attack.