<p>Transaction malleability is a consequence of the features of Bitcoin. The input data (scriptSig) for claiming outputs is purposely malleable to allow for useful scenarios where one would want to claim outputs in different ways.</p>

<p>The consequence of these features is that the hash of the transaction changes and shouldn't be considered as a useful piece of information other than referencing outputs of transactions that have been confirmed.</p>

<p>With that being said, I'm not sure what changes the client could implement to prevent the hash from changing. Perhaps it can enforce specific rules, like <a href="https://github.com/bitcoin/bitcoin/pull/3025" rel="nofollow">making non-canonical data pushes non standard</a>, however that may interfere with later extensions to Bitcoin.</p>

CC BY-SA 3.0
2015-04-04T00:58:21.877Z
If the scriptSig is purposefully malleable, can't it just be excluded when calculating the txid?
Minthos
CC BY-SA 3.0
2014-03-02T15:37:34.250Z
2014-03-02T16:01:06.097Z
2014-03-02T16:01:06.097Z
Luca Matteis
<p>With the upcoming release of Bitcoin Core 0.9, I am wondering how the transaction malleability issue is being fixed and what are the consequences of the fix?</p>

<p>It appears that transaction malleability is causing a few problems for the Bitcoin network:</p>

<ul>
<li>The network is DDoSed by multiple apparent double-spends being relayed</li>
<li>Senders of the transactions need to avoid spending 0 confirmation transactions in case they become invalidated by malleability</li>
<li>When saving TxIDs of spent transaction for record keeping one has to make sure the TxID did not get changed later</li>
</ul>

<p>Will all of those issues be addressed in the upcoming update, and if so, how will they be addressed?</p>

CC BY-SA 3.0
2014-03-02T14:19:29.870Z
The second and third items are outside the scope of the basic Bitcoin client and wallet software; they'd be issues for an exchange's custom software to address.
Nate Eldredge
CC BY-SA 3.0
2014-03-02T20:21:08.123Z
The release notes for Bitcoin Core 0.90 (the reference client) lay out several fixes for transaction malleability: https://bitcointalk.org/index.php?topic=495683.0
ChrisW
<transactions><bitcoin-core><transaction-malleability><protocol>
How is the transaction malleability issue being fixed?
ThePiachu
# How is the transaction malleability issue being fixed?

(Asked by: username_0 on 2014-03-02)

With the upcoming release of Bitcoin Core 0.9, I am wondering how the transaction malleability issue is being fixed and what are the consequences of the fix?

It appears that transaction malleability is causing a few problems for the Bitcoin network:

* The network is DDoSed by multiple apparent double-spends being relayed
* Senders of the transactions need to avoid spending 0 confirmation transactions in case they become invalidated by malleability
* When saving TxIDs of spent transaction for record keeping one has to make sure the TxID did not get changed later

Will all of those issues be addressed in the upcoming update, and if so, how will they be addressed?

**Tags:** transactions, bitcoin-core, transaction-malleability, protocol

> **Comments:**
> **username_1**: The second and third items are outside the scope of the basic Bitcoin client and wallet software; they'd be issues for an exchange's custom software to address.  
> **username_2**: The release notes for Bitcoin Core 0.90 (the reference client) lay out several fixes for transaction malleability: https://bitcointalk.org/index.php?topic=495683.0  

---

## 1 answers

### Answer by username_3 on 2014-03-02. Score: 3

Transaction malleability is a consequence of the features of Bitcoin. The input data (scriptSig) for claiming outputs is purposely malleable to allow for useful scenarios where one would want to claim outputs in different ways.

The consequence of these features is that the hash of the transaction changes and shouldn't be considered as a useful piece of information other than referencing outputs of transactions that have been confirmed.

With that being said, I'm not sure what changes the client could implement to prevent the hash from changing. Perhaps it can enforce specific rules, like [making non-canonical data pushes non standard](https://github.com/bitcoin/bitcoin/pull/3025), however that may interfere with later extensions to Bitcoin.

> **Comments:**
> **username_4**: If the scriptSig is purposefully malleable, can't it just be excluded when calculating the txid?  

---

