<p>According to statuses of proposed BIPs implementation into Bitcoin Core #62 is in status Draft. This means that none of the seven proposed "fixes" have been implemented, yet.</p>

<p>Source: <a href="https://github.com/bitcoin/bips" rel="nofollow">https://github.com/bitcoin/bips</a></p>

CC BY-SA 3.0
2015-02-04T23:50:52.383Z
Thanks for the info. Do the new rules apply only to confirmation, or relay/mempool as well? For example, new rule #2 (non-push operations in scriptSig) appears to part of the IsStandardTx check in v0.10.0 RC3: https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L678
Rich Apodaca
CC BY-SA 3.0
2015-07-14T19:44:53.400Z
That doesn't mean a lot. [BIP42](https://github.com/bitcoin/bips/blob/8defdc87d18a8f36d426ed40145441d271f18ae4/bip-0042.mediawiki) is still in draft stage too.
Nick ODell
CC BY-SA 3.0
2015-02-04T23:28:26.000Z
2015-02-04T23:28:26.000Z
Marek
<p>Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules.  Here are some details: </p>

<blockquote>
  <ol>
  <li>Non-DER encoded ECDSA signatures</li>
  </ol>
</blockquote>

<p>These are currently non-standard, so Bitcoin Core nodes (since 0.8.0, IIRC) by default won't relay or mine them.  When the <a href="https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki">BIP66</a> soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.</p>

<blockquote>
  <ol start="2">
  <li>Non-push operations in scriptSig</li>
  </ol>
</blockquote>

<p>These are also currently non-standard, and are completely forbidden for signature scripts spending a P2SH output.  I don't know when they were first made non-standard, but I suspect it was 0.8 or before.</p>

<blockquote>
  <ol start="3">
  <li>Push operations in scriptSig of non-standard size type</li>
  </ol>
</blockquote>

<p>These were made non-standard in <a href="https://bitcoin.org/en/release/v0.9.0">0.9.0</a>, where they're called "non-canonically-encoded serialization sizes".</p>

<blockquote>
  <ol start="4">
  <li>Zero-padded number pushes</li>
  </ol>
</blockquote>

<p>This will be <a href="https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L50">non-standard in 0.10.0</a>.</p>

<blockquote>
  <ol start="5">
  <li>Inherent ECDSA signature malleability</li>
  </ol>
</blockquote>

<p>This is currently allowed, and several popular Bitcoin programs still do create full-range signatures.  Getting those programs to update to using only low-S values before BIP62 is implemented would be nice, but it <strong>isn't</strong> critical because the new BIP62 validation rules will only apply to version 2 transactions.  Programs that don't update will still be allowed to create version 1 transactions even after the soft fork.</p>

<p>The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.</p>

<p><em>Edit:</em> an earlier version of this section incorrectly said getting programs to create only low-S signatures was critical.  Thanks to @PieterWuille's comment below for pointing out my error.</p>

<blockquote>
  <ol start="6">
  <li>Superfluous scriptSig operations</li>
  </ol>
</blockquote>

<p><a href="https://github.com/bitcoin/bitcoin/commit/39f0d9686095bce469dbfa52333331a5d15c6545">Non-standard since 0.6.0</a>.  In master, this test has <a href="https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L53">moved here</a>.</p>

<blockquote>
  <ol start="7">
  <li>Inputs ignored by scripts</li>
  </ol>
</blockquote>

<p>This is partly <a href="https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L51">addressed in 0.10.0</a>, but see the note below.</p>

<blockquote>
  <ol start="8">
  <li><p>Sighash flags based masking</p></li>
  <li><p>New signatures by the sender</p></li>
  </ol>
</blockquote>

<p>Per <a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki">BIP62</a>, "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable."</p>

<p>In short, rule 7 doesn't have a complete solution and rules 8 and 9 don't have any solution.  (Indeed, the malleability from 8 is a feature, and fixing 9 would require a different signature scheme.)</p>

