LNHANCE

What Is LNHANCE?

LNHANCE is a proposed Bitcoin soft fork that packages three new opcodes into a single activation bundle. Created by Bitcoin protocol developers Brandon Black (reardencode) and 4moonsettler, the proposal aims to give Bitcoin Script the minimum set of new capabilities needed to dramatically improve Lightning Network channel management, vault constructions, and multi-party protocols.

The name reflects the proposal's core motivation: enhancing the Lightning Network. While each opcode has standalone value, their combination unlocks protocol designs that none of them can achieve individually. LNHANCE repurposes existing no-operation (NOP) opcodes in legacy script types and SUCCESS opcodes in Tapscript, following the same backward-compatible upgrade path that previous soft forks have used.

How It Works

LNHANCE introduces three opcodes that each address a different gap in Bitcoin Script's current capabilities. Understanding each opcode individually is essential before seeing how they combine into more powerful constructions.

OP_CHECKTEMPLATEVERIFY (BIP 119)

OP_CHECKTEMPLATEVERIFY (CTV) allows a UTXO to commit to the exact transaction that will spend it. The opcode computes a SHA-256 hash of specific transaction fields: version, locktime, input count, sequences hash, output count, outputs hash, and the index of the spending input. If the hash matches the template on the stack, the spend is valid.

This creates what developers call a transaction template: a predetermined spending path that cannot be altered after the UTXO is created. CTV enables congestion control (batching many payments into a single on-chain transaction that later expands), simple vaults, and non-interactive channel opens.

# Simplified CTV spending script
# The UTXO can only be spent into a transaction
# matching this exact template hash
<template_hash> OP_CHECKTEMPLATEVERIFY

OP_CHECKSIGFROMSTACKVERIFY (BIP 348)

OP_CHECKSIGFROMSTACKVERIFY (CSFS) verifies a Schnorr signature against an arbitrary message provided on the stack, rather than against transaction data. It pops three elements: a 32-byte public key, a message, and a signature, then validates using BIP 340 Schnorr verification.

Standard Bitcoin signature opcodes like OP_CHECKSIG can only verify signatures over the spending transaction itself. CSFS removes this limitation, enabling scripts that verify signatures over any data. This is the building block for oracle-based contracts, delegated spending authority, and state updates in off-chain protocols.

# CSFS verifies a signature over an arbitrary message
# rather than the spending transaction
<signature> <message> <pubkey> OP_CHECKSIGFROMSTACKVERIFY

OP_INTERNALKEY (BIP 349)

OP_INTERNALKEY pushes the 32-byte x-only representation of the Taproot internal key onto the stack. In a standard P2TR output, the internal key is embedded in the output's public key but is not directly accessible from within a script. OP_INTERNALKEY makes it available.

This saves approximately 8 virtual bytes per script that needs access to the internal key, since without it, the key must be duplicated in the script itself. More importantly, it enables collaborative spending constructions where the MuSig2 aggregate key used as the internal key can also participate in script-path conditions.

How the Opcodes Combine

The real power of LNHANCE emerges when these opcodes work together. CTV alone can commit to a transaction template, but it cannot be updated after creation. Adding CSFS allows a signature to authorize a new template, creating updateable commitments. OP_INTERNALKEY lets the Taproot key-path signers also participate in these script conditions without duplicating key data.

This combination enables what is known as LN-Symmetry (formerly eltoo): a channel state is committed via CTV, a CSFS-verified signature authorizes state transitions, and OP_INTERNALKEY allows the channel participants' aggregate key to be referenced efficiently. The result is a channel construction where all states are equally valid and the latest state always wins, eliminating the need for penalty transactions.

Use Cases

LN-Symmetry Channels

Current Lightning channels use a penalty mechanism: if a counterparty broadcasts an old state, the other party can claim all funds as punishment. This works but requires storing every prior state and introduces complex justice transaction logic. LN-Symmetry replaces this with a simpler model where any party can publish any state, and newer states can always override older ones through a brief challenge period.

LNHANCE enables LN-Symmetry by combining CTV (to template each state transaction), CSFS (to authorize state updates with signatures over state data), and OP_INTERNALKEY (to reference the channel key-path). This reduces storage requirements and simplifies Lightning channel implementations. For a deeper exploration of how this changes Lightning protocol design, see the research on PTLCs and the next evolution of Lightning.

Non-Interactive Channel Opens

Today, opening a Lightning channel requires both parties to be online and actively coordinate. With CTV, a sender can construct a transaction that opens a channel to a recipient without the recipient being online. The transaction template commits to the channel's funding output structure, so the recipient can begin using the channel whenever they come online.

This is particularly valuable for channel factories and timeout trees, where a single on-chain transaction can open dozens or hundreds of channels simultaneously. Combined with CSFS, these constructions can support state updates, making them far more practical than CTV-only designs.

Efficient Vaults

Vaults are a covenant pattern where funds require a time-delayed withdrawal process: the owner initiates a withdrawal, waits through a challenge period, and then completes it. If the withdrawal is unauthorized, the owner (or a watchtower) can claw back the funds to a recovery address during the waiting period.

