OP_PAIRCOMMIT

What Is OP_PAIRCOMMIT?

OP_PAIRCOMMIT is a proposed Bitcoin opcode defined in BIP-442 that creates a cryptographic commitment to two stack elements. When executed, it pops the top two elements from the Bitcoin Script stack, hashes them together using a tagged SHA-256 construction, and pushes the resulting 32-byte hash onto the stack. The opcode is assigned number 0xcd (decimal 205), replacing OP_SUCCESS205 in tapscript.

The proposal was authored by moonsettler and Brandon Black and introduced in late 2024 as part of the broader LNHANCE effort to bring targeted scripting improvements to Bitcoin. BIP-442 was merged into the official Bitcoin BIPs repository in March 2026 and remains in Draft status with no activation timeline scheduled.

Unlike OP_CAT, which concatenates two elements into a single byte string that can be further manipulated, OP_PAIRCOMMIT outputs a hash. This is a deliberate design choice: the original data cannot be recovered from the output, preventing recursive constructions and limiting the opcode's power to commitment schemes rather than general-purpose data manipulation.

How It Works

OP_PAIRCOMMIT operates on the top two elements of the script stack. If fewer than two elements are available, script execution fails immediately. The operation proceeds in three steps:

1. Pop the top element (x2) and the second element (x1) from the stack
2. Serialize both elements with compact_size length prefixes and compute their tagged SHA-256 hash
3. Push the resulting 32-byte hash onto the stack

Tagged Hashing

The hash follows the tagged hashing convention from BIP-340 (Schnorr signatures). Tagged hashing prepends a domain-specific tag to prevent hash collisions across different protocols. The tag used is "PairCommit":

hash_PairCommit(x) = SHA256(
  SHA256("PairCommit") || SHA256("PairCommit") || x
)

The data x fed into the tagged hash is the concatenation of both elements, each prefixed with its length in Bitcoin's compact_size encoding:

x = compact_size(len(x1)) || x1 || compact_size(len(x2)) || x2

Length-prefixing is critical for security. Without it, an attacker could redistribute bytes between x1 and x2 while producing the same hash: a "byte shifting attack." For example, the pairs ("AB", "CD") and ("ABC", "D") would produce the same raw concatenation "ABCD". The length prefixes make each pair produce a unique serialization.

Performance

Because the "PairCommit" tag midstate can be pre-computed, validation requires only one to two SHA-256 compression cycles. For common LN-Symmetry use cases (a 7-byte balance value combined with a 32-byte CTV hash, totaling 55 bytes of input), the data fits within a single SHA-256 block, making execution very efficient.

Script Example

Committing to a tree of elements using nested OP_PAIRCOMMIT calls:

# Given three elements a, b, c on the stack:
# Stack: [a, b, c]

OP_PAIRCOMMIT        # Hash b and c together
                     # Stack: [a, PC(b, c)]

OP_PAIRCOMMIT        # Hash a and PC(b, c)
                     # Stack: [PC(a, PC(b, c))]

# The result is a Merkle-like commitment to all three elements

This nested pattern enables Merkle-like commitment trees without requiring OP_CAT or any other concatenation opcode.

The LNHANCE Bundle

OP_PAIRCOMMIT is one of four opcodes in the LNHANCE soft fork proposal. Each opcode addresses a specific scripting limitation, and together they enable a broad range of new constructions:

CTV and CSFS repurpose two OP_NOP codes and are available in all script types. OP_INTERNALKEY and OP_PAIRCOMMIT repurpose OP_SUCCESS codes and are restricted to tapscript (taproot script path spends with leaf version 0xc0).

Why Not Just Use OP_CAT?

OP_CAT concatenates two stack elements into a single byte string, which can then be further manipulated. This general-purpose capability enables a wide range of constructions: recursive covenants, novel transaction introspection, and even Turing-complete computation when combined with other opcodes.

