<p>They define what they mean by mauling in the referenced paper:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>This is the same thing as transaction malleability.</p>

<p>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.</p>

CC BY-SA 3.0
2017-07-13T15:29:12.523Z
2017-07-13T15:29:12.523Z
Nick ODell
<p><a href="http://stevengoldfeder.com/papers/ZKCSP.pdf" rel="nofollow noreferrer">http://stevengoldfeder.com/papers/ZKCSP.pdf</a> notes:</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>The reference [5] cited is <a href="https://eprint.iacr.org/2016/451.pdf" rel="nofollow noreferrer">Efficient Zero-Knowledge Contingent Payments in
Cryptocurrencies Without Scripts</a></p>

<p>This sounds a lot like transaction malleability. What is the difference?</p>

<p>If it is not the same, is mauling fixed by Segregated Witness?</p>

<transactions><segregated-witness>
What is the difference between mauling and transaction malleability?
Janus Troelsen
# What is the difference between mauling and transaction malleability?

(Asked by: username_0 on 2017-07-13)

<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](https://eprint.iacr.org/2016/451.pdf)

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

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

**Tags:** transactions, segregated-witness


---

## 1 answers

### Answer by username_1 on 2017-07-13. Score: 2 | Accepted answer

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.


---

