<p><a href="https://en.bitcoin.it/wiki/Transaction_Malleability" rel="nofollow">Transaction malleability</a> is prevented by selecting one canonical representation of every transaction and making every other representation nonstandard. That is, of all possible transactions one transaction can be mutated into, exactly one is considered "original", and other representations are not relayed.</p>

<p>Originally, Bitcoin could accept different representations of the same data. For example, it were possible to represent the same number both with and without leading zeros, producing equivalent transactions with different binary representations. Now, a transaction would only be considered standard if those numbers are represented using a specific number of digits, so it is now impossible to write the same number in different ways.</p>

<p>However, this rule is not enforced on transactions that are already in a block (since otherwise it would be a fork), so a powerful adversary can still push a mutated transaction into the network by mining it himself.</p>

CC BY-SA 3.0
2014-09-27T10:04:47.033Z
How can all the clients agree on which transaction to be considered original?
Pacerier
CC BY-SA 3.0
2014-09-27T10:14:59.650Z
@Pacerier Originally, the rules for representation of signatures were pretty lax. For example, it were possible to represent numbers both with and without leading zeros. This means that the same number could be represented in several different ways. New rules require all those numbers to be represented using a specific number of digits, so now there is no leeway. Other rules are similarly tightened.
abacabadabacaba
CC BY-SA 3.0
2014-09-27T13:38:13.460Z
Is it merely a reduction in the probability of possible representations, or does the update ensure that only **one** representation is possible?
Pacerier
CC BY-SA 3.0
2014-09-27T15:33:11.507Z
There is only one "canonical" representation for "standard" transactions. Unfortunately, not all current clients create canonical transactions. So, it is not possible to check for some transactions are they malled from canonical representation or created by old clients.
amaclin
CC BY-SA 3.0
2014-09-27T09:48:36.853Z
2014-09-27T10:29:28.240Z
2014-09-27T10:29:28.240Z
abacabadabacaba
<p>Quoth <a href="https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#transaction-malleability-related-fixes" rel="nofollow">Bitcoin release-notes-0.9.0.md</a>:</p>

<blockquote>
  <p>This release contains a few fixes for transaction ID (TXID)
  malleability issues:</p>
  
  <ul>
  <li><p>-nospendzeroconfchange command-line option, to avoid spending zero-confirmation change</p></li>
  <li><p>IsStandard() <strong>transaction rules tightened</strong> to <strong>prevent relaying and mining of mutated transactions</strong></p></li>
  <li><p>Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they
  spend the same outputs.</p></li>
  <li><p>Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.</p></li>
  <li><p>New option: -zapwallettxes to rebuild the wallet's transaction information</p></li>
  </ul>
</blockquote>

<p>What does "transaction rules tightened" mean and how does it prevent relaying and mining of mutated transactions?
Since mutated transactions are also <strong>valid</strong> transactions, how can the client tell <em>original</em> transactions apart from mutated ones?</p>

<p>Are powerful adversaries still able to abuse this feature after the update?</p>

<client><security><transaction-malleability>
How are mutated transactions prevented from getting relayed?
Pacerier
# How are mutated transactions prevented from getting relayed?

(Asked by: username_0 on 2014-05-22)

Quoth [Bitcoin release-notes-0.9.0.md](https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.9.0.md#transaction-malleability-related-fixes):

> This release contains a few fixes for transaction ID (TXID)
> malleability issues:
>
> * -nospendzeroconfchange command-line option, to avoid spending zero-confirmation change
> * IsStandard() **transaction rules tightened** to **prevent relaying and mining of mutated transactions**
> * Additional information in listtransactions/gettransaction output to report wallet transactions that conflict with each other because they
>   spend the same outputs.
> * Bug fixes to the getbalance/listaccounts RPC commands, which would report incorrect balances for double-spent (or mutated) transactions.
> * New option: -zapwallettxes to rebuild the wallet's transaction information

What does "transaction rules tightened" mean and how does it prevent relaying and mining of mutated transactions?
Since mutated transactions are also **valid** transactions, how can the client tell *original* transactions apart from mutated ones?

Are powerful adversaries still able to abuse this feature after the update?

**Tags:** client, security, transaction-malleability


---

## 1 answers

### Answer by username_1 on 2014-09-27. Score: 3 | Accepted answer

[Transaction malleability](https://en.bitcoin.it/wiki/Transaction_Malleability) is prevented by selecting one canonical representation of every transaction and making every other representation nonstandard. That is, of all possible transactions one transaction can be mutated into, exactly one is considered "original", and other representations are not relayed.

Originally, Bitcoin could accept different representations of the same data. For example, it were possible to represent the same number both with and without leading zeros, producing equivalent transactions with different binary representations. Now, a transaction would only be considered standard if those numbers are represented using a specific number of digits, so it is now impossible to write the same number in different ways.

However, this rule is not enforced on transactions that are already in a block (since otherwise it would be a fork), so a powerful adversary can still push a mutated transaction into the network by mining it himself.

> **Comments:**
> **username_0**: How can all the clients agree on which transaction to be considered original?  
> **username_1**: @username_0 Originally, the rules for representation of signatures were pretty lax. For example, it were possible to represent numbers both with and without leading zeros. This means that the same number could be represented in several different ways. New rules require all those numbers to be represented using a specific number of digits, so now there is no leeway. Other rules are similarly tightened.  
> **username_0**: Is it merely a reduction in the probability of possible representations, or does the update ensure that only **one** representation is possible?  
> **username_2**: There is only one "canonical" representation for "standard" transactions. Unfortunately, not all current clients create canonical transactions. So, it is not possible to check for some transactions are they malled from canonical representation or created by old clients.  

---

