What is the difference between mauling and transaction malleability?

Question

http://stevengoldfeder.com/papers/ZKCSP.pdf notes:

The protocol presented in [5] is vulnerable to the so-called mauling problem, where an adversary which knows the hash identifier T of a transaction is able to come up with a hash identifier T 0 that is semantically equivalent to T (i.e. spends the same transaction, has the same value, and the same inputs and outputs). As the authors of [5] point out, there are many Bitcoin software clients that cannot handle transactions appearing in the ledger with an hash identifier which is different from the original one (namely, the one with which they were posted) [3]. This effectively makes the transaction unredeemable, causing problems when creating Bitcoin contracts [2,3]. While the authors acknowledge the mauling problem, their scheme only addresses mauling due to malleability in ECDSA signatures, but does not address mauling due to changing the script.

The reference [5] cited is Efficient Zero-Knowledge Contingent Payments in Cryptocurrencies Without Scripts

This sounds a lot like transaction malleability. What is the difference?

If it is not the same, is mauling fixed by Segregated Witness?

Answer 1

They define what they mean by mauling in the referenced paper:

As described in Section 2, the Bitcoin transactions are identified by their hashes, more precisely: TXid(T) = H(T) (where H is the SHA256 hash function). This can sometimes be a problem, since it turns out that often the adversary that knows T can compute T' that is semantically equivalent to T (i.e.: spends the same transaction, has the same value, and the same inputs and outputs), but is syntactically different from T. This is called mauling the transaction T. In a moment we will explain how mauling can be done, but let us first say what are the consequences of this attack. The problem comes from the fact that in such a case TXid(T) != TXid(T'). Note that this does not imply that the adversary can steal money (as the output of T is the same as the output of T'). Still, it is undesirable in many situations.

This is the same thing as transaction malleability.

Would segregated witness solve this? I believe so. If every input is a segwit spend, that solves every kind of transaction malleability, except when the attacker has a copy of every private key that signed the transaction.