CC BY-SA 3.0
2015-02-05T17:02:50.690Z
Excellent answer, thanks! I especially appreciate the references.
Rich Apodaca
CC BY-SA 3.0
2015-02-05T19:49:08.620Z
One comment about 5: it's not actually required to have other wallet software use the low-S range before BIP62 can be deployed, as this rule is only planned to be enforced for transactions with an increased version number (making it completely opt-in, even after the 95% threshold for BIP62 is reached).
Pieter Wuille
CC BY-SA 3.0
2015-02-05T20:00:02.877Z
@PieterWuille oh, bugger, I forgot about that.  I'll update the answer.  Thanks!
David A. Harding
CC BY-SA 3.0
2015-02-05T23:59:45.693Z
@DavidA.Harding, did you mean v3? I thought v2 was being skipped as a transaction version to avoid confusion with the upcoming v3 blocks.
Rich Apodaca
CC BY-SA 3.0
2015-02-06T00:08:22.410Z
@RichApodaca I believe the current plan, as [discussed on the mailing list](http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06456.html) and seen in [this pull request](https://github.com/bitcoin/bips/pull/117)/[commit](https://github.com/sipa/bips/commit/3b9d5df9f10a0e31cafe56df51ae461c50f380b5) is to enforce the BIP62 rules on v2 transactions.
David A. Harding
CC BY-SA 3.0
2015-02-05T03:13:40.470Z
2015-02-05T20:08:49.590Z
2015-02-05T20:08:49.590Z
David A. Harding
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki">BIP 62</a> lists nine source of malleability:</p>

<ol>
<li><p>Non-DER encoded ECDSA signatures</p></li>
<li><p>Non-push operations in scriptSig</p></li>
<li><p>Push operations in scriptSig of non-standard size type</p></li>
<li><p>Zero-padded number pushes</p></li>
<li><p>Inherent ECDSA signature malleability</p></li>
<li><p>Superfluous scriptSig operations</p></li>
<li><p>Inputs ignored by scripts</p></li>
<li><p>Sighash flags based masking</p></li>
<li><p>New signatures by the sender</p></li>
</ol>

<p>...and proposes new rules that would fix the first seven. How many of these fixes have been implemented in Bitcoin Core?</p>

<transaction-malleability><bitcoin-core-development>
How much of BIP 62 ("Dealing with malleability") has been implemented?
Rich Apodaca
# How much of BIP 62 ("Dealing with malleability") has been implemented?

(Asked by: username_0 on 2015-02-04)

[BIP 62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki) lists nine source of malleability:

1. Non-DER encoded ECDSA signatures
2. Non-push operations in scriptSig
3. Push operations in scriptSig of non-standard size type
4. Zero-padded number pushes
5. Inherent ECDSA signature malleability
6. Superfluous scriptSig operations
7. Inputs ignored by scripts
8. Sighash flags based masking
9. New signatures by the sender

...and proposes new rules that would fix the first seven. How many of these fixes have been implemented in Bitcoin Core?

**Tags:** transaction-malleability, bitcoin-core-development


---

## 2 answers

### Answer by username_3 on 2015-02-05. Score: 11 | Accepted answer

Most of the fixes have been implemented in Bitcoin Core's master branch, or earlier versions, as standard transaction checks that prevent default Bitcoin Core nodes from relaying or mining transactions that break the rules. Here are some details:

> 1. Non-DER encoded ECDSA signatures

These are currently non-standard, so Bitcoin Core nodes (since 0.8.0, IIRC) by default won't relay or mine them. When the [BIP66](https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki) soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.

> 2. Non-push operations in scriptSig

These are also currently non-standard, and are completely forbidden for signature scripts spending a P2SH output. I don't know when they were first made non-standard, but I suspect it was 0.8 or before.

> 3. Push operations in scriptSig of non-standard size type

These were made non-standard in [0.9.0](https://bitcoin.org/en/release/v0.9.0), where they're called "non-canonically-encoded serialization sizes".

> 4. Zero-padded number pushes

This will be [non-standard in 0.10.0](https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L50).

> 5. Inherent ECDSA signature malleability

This is currently allowed, and several popular Bitcoin programs still do create full-range signatures. Getting those programs to update to using only low-S values before BIP62 is implemented would be nice, but it **isn't** critical because the new BIP62 validation rules will only apply to version 2 transactions. Programs that don't update will still be allowed to create version 1 transactions even after the soft fork.

The advantage for programs using v2 transactions is that they can generally be constructed to be non-malleable by third parties, so v2 transactions can more safely be used for applications like the initial bond part of establishing a micropayment channel.

*Edit:* an earlier version of this section incorrectly said getting programs to create only low-S signatures was critical. Thanks to @username_4's comment below for pointing out my error.

> 6. Superfluous scriptSig operations

[Non-standard since 0.6.0](https://github.com/bitcoin/bitcoin/commit/39f0d9686095bce469dbfa52333331a5d15c6545). In master, this test has [moved here](https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L53).

> 7. Inputs ignored by scripts

This is partly [addressed in 0.10.0](https://github.com/bitcoin/bitcoin/blob/fcf646c9b08e7f846d6c99314f937ace50809d7a/src/script/standard.h#L51), but see the note below.

> 8. Sighash flags based masking
> 9. New signatures by the sender

Per [BIP62](https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki), "The first six and part of the seventh can be fixed by extra consensus rules, but the last two can't. Not being able to fix #7 means that even with these new consensus rules, it will always be possible to create outputs whose spending transactions will all be malleable."

In short, rule 7 doesn't have a complete solution and rules 8 and 9 don't have any solution. (Indeed, the malleability from 8 is a feature, and fixing 9 would require a different signature scheme.)

> **Comments:**
> **username_0**: Excellent answer, thanks! I especially appreciate the references.  
> **username_4**: One comment about 5: it's not actually required to have other wallet software use the low-S range before BIP62 can be deployed, as this rule is only planned to be enforced for transactions with an increased version number (making it completely opt-in, even after the 95% threshold for BIP62 is reached).  
> **username_3**: @username_4 oh, bugger, I forgot about that.  I'll update the answer.  Thanks!  
> **username_0**: @username_3, did you mean v3? I thought v2 was being skipped as a transaction version to avoid confusion with the upcoming v3 blocks.  
> **username_3**: @username_0 I believe the current plan, as [discussed on the mailing list](http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06456.html) and seen in [this pull request](https://github.com/bitcoin/bips/pull/117)/[commit](https://github.com/sipa/bips/commit/3b9d5df9f10a0e31cafe56df51ae461c50f380b5) is to enforce the BIP62 rules on v2 transactions.  

---

### Answer by username_1 on 2015-02-04. Score: 1

According to statuses of proposed BIPs implementation into Bitcoin Core #62 is in status Draft. This means that none of the seven proposed "fixes" have been implemented, yet.

Source: <https://github.com/bitcoin/bips>

> **Comments:**
> **username_0**: Thanks for the info. Do the new rules apply only to confirmation, or relay/mempool as well? For example, new rule #2 (non-push operations in scriptSig) appears to part of the IsStandardTx check in v0.10.0 RC3: https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/main.cpp#L678  
> **username_2**: That doesn't mean a lot. [BIP42](https://github.com/bitcoin/bips/blob/8defdc87d18a8f36d426ed40145441d271f18ae4/bip-0042.mediawiki) is still in draft stage too.  

---

