Did Segwit (BIP141) eliminate all txid malleability issues listed in BIP62?

Question

• There are 9 malleability issues listed in the BIP62, but doesn't seem like BIP141 addressed all of them. If not, why not and why is it not an issue for Lightning or other DoS vectors?
• What is exactly meant by the word "Nonintentional" in motivation point #1 of BIP141? Does it imply there can still be "intentional" ways to malleate txid?
• What was the exact difference in PR6769 and Segwit in regards to preventing txid malleability because of ECDSA signatures? Miners could still collude and mine a different txid after this PR, which was fully eliminated by Segwit?

Answer 1

Most of the malleability issues listed in BIP62 stem from the fact that an input script (scriptSig) can be modified and still remain valid for the input, and because the input script is included when calculating the TXID, this modifies the TXID as well.

Example ways you can turn an input script into a different but still valid input script:

• Any valid ECDSA signature can be turned into a different valid signature by inverting the s-value. BIP62 proposed that an s-value in the lower half of the range be required.
• Any push operation can be expressed multiple ways. For example, pushing the byte 01 can be done with the opcode 0x51 (OP_1/OP_TRUE), but also less efficiently using the sequence 0101 (OP_PUSHBYTES_1 01). BIP62 proposed that the most efficient ("canonical") way be required.
• Since the input script is a script, it can be modified any number of ways, for example by including <data> OP_DROP anywhere in the script. BIP62 proposed to restrict input scripts to data pushing opcodes.

SegWit cleverly fixed all of these malleability vectors by simply requiring the input script to be empty (or, in the case of wrapped SegWit, to push a single specific byte vector), and moving signatures and other script inputs to the witness which isn't covered by the TXID. Witness data can still be malleated by third parties, but it doesn't affect TXID malleability anymore.

"Nonintentional malleability" just refers to malleability by a third party that the original creator of the transaction didn't intend. It will of course always be possible for the creator to intentionally malleate the transaction themselves before it is included in a block, and even with SegWit you can still create transactions intentionally malleable by third parties by e.g. not requiring any signatures to spend an output.

The pull request you mention changed standardness rules, not consensus rules, so it's easily bypassed by miners. Because SegWit took a different approach to fixing malleability, high s-value signatures are still just non-standard but valid by consensus.