BIP 62 transaction malleability explained as a closed proposal covering DER signatures, low-S values, minimal pushes and later deployed rules.
This guide explains BIP 62 Dealing with malleability in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
BIP 62 Dealing with malleability: Bundling many rules and activation through proposed version-three blocks became unwieldy, and not every malleability source could be removed generally.
A node operator is checking BIP 62 Dealing with malleability. Equivalent signatures, non-minimal pushes or extra stack data could alter those bytes while preserving a valid spend.
A transaction identifier historically committed to the serialised transaction including unlocking scripts. Equivalent signatures, non-minimal pushes or extra stack data could alter those bytes while preserving a valid spend. Systems that created unconfirmed child transactions or tracked payment solely by the original TXID could then fail.
BIP 62 listed strict DER signatures, push-only scriptSig, minimal data pushes, minimal numeric encodings, low-S signatures, clean stack and rules against ignored inputs. The first group could be constrained by consensus for standard script patterns, while a signer or unusual output script could still deliberately permit alternative encodings.
ECDSA signatures admit multiple encodings and a mathematically equivalent S value. Canonical DER limits the byte structure; low-S selects one half of the valid S range. These reduce third-party mutation but require exact validation. Current production evidence should cite the BIP and code path that actually deployed each rule.
The same data or number can be pushed with different opcodes or byte forms. Minimal-push and minimal-number rules choose one representation, while clean-stack rules restrict unused results. A policy rule may reject non-canonical forms from relay before consensus makes a narrower subset invalid in blocks.
Bundling many rules and activation through proposed version-three blocks became unwieldy, and not every malleability source could be removed generally. Individual changes proceeded through focused proposals and deployments. A closed umbrella BIP is therefore a map of problems, not an activation status for every numbered rule.
Segregated Witness removes witness data from the legacy TXID calculation and defines WTXID for the complete serialisation. This fixes important third-party malleability for SegWit spends but does not make every transaction field immutable or protect deliberately malleable scripts. Applications must identify which identifier and confirmation state they use.
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
BIP 62 Dealing with malleability: Bundling many rules and activation through proposed version-three blocks became unwieldy, and not every malleability source could be removed generally.
A transaction identifier historically committed to the serialised transaction including unlocking scripts.
BIP 62 listed strict DER signatures, push-only scriptSig, minimal data pushes, minimal numeric encodings, low-S signatures, clean stack and rules against ignored inputs.
ECDSA signatures admit multiple encodings and a mathematically equivalent S value. Canonical DER limits the byte structure.
BIP 62 organised Bitcoin’s malleability problem but did not activate as one package. Safe applications rely on the deployed canonical-signature and SegWit rules, confirmed transaction state and tests that distinguish relay policy from consensus.
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
BIP 441 guide to the Draft tapleaf 0xC2 script-restoration proposal, varops, stack limits, unsigned arithmetic, restored opcodes and safety testing.
BIP 440 guide to the Draft transaction-wide variable-operation budget, weight scaling, opcode cost classes, benchmarks, validation and soft-fork status.
BIP 361 guide to the Draft informational post-quantum migration and legacy-signature sunset proposal, phases, prerequisites, risks and readiness planning.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.