Hi Matt,
Thanks for raising this. Since the compiler only produces SegWit addresses, I hadn't worried at all about malleability, but as you pointed out out-of-band, malleability in the length of an argument can allow an attacker to deflate the feerate of a transaction.
There was in fact a minor witness malleability problem with how the compiler was handling clause selection. It's now been fixed in version 0.0.7 of the compiler.
As far as I can tell (and I haven't looked all that carefully), any sensible Ivy contract won't have any witness malleability problem. (A funny exception is the RevealCollision contract, since you can length-extend the arguments to get another collision. But without a signature check, that one has a more serious transaction malleability problem anyway.) But the compiler currently doesn't prevent you from doing dumb unconstrained stuff like:
```
clause spend(a: Bytes, b: Bytes, sig: Signature) {
verify a == b
verify checkSig(publicKey, sig)
unlock val
}
```
Maybe it should, particularly since there's no reason to include a trivial condition like that anyway. But I think it would probably be about as easy (and more generally useful) to build a static analyzer that solved this problem for low-level Bitcoin Script.