LNHANCE: The Soft Fork Bundle Aiming to Supercharge Lightning and Bitcoin Vaults

Bitcoin's consensus rules change slowly. Any soft fork proposal faces years of review, debate, and political negotiation before it reaches activation. LNHANCE takes a pragmatic approach to this reality: instead of pushing a single opcode through the gauntlet, it bundles four complementary opcodes into one proposal, arguing that the combination delivers far more value than any piece alone.

The name says it all: "LN" plus "enhance." The bundle targets improvements to the Lightning Network as its headline use case, but its reach extends to covenants, vaults, payment pools, and protocol designs that do not yet exist. This article breaks down what each opcode does, what they unlock together, and where the proposal stands in Bitcoin's contentious upgrade process.

What Is LNHANCE?

LNHANCE is a soft fork proposal authored primarily by Brandon Black (reardencode) with significant contributions from moonsettler. Black opened the initial combined implementation as Bitcoin Core PR #29198 on January 7, 2024. The proposal bundles four opcodes, each with its own BIP:

The original January 2024 proposal included only the first three. moonsettler introduced OP_PAIRCOMMIT later that year as an optimization for LN-Symmetry constructions, avoiding the script bloat of "key laddering" that would otherwise be needed. All four BIPs remain in Draft status.

What Each Opcode Does

OP_CHECKTEMPLATEVERIFY (BIP 119)

CTV is the most reviewed opcode in the bundle, with over five years of development history. It expects a 32-byte hash on the stack and computes a deterministic hash of the spending transaction's fields: version, locktime, input outpoints, sequence numbers, and output details. If the hashes match, execution continues. If not, the script fails.

This creates non-recursive covenants: an output can specify exactly which transaction may spend it. All spending paths must be known at creation time, which bounds the complexity and makes analysis tractable. On its own, CTV enables congestion control via transaction trees, simplified CoinJoin constructions, non-custodial mining payouts, and a basic form of vault.

OP_CHECKSIGFROMSTACK (BIP 348)

CSFS pops three elements from the stack: a public key, a message, and a signature. It verifies the signature against the message using BIP 340 Schnorr rules. Unlike the standard OP_CHECKSIG, which always verifies against the transaction's sighash, CSFS decouples signature verification from transaction data entirely. Scripts can now verify commitments to arbitrary data.

This is not a new idea. CSFS has been deployed on Blockstream's Liquid sidechain for over eight years without significant issues. On its own, it enables oracle attestation verification (critical for Discreet Log Contracts), key delegation without multisig, "pay for signature" protocols, and on-chain state transfer verification relevant to statechains.

OP_INTERNALKEY (BIP 349)

IKEY is the simplest opcode in the bundle. It pushes the 32-byte x-only representation of the Taproot internal key onto the stack. Without IKEY, scripts that need to reference the internal key must include it explicitly, costing around 8 additional virtual bytes per use.

Beyond the space savings, IKEY enables dynamic re-keying across Taptrees: when the internal key changes, scripts using IKEY automatically reference the new key without manual updates to every leaf script. This matters for constructions like channel factories where the participant set evolves over time.

OP_PAIRCOMMIT (BIP 442)

OP_PAIRCOMMIT pops two elements from the stack, concatenates them with their size commitments, applies a tagged SHA256 hash, and pushes the result. It provides a limited form of vector commitment without requiring OP_CAT.

The inclusion of size commitments prevents "length redistribution attacks" where bytes could be reallocated between the two elements to forge a valid commitment. OP_PAIRCOMMIT was added to the LNHANCE bundle specifically to optimize LN-Symmetry: it enables efficient commitment to both a balance allocation and a CTV hash in a single script without the bloat of alternative approaches.

What the Combination Unlocks

Individually useful, these opcodes become dramatically more powerful together. The key insight is that CTV plus CSFS can emulate SIGHASH_ANYPREVOUT (APO) behavior: signatures become bound to transaction templates rather than specific inputs. A composite script pattern illustrates this:

• CTV commits to the structure of a spending transaction (what it looks like)
• CSFS verifies that an authorized key signed that template hash (who approved it)
• Because the signature authorizes the template rather than a specific input, the same pre-signed update can spend any UTXO locked with this script

This input-agnostic authorization is the foundation of LN-Symmetry and opens the door to several protocol improvements.

LN-Symmetry (Eltoo)

LN-Symmetry, originally proposed as "eltoo" by Christian Decker, Rusty Russell, and Olaoluwa Osuntokun in 2018, redesigns Lightning channel state management so that any later state can replace any earlier state. There are no justice transactions and no penalties.

In today's LN-Penalty design, broadcasting an outdated channel state lets the counterparty seize all funds via a penalty transaction. This means nodes must store every prior state, accidentally restoring from an old backup can cause total fund loss, watchtowers need significant resources, and multi-party channels become impractical. With LN-Symmetry, a party who broadcasts an old state simply loses a transaction fee: the counterparty publishes their newer state, which replaces the older one, and only the most recent state can settle.

