12

BIP 62 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?

Improve this question

2 Answers 2

Reset to default
11

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 soft fork is successful and version-3 blocks become mandatory, this rule will be enforced on all confirmed transactions.

  1. 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.

  1. Push operations in scriptSig of non-standard size type

These were made non-standard in 0.9.0, where they're called "non-canonically-encoded serialization sizes".

  1. Zero-padded number pushes

This will be non-standard in 0.10.0.

  1. 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 @PieterWuille's comment below for pointing out my error.

  1. Superfluous scriptSig operations

Non-standard since 0.6.0. In master, this test has moved here.

  1. Inputs ignored by scripts

This is partly addressed in 0.10.0, but see the note below.

  1. Sighash flags based masking

  2. New signatures by the sender

Per BIP62, "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.)

Improve this answer
5
  • 2
    Excellent answer, thanks! I especially appreciate the references.
    – Rich Apodaca
    Feb 5, 2015 at 17:02
  • 3
    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
    Feb 5, 2015 at 19:49
  • @PieterWuille oh, bugger, I forgot about that. I'll update the answer. Thanks!
    – David A. Harding
    Feb 5, 2015 at 20:00
  • @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
    Feb 5, 2015 at 23:59
  • 1
    @RichApodaca I believe the current plan, as discussed on the mailing list and seen in this pull request/commit is to enforce the BIP62 rules on v2 transactions.
    – David A. Harding
    Feb 6, 2015 at 0:08
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

Improve this answer
2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.