BA-06 · LESSON 07

Script limits and malleability

KEY DEFINITIONS

Terms used in this lesson

Signature malleability: The possibility that related signature representations can authorize the same message unless a scheme and its rules enforce a canonical form.
Transaction ID: The identifier produced by hashing a Bitcoin transaction’s non-witness serialization.
SegWit: Segregated Witness: a Bitcoin upgrade that separates authorization data from the transaction identifier and introduces versioned witness programs.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
OP_SUCCESS126: The current OP_SUCCESS-family name for Tapscript byte 0x7e, which succeeds immediately when executed.
Tapscript: The version of Bitcoin Script used by a Taproot script-path spend.
BIP347: The Bitcoin Improvement Proposal specifying proposed CAT byte-concatenation semantics for Tapscript.
CAT: A proposed restoration of a Bitcoin Script operation that concatenates two byte strings.
RBF: Replace-by-fee: a policy for replacing an unconfirmed transaction with a conflicting one that pays more.

Disabled opcodes, resource limits, encoding rules, and malleability protections constrain safe composition.

55 min Difficulty 2/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · script stackWitness data is evaluated by a deterministic stack machineSelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered validation pipeline

01
WITNESSStack items
The spender supplies signatures, preimages, selectors, or other required items.
02
PROGRAMLocking script
The prior output determines the program and rule version to execute.
03
EXECUTEScript limits and malleability
This lesson follows the stack effects and failure boundary for Script limits and malleability.
04
FIRST FAILUREOpcode and state
Invalid encoding, underflow, failed verification, or disabled behavior stops execution.
05
FINAL STACKTrue or false
Consensus accepts the input only when the applicable Script rules succeed.

Rule shown: A spend succeeds only if every opcode is valid and the final stack satisfies the spending condition.

STAGE 1 OF 5WITNESS: Stack items

The spender supplies signatures, preimages, selectors, or other required items.

Governing relationship: A spend succeeds only if every opcode is valid and the final stack satisfies the spending condition. Complete path: 1. WITNESS, Stack items. The spender supplies signatures, preimages, selectors, or other required items. 2. PROGRAM, Locking script. The prior output determines the program and rule version to execute. 3. EXECUTE, Script limits and malleability. This lesson follows the stack effects and failure boundary for Script limits and malleability. 4. FIRST FAILURE, Opcode and state. Invalid encoding, underflow, failed verification, or disabled behavior stops execution. 5. FINAL STACK, True or false. Consensus accepts the input only when the applicable Script rules succeed.

1. State transitionWhat exists, what changes, and what results

BEFORE

Transaction A uses a consensus-disabled opcode. Transaction B is consensus-valid but has an output below a node's current dust policy.

MECHANISM

Applicable Script versions restrict script size, element size, opcode behavior, and other execution properties. Some opcodes are disabled or version-dependent.

AFTER

A debugger must name the exact layer and rule instead of calling every rejection invalid.

Text equivalent: Starting from Transaction A uses a consensus-disabled opcode. Transaction B is consensus-valid but has an output below a node's current dust policy. The mechanism begins when Applicable Script versions restrict script size, element size, opcode behavior, and other execution properties. Some opcodes are disabled or version-dependent. The resulting lesson is A debugger must name the exact layer and rule instead of calling every rejection invalid.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 5

Constrain program structure

Applicable Script versions restrict script size, element size, opcode behavior, and other execution properties. Some opcodes are disabled or version-dependent.

Complete path: 1. Constrain program structure: Applicable Script versions restrict script size, element size, opcode behavior, and other execution properties. Some opcodes are disabled or version-dependent. 2. Constrain transaction and block cost: Weight limits total block validation data. Signature-operation accounting and script rules limit expensive checks. 3. Require encodings: Minimal pushes, number formats, signature encodings, and clean-stack conditions apply under particular consensus or policy contexts. 4. Separate policy rejection: A node may refuse to relay dust, unusual scripts, or excessive chains even when a miner could include them in a valid block. 5. Analyze identifiers and dependencies: Legacy scriptSig changes can alter txid. SegWit moves witness authorization outside txid, enabling safer unconfirmed dependency construction, while RBF and signer changes remain separate issues.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Exact legacy, SegWit-v0, and Tapscript contexts separately apply consensus resource, opcode, encoding, clean-stack, and local standardness rules.

CHANGED CONDITION

Legacy disabled OP_CAT is consensus-invalid, current Tapscript byte 0x7e is OP_SUCCESS126, and proposed BIP347 CAT semantics must never be applied as deployed rules.

Important distinction: SegWit made every unconfirmed Bitcoin transaction non-malleable and final. It prevents third parties from changing segregated witness data in txid. Inputs, outputs, replacement policy, signer choices, and chain reorganizations remain relevant.

Text equivalent: The accepted path is enforced by Exact legacy, SegWit-v0, and Tapscript contexts separately apply consensus resource, opcode, encoding, clean-stack, and local standardness rules. If the required condition changes, Legacy disabled OP_CAT is consensus-invalid, current Tapscript byte 0x7e is OP_SUCCESS126, and proposed BIP347 CAT semantics must never be applied as deployed rules.

Loading lesson visuals...

Learn the idea

Bitcoin limits Script and transaction resources to keep validation predictable and resist denial of service. OP_SUCCESS126 is the current immediate-success meaning of Tapscript byte 0x7e. BIP347 is the undeployed proposal that would assign CAT byte-concatenation semantics to that byte. Consensus limits make a block invalid when exceeded. Standardness policy can be stricter for mempool relay. Malleability means changing transaction bytes without invalidating the intended spend; SegWit removed third-party mutation of witness data from txid but not every form of transaction replacement or signer-controlled variation.

GUIDED EXPLANATION1/5 ideas inspected

Constrain program structure

Applicable Script versions restrict script size, element size, opcode behavior, and other execution properties. Some opcodes are disabled or version-dependent.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“SegWit made every unconfirmed Bitcoin transaction non-malleable and final.”

It prevents third parties from changing segregated witness data in txid. Inputs, outputs, replacement policy, signer choices, and chain reorganizations remain relevant.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.