Why LN-Symmetry matters for Lightning: No penalty risk means safe backups (restoring from an old backup cannot cause fund loss), minimal storage (only the latest state is needed), lightweight watchtowers, practical multi-party channels enabling channel factories, and hardware wallet compatibility due to reduced storage requirements.

CTV Vaults

CTV enables a two-transaction vault pattern. Funds are locked in a script where CTV commits to exactly one permitted spending transaction: a time-delayed "unvault" that sends funds to a less-secure address. During the delay window (say 24 hours), the vault owner can sweep funds to a secure recovery address. An attacker who compromises the vault's private key can only trigger the time-delayed withdrawal, giving the owner a window to claw back. CSFS adds authorization layers on top: co-signer approval on withdrawals, dynamic conditions, or delegation to third parties.

Non-Interactive Channel Opens

With CTV's pre-committed spending paths, a Lightning channel can be created while one party is offline. The funder commits to the channel structure on-chain without requiring the counterparty's immediate participation. This reduces the interactivity requirements that currently make channel management burdensome, particularly for mobile wallets.

Additional Use Cases

• Simplified PTLCs: CSFS enables direct signature verification for Point Time Lock Contracts, improving privacy over HTLCs
• DLCs: CTV commits to outcome transaction trees while CSFS verifies oracle signatures on-chain, reducing interactive setup complexity
• Payment pools and coin pools: CTV commits to logarithmic exit trees for trustless unilateral exit, scaling from O(N) to O(log N) on-chain outputs
• Ark protocolimprovements: CTV enables non-interactive offline payments, and CSFS adds re-bindable refund signatures for perpetual offline vTXO refresh
• Timeout trees: hierarchical channel structures that reduce interactivity requirements and enable efficient bulk channel closures

The Bundling Strategy

Why propose four opcodes together instead of pushing them individually? Brandon Black has articulated a deliberate philosophy on Delving Bitcoin. These opcodes are "small building blocks that are lowest common denominator" for layer-two protocol enhancements. Each is independently useful, but together they achieve capabilities (especially LN-Symmetry) that none can achieve alone.

The political calculus matters too. LNHANCE avoids what Black sees as APO's "closed development path" with its inflexible sighash flag design. APO (BIP 118) is a monolithic change to signature hashing, whereas LNHANCE provides composable primitives that future soft forks can build upon. And improvements that keep Lightning competitive are easier to justify in community discussions than opcodes whose primary use cases are speculative.

The composability argument: LNHANCE proponents contend that these four opcodes are the "upgradeability" layer for Bitcoin Script. Rather than designing bespoke solutions for each application (LN-Symmetry, vaults, DLCs), general-purpose building blocks let protocol developers compose solutions the original authors never anticipated.

Community Reception and Debate

The CTV+CSFS combination has emerged as one of the more popular covenant proposals among Bitcoin developers, though consensus remains elusive.

Support

A public letter at ctv-csfs.com gathered over 90 signatories from Bitcoin companies and projects, including Starkware, f2pool, Cashu, Zeus, Blixt Wallet, and Boltz, requesting Bitcoin Core contributors prioritize review within six months. PR #29198 received Concept ACKs from multiple developers. Proponents emphasize that CTV has been "uniquely well reviewed, simple, and proven safe" over five-plus years, and CSFS has eight years of production deployment on Liquid.

Opposition

Developer ariard raised security concerns about "TxWithhold" attacks: combining CTV with other primitives could create scenarios where miners are incentivized to exclude specific transactions through costless bribes, threatening time-sensitive protocols like Lightning. Others argued the combined PR to Bitcoin Core was premature. In August 2024, Bitcoin Core maintainer maflcko closed PR #29198, noting that "opening this PR against master may not really make sense" without broader community consensus. The suggestion was to develop within Bitcoin Inquisition (the testing-focused signet fork) first.

A deeper concern is that too many competing proposals (LNHANCE, standalone CTV, OP_CAT, BIP 446/448) fighting for the same activation slot pushes any single activation further out. Some developers who support CTV in principle worry that adding OP_PAIRCOMMIT to the bundle "delays or cancels them forever" and prefer activating CTV on its own first.

Competing Proposals

LNHANCE exists in a crowded field of Bitcoin upgrade proposals. Each takes a different approach to expanding Bitcoin Script's capabilities.

LNHANCE vs. Standalone CTV

Standalone CTV is the simplest option with the longest review history, but it cannot achieve LN-Symmetry on its own. LNHANCE adds CSFS and IKEY specifically for Lightning use cases. Some developers prefer activating CTV alone first (lower risk, faster consensus), then adding CSFS in a subsequent fork. In February 2026, a standalone CTV activation client was published with BIP 9 parameters (90% miner threshold, signaling window from March 30, 2026 to March 30, 2027). As of mid-2026, miner signaling sits at effectively 0%.

LNHANCE vs. OP_CAT