LNHANCE enables vault constructions using CTV to template the withdrawal transaction and CSFS to authorize clawback signatures. While the dedicated OP_VAULT proposal (BIP 345) provides a more specialized vault opcode, LNHANCE-based vaults offer a general-purpose alternative using composable primitives. For a detailed comparison of vault designs, see the research on Bitcoin script vaults.

Discreet Log Contracts

Discreet log contracts (DLCs) enable trustless bets on real-world outcomes using oracle signatures. Current DLC implementations require generating a separate adaptor signature for every possible outcome, which becomes expensive for contracts with many outcomes (such as price feeds with thousands of possible values).

With CSFS, DLCs can verify oracle signatures directly in script rather than relying on pre-computed adaptor signatures for each outcome. This reduces the setup cost from O(n) signatures to a constant-size script, making DLCs with large outcome spaces practical. For background on DLC mechanics, see the research on discreet log contracts on Bitcoin.

Congestion Control

During periods of high on-chain demand, CTV enables a single transaction to commit to a tree of future transactions. A payment processor or exchange can batch hundreds of withdrawals into one on-chain transaction that expands into individual payments over time as block space becomes available. Recipients receive a cryptographic guarantee of eventual settlement without needing immediate block inclusion.

LNHANCE vs. Other Proposals

LNHANCE exists within a broader landscape of Bitcoin covenant proposals. Understanding how it compares to alternatives helps clarify its design philosophy. For comprehensive coverage of the covenant debate, see the research on Bitcoin covenants explained and the OP_CAT covenant debate.

Standalone CTV

CTV on its own (BIP 119) enables transaction templates, vaults, and congestion control, but it cannot support updateable state. Without CSFS, there is no way to authorize new templates after the initial commitment is created. This means CTV alone cannot enable LN-Symmetry or interactive covenant constructions. LNHANCE adds CSFS and OP_INTERNALKEY to fill this gap, turning static templates into dynamic, updateable protocols. For a deep dive into CTV's standalone capabilities, see the research on OP_CTV and Check Template Verify.

OP_CAT

OP_CAT takes a broader approach by enabling arbitrary data concatenation on the stack. This single opcode, combined with existing opcodes, can emulate many covenant patterns including recursive covenants and validity proofs. However, OP_CAT's generality introduces concerns: it enables constructions whose security implications are difficult to analyze, and it could affect Bitcoin's fungibility through complex spending conditions.

LNHANCE proponents argue that their approach is more targeted: each opcode solves a specific, well-understood problem, and the combined capabilities are bounded and predictable. OP_CAT advocates counter that a single general-purpose opcode is simpler to reason about than multiple special-purpose ones. The two proposals are not mutually exclusive, and some developers advocate activating both.

APO (SIGHASH_ANYPREVOUT)

SIGHASH_ANYPREVOUT (BIP 118) is another proposal that enables LN-Symmetry by allowing signatures that do not commit to the specific input being spent. APO achieves rebindable transactions through a new sighash flag rather than new opcodes. LNHANCE achieves similar goals through CTV plus CSFS, offering a different set of tradeoffs: LNHANCE additionally enables vaults and congestion control, while APO has a simpler implementation for the specific case of channel state updates.

Current Status

As of mid-2026, LNHANCE has no scheduled activation date. All three opcodes are available for testing on Bitcoin Inquisition, the dedicated testing framework for proposed consensus changes. The proposal has been implemented as a Bitcoin Core pull request (PR #29198) for review.

Community sentiment is generally positive among developers who prioritize practical Lightning improvements, though debate continues on several fronts: whether the three-opcode bundle represents the right scope, whether alternative formulations like BIP 446 (OP_TEMPLATEHASH) and BIP 448 offer a cleaner design, and what level of tooling and proof-of-concept implementations should exist before activation is considered.

The broader covenant activation discussion remains one of Bitcoin's most active areas of protocol development. Layer 2 protocols like Spark, Ark, and Lightning would all benefit from the capabilities LNHANCE provides, creating strong demand-side pressure for some form of covenant support.

Risks and Considerations

Activation Uncertainty

Bitcoin's consensus change process is deliberately slow and conservative. The last successful soft fork, Taproot, took years from proposal to activation. LNHANCE faces the additional challenge of bundling three separate BIPs, each of which must be individually reviewed and accepted. There is no guarantee that all three will be activated together, or at all.

Bundle Scope Debate

Some developers argue that LNHANCE bundles too many changes, making review more complex. Others argue it bundles too few, and that additional opcodes like OP_CAT should be included. Finding the right scope for a consensus change bundle is inherently political as well as technical: different stakeholders prioritize different use cases.

Interaction with Future Proposals

Activating LNHANCE does not preclude future covenant proposals, but it does influence the design space. If CSFS is activated, future proposals can build on it rather than reimplementing signature verification. This composability is a design goal, but it also means the choice of which opcodes to activate first shapes the long-term evolution of Bitcoin Script.

Implementation Complexity

While each individual opcode is relatively simple, the protocols they enable (LN-Symmetry, vaults, DLCs) are complex systems that require significant engineering effort to build, test, and deploy. Activating the opcodes is only the first step: the practical limitations of Bitcoin Script mean that translating opcode capabilities into production software takes years of additional development.

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.