That generality is precisely what makes OP_CAT contentious. A significant portion of the Bitcoin developer community is concerned that enabling recursive covenants could have unforeseen consequences for Bitcoin's fungibility and censorship resistance. OP_PAIRCOMMIT sidesteps this debate by producing a hash rather than a concatenation: the output cannot be decomposed or further processed as raw data.

As discussed in the OP_CAT covenant debate, the trade-off is clear. OP_CAT is more powerful but politically difficult. OP_PAIRCOMMIT is deliberately limited but solves the specific vector commitment problem needed for LN-Symmetry, vaults, and other targeted use cases without opening the broader design space that concerns critics. Notably, no one in the Bitcoin development community has raised objections to OP_PAIRCOMMIT's specific use cases.

Use Cases

LN-Symmetry Channel Updates

LN-Symmetry (formerly known as eltoo) is a proposed Lightning channel update mechanism where any later state can replace any earlier state, eliminating the need for penalty transactions. OP_PAIRCOMMIT plays a critical role in this design by enabling parties to commit to the combination of channel balance data and settlement transaction hashes (CTV hashes).

During a contested channel close, the on-chain script must verify that a published state is valid. With OP_PAIRCOMMIT, the script can check that a balance value and a CTV hash together match a previously committed pair, without requiring the full state to be stored on-chain. This solves the "data availability" problem for contested closes while keeping script sizes compact.

Vault Constructions

Vaults are Bitcoin spending policies that enforce a time-delayed withdrawal process, giving owners a window to cancel unauthorized transactions. OP_PAIRCOMMIT enables lighter vault implementations by allowing scripts to verify commitments to pairs of spending conditions without the overhead of full concatenation and hashing in script.

Combined with CTV for transaction template enforcement and CSFS for arbitrary message signing verification, OP_PAIRCOMMIT enables modular covenant designs where each opcode handles a specific part of the verification logic.

Covenant Emulation

While OP_PAIRCOMMIT cannot enable recursive covenants on its own, it can emulate bounded covenant patterns when combined with the other LNHANCE opcodes. Scripts can commit to specific spending paths using nested pair commitments, creating Merkle-like structures that encode complex spending policies. For a broader overview of covenant proposals, see the Bitcoin covenants explainer.

Additional Applications

• Ark and joinpool designs that reduce interactivity requirements for larger payment pools
• Non-interactive Lightning channels that can be created while one party is offline
• Reduced-signature Discreet Log Contracts with more efficient construction
• Complex delegation schemes combining CSFS with multi-element state validation

Risks and Considerations

Narrow Scope Trade-off

OP_PAIRCOMMIT is intentionally limited in scope. Critics argue that adding specialized opcodes delays or reduces momentum for broader proposals like OP_CAT, which could eventually subsume its functionality. If OP_CAT were activated, OP_PAIRCOMMIT would become redundant for most use cases. The covenant activation path forward explores this tension in detail.

Power Boundary Uncertainty

Some Bitcoin developers have noted that the exact boundary between what OP_PAIRCOMMIT enables and what OP_CAT enables has not been fully analyzed. There is ongoing discussion about whether OP_PAIRCOMMIT could, in combination with other opcodes, simulate some of OP_CAT's more controversial capabilities. No concrete examples have been demonstrated, but the theoretical question remains open.

Tapscript Only

OP_PAIRCOMMIT is available only in tapscript (taproot script path spends with leaf version 0xc0). It cannot be used in legacy scripts, SegWit v0 scripts, or taproot key path spends. This limits its applicability to transactions that use taproot's script path, though this is the expected execution environment for advanced Bitcoin Script constructions going forward.

Activation Uncertainty

As of mid-2026, BIP-442 remains in Draft status with no activation mechanism specified. The LNHANCE bundle has not reached community consensus, and the broader soft fork activation landscape remains complex. For background on how Bitcoin consensus changes are adopted, see the soft fork activation history.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.