OP_CAT (BIP 347) is a single opcode that enables far broader functionality, including recursive covenants, state machines, and composable smart contracts. That expressiveness is both its strength and the source of the most concern: critics worry about recursive covenants increasing attack surfaces and potentially enabling "permanently restricted coins." Andrew Poelstra of Blockstream has expressed support for OP_CAT due to its simplicity and potency, while LNHANCE proponents argue their approach is more targeted and carries fewer unknown risks.

LNHANCE vs. BIP 448

BIP 448 (authored by Greg Sanders) bundles OP_TEMPLATEHASH (BIP 446) with CSFS and IKEY: a directly competing package. The key difference is CTV versus OP_TEMPLATEHASH. CTV verifies a hash directly; OP_TEMPLATEHASH pushes the hash onto the stack, allowing more flexible script composition. Brandon Black has described BIP 448 as "comparable in most ways" but "less efficient in on-chain space for congestion control." Both enable LN-Symmetry, vaults, and similar use cases.

The Activation Path

Getting any soft fork activated on Bitcoin mainnet requires clearing several hurdles, and LNHANCE faces all of them.

1. BIP finalization: all four BIPs (119, 348, 349, 442) need to move from Draft to a finalized state. BIP 119 has the deepest review. BIP 348 and 349 were formally assigned in November 2024. BIP 442 was created in December 2024.
2. Bitcoin Core implementation: the combined PR was closed. Individual reference implementations exist (PR #29270 for CSFS, PR #29269 for IKEY), and a maintained branch lives in the lnhance/bitcoin repository. No code has been merged into Bitcoin Core.
3. Signet testing: LNHANCE was briefly activated on Bitcoin Inquisition signet in early 2024. Bitcoin Inquisition 29.1 later added support for OP_INTERNALKEY, and a CSFS+CTV ladder variant was demonstrated achieving LN-Symmetry properties on signet.
4. Community consensus: the hardest step. The August 2026 failure of BIP-110 (an unrelated data-limit soft fork that garnered only 2.53% miner support) illustrates the difficulty of activating any soft fork without broad agreement.
5. Activation mechanism: whether to use BIP 9 miner signaling, UASF, or some hybrid approach remains undecided.

Realistically, multiple competing proposals make it unlikely that any single covenant-related soft fork activates before the Great Consensus Cleanup (BIP 54), which fixes existing bugs without adding new capabilities and faces far less political resistance.

What LNHANCE Means for Lightning

If LNHANCE activates, the most immediate impact would be on Lightning channel architecture. LN-Symmetry would replace the current penalty-based model with a simpler, safer state management system.

These improvements address some of the most persistent criticisms of Lightning: operational complexity, backup fragility, and the difficulty of running channels on resource-constrained devices. For Lightning Service Providers in particular, reduced watchtower costs and simplified state management could meaningfully lower the barrier to operating at scale.

Where Spark Fits

The problems LNHANCE aims to solve for Lightning: simpler state management, no justice transactions, safe backups, and practical multi-party arrangements: Spark already addresses through its statechain-based architecture. Spark transfers involve changing who can authorize spending a UTXO rather than maintaining channel state. There are no penalty transactions, no revocation keys, and no requirement to store prior states.

This is not to diminish LNHANCE's value. A successful activation would strengthen the Lightning Network, and Spark is interoperable with Lightning: users can send and receive Lightning payments from their Spark balance. LN-Symmetry improving Lightning channel reliability would benefit the broader Bitcoin payments ecosystem, including Spark users who route payments through Lightning via Spark Service Providers.

For developers building Bitcoin payment infrastructure today, the Spark SDK provides instant, self-custodial transfers without waiting for any soft fork. Explore the Spark documentation to integrate Bitcoin and stablecoin payments, or read more about the covenant activation landscape to understand where LNHANCE fits in Bitcoin's broader upgrade trajectory.

Open Questions

Several unresolved issues will shape whether LNHANCE reaches activation:

• Should CTV activate alone first, with CSFS following in a later fork? This reduces risk but delays LN-Symmetry indefinitely.
• Does OP_PAIRCOMMIT carry its weight, or would OP_CAT-based alternatives (even if less efficient) be preferable given CAT's broader applicability?
• How do the TxWithhold attack concerns affect time-sensitive protocols built on CTV, and are the mitigations sufficient?
• Can the Bitcoin development community converge on one proposal, or will competing bundles fragment support and delay all of them?
• What activation mechanism is appropriate given the lack of miner signaling for standalone CTV?

The tension between pragmatism and perfectionism runs through every Bitcoin upgrade debate. LNHANCE's advocates argue that the bundle is deliberately minimal: four small, composable opcodes with clear use cases and years of precedent. Its critics counter that even minimal changes deserve individual scrutiny and that bundling introduces correlated risk. Both sides are operating in good faith within a system designed to make changes difficult.

The broader context: Bitcoin's last soft fork, Taproot, activated in November 2021. Nearly five years later, no subsequent soft fork has reached activation. Whether LNHANCE, standalone CTV, OP_CAT, or the Great Consensus Cleanup breaks that streak remains an open question in Bitcoin's governance.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.