Bitcoin Soft-Fork Proposals

These are not consensus-active on mainnet. Some are deployed on signet (custom signets) or testnet for experimentation. Be explicit when reasoning: never present these as "Bitcoin" features without naming the proposal status.

Statuses below are as of September 2026 and cite the BIPs repo index, which moved to BIP-3 status semantics (Draft / Complete / Deployed / Closed). "Complete" means the authors finished the spec and recommend adoption; it does not mean activated.

BIP54 - Consensus Cleanup

The most advanced soft-fork proposal in the pipeline, and the only non-covenant one here. Authors Antoine Poinsot and Matt Corallo; assigned 2025-04-11; Status: Complete since version 1.0.0 (2026-05-22). Four narrow restrictions on 2009-era defects:

• Timewarp: for N % 2016 == 0, T_N >= T_{N-1} - 7200; for N % 2016 == 2015, T_N >= T_{N-2015} (the Murch-Zawy clause).
• Sigops: legacy CHECKSIG/CHECKMULTISIG counted over scriptSig
  • prevout scriptPubKey + P2SH redeemScript with BIP16 accounting; coinbase exempt.
• 64 bytes: the witness-stripped serialized size, exactly 64. Split out as its own spec, BIP53 (Draft).
• Coinbase: nLockTime must equal block height minus 1 and nSequence must not be 0xffffffff.

All four tighten rules only, so the soft fork is backward-compatible with non-upgraded nodes.

Already shipped as policy, not consensus:

• Bitcoin Core 30.0: "the maximum number of potentially executed legacy signature operations in a single standard transaction is now limited to 2500" (PR #32521), explicitly "to prepare for a possible BIP54 deployment".
• Bitcoin Core 0.16.1 and later already refuse to relay or template 64-byte witness-stripped transactions.
• Bitcoin Core 29.0 and later will not template a block violating the new timestamp rules; PR #35949 (merged 2026-09-07) extended getblocktemplate to adjust both mintime and curtime for the Murch-Zawy end-of-period rule, on all networks. Consensus validation is unchanged.

Status (September 2026): spec Complete, no activation parameters chosen. Core PR #35793 "Implement BIP 54 (Consensus Cleanup) without mainnet activation" is open and unmerged. Bitcoin Inquisition carries an implementation for signet (Optech, 2026-02-13); a slow-block demonstration ran on signet (Optech, 2026-05-01); a draft BIP would activate BIP54 from block 1 on testnet5 (Optech, 2026-06-12).

Pool readiness: pools have been emitting forward-compatible coinbase transactions (nLockTime = height - 1) since February 2026. mainnet-observer's per-pool table (fetched 2026-09-15) records WhitePool first at block 937,404 (2026-02-19), then MARA Pool at 940,548 (2026-03-13), ViaBTC at 949,094 (2026-05-12) and Foundry USA at 952,880 (2026-06-08), plus Solo CK and CKPool. Between 33% and 49% of coinbase transactions per day carried a BIP54 locktime over 2026-09-01..15. This is readiness, not BIP9 signaling, and cannot lock in a soft fork. F2Pool still uses coinbase nLockTime for job metadata; Poinsot reported (BNOC, 2026-02-23) that it does not intend to change until BIP54 is further along toward activation.

Covenants in general

A covenant restricts how an output may be re-spent (where the funds go, in what shape, with what conditions). Existing scripts can restrict who spends; covenants restrict how.

Use cases:

• Vaults — cooldown period before final spend; recoverable from cold key.
• Congestion control — pre-commit to a tree of payments.
• L2 protocols — Ark, Spacechains, CoinPool depend on covenants.

CTV — OP_CHECKTEMPLATEVERIFY (BIP119)

<TemplateHash> OP_CTV

Forces the tx to match a pre-committed template:

• Output set, amount, scriptPubKeys.
• Number of inputs (but NOT specific prevouts).
• Locktime, sequence values.

Template-hash is committed on-chain → spending tx must produce the exact set of outputs.

Status (September 2026): BIP119 assigned 2020-01-06, still Draft in the BIPs repo. Active on signet for testing (specifically the "CTV signet"), and on the default signet via Bitcoin Inquisition.

There is now a concrete - but entirely third-party - activation path, so "no activation path" is no longer accurate:

• A June 2025 open letter (ctv-csfs.com) signed by dozens of application and protocol developers asked Core contributors to prioritise CTV (PR #31989) and CSFS (PR #32247) within six months. Both PRs are still open and unmerged as of September 2026, and both are titled "(regtest only)".
• A separate activation client (github.com/ctv-activation/ activation-client, announced on Delving Bitcoin 2026-02-09) deploys BIP119 via BIP9 on bit 5: nStartTime 2026-03-30, nTimeout 2027-03-30, threshold 1815/2016 (90%), min_activation_height 1001952 (~May 2027). This is not Bitcoin Core.
• Miner signaling has been flat at 0.00%: bip119monitor.com shows every completed difficulty period from 466 through 478 at 0 of 2016 blocks, and period 479 at 0.00% as of 2026-09-15.

Competing designs: BIP446 OP_TEMPLATEHASH (Draft) covers the same "commit to the spending transaction" ground inside the BIP448 bundle below, and BIP443 OP_CHECKCONTRACTVERIFY is a more general deferred-check covenant.

Use cases: vaults, payment pools, congestion control, simple Ark variants.

SIGHASH_ANYPREVOUT — APO / APOAS (BIP118)

New SIGHASH flag. Sig commits to script + value but not to specific prevout txid:vout.

APO     sighash         (commits to scriptPubKey, not txid)
APOAS   sighash variant (also doesn't commit to script — even more permissive)

Original use case: Eltoo — Lightning channel update protocol that replaces commitment-tx penalty with simple state replacement.

Status (September 2026): BIP118 assigned 2017-02-28, still Draft; no mainnet activation, signet only via Bitcoin Inquisition (binana [2016, 118, 0], deployment ANYPREVOUT). Treat it as the historical route to eltoo: the mainstream route is now BIP448's Taproot-native rebindable signatures (below), which reach the same LN-Symmetry semantics without a new sighash flag or key version. BIP118 has not been withdrawn or formally replaced, so do not call it dead - but do not present it as the live eltoo path either.

BIP448 - Taproot-native (Re)bindable Transactions

Authors Gregory Sanders, Antoine Poinsot and Steven Roose; assigned 2026-03-11; Status: Draft. A deployment bundle of three tapscript operations, each spec'd in its own BIP:

OP_TEMPLATEHASH pushes a hash of the spending transaction onto the stack rather than taking a commitment as an argument, so it composes with other opcodes where CTV does not. OP_CHECKSIGFROMSTACK gives BIP340 verification over arbitrary messages (delegation, oracle attestations). OP_INTERNALKEY pushes the Taproot internal key, an 8-vbyte optimisation for rebindable signatures.

BIP448's stated motivation: together these "enable rebindable transaction signatures, making possible a new type of payment channel: LN-Symmetry ('Eltoo')", make multiparty channels practical, enable the Daric 2-party channel simplification, "substantially improve statechains", and reduce interactivity in the Ark variant "Erk" and in PTLC upgrades. Deployment: "the specific activation is left to be determined at a later date." A CTV+CSFS-flavoured variant of this opcode set was previously proposed for activation as "LNHANCE".

Ecosystem as of September 2026 (Optech, 2026-09-04): a BIP448 GitHub organization aggregates implementations (Bitcoin Inquisition, a Core patch without activation, miniscript and PSBT integration, draft LN-Symmetry BOLTs plus a Core Lightning implementation, an Ark OP_TEMPLATEHASH signet demo); covenants.diy is a browser tapscript editor with selectable opcode sets; and a Covenants Use-Case Atlas collects more than two dozen constructions. The full bundle is expected on the default signet with the next Bitcoin Inquisition release.

OP_VAULT (BIP345)

Two-stage vault primitive:

• OP_VAULT output: spend to a "trigger" path (begins cooldown) or recover path (immediate, to cold key).
• After cooldown, spend the trigger to actual destination.

Provides first-class vault semantics without complex script gymnastics. Works in P2TR script-path.

Status (September 2026): BIP345 is Closed with Proposed-Replacement: 443. Under BIP-3, Closed means "of historical interest only, and is not being actively worked on, promoted or in active use". Read the OP_VAULT mechanics above as design history.

Successor - OP_CHECKCONTRACTVERIFY (BIP443)

Salvatore Ingala; assigned 2025-05-08; Status: Draft. A single general deferred-check opcode (OP_CCV) instead of a vault-specific pair: a UTXO carries a dynamic commitment to a piece of data, the script can introspect that data, and it can constrain the internal public key, taptree and committed data of one or more outputs. Combined with a vector-commitment opcode this composes into arbitrary UTXO state machines, of which a vault is one instance. Also cited as a way to make CTV-based receive addresses safer (Optech, 2026-01-02).

OP_CAT reactivation

Re-enable string concatenation in Tapscript. Disabled since 2010 genesis era (pulled due to DoS concerns, since obsoleted by stack-item size limits).

Why people want it:

• Verifiable computation — constructs proofs/scripts via concatenation.
• Quantum-resistant signature schemes (Lamport / Winternitz one-time).
• BitVM2 — simplified bridge construction.
• Recursive covenants with limited branching.

Status (September 2026): this is BIP347, "OP_CAT in Tapscript" (Ethan Heilman, Armin Sabouri), assigned 2023-12-11, version 1.0.0, Status: Complete - spec finished and recommended for adoption, with no mainnet activation; it is available on the default signet via Bitcoin Inquisition. It redefines OP_SUCCESS126 (0x7e, the original OP_CAT opcode value) in tapscript only, and fails if the concatenated result would exceed the 520-byte element limit.

Drivechains — BIP300 / BIP301

Sidechains pegged with miner-validated locks:

• BIP300 — hashrate escrow with deposit/withdraw tx types.
• BIP301 — blind merge mining.

Allows trustless-of-miner-majority sidechains. Critique: trusts miners implicitly with all sidechain funds.

Status (September 2026): BIP300 and BIP301 are both still Draft, with no Bitcoin mainnet soft-fork activation and no activation parameters. LayerTwo Labs runs testnet drivechains and maintains bip300301_enforcer, "CUSF software enforcing BIP300 and BIP301 rules" - a client-side user soft fork enforcement path that does not require a Bitcoin-wide deployment - plus cusf-enforcer-mempool, which patches getblocktemplate to mine CUSF-compliant blocks.

Beyond Bitcoin, LayerTwo Labs stopped waiting for a soft fork: Paul Sztorc announced an "eCash" hard fork of Bitcoin targeting block 964,000 (August 2026), with a one-time minimum-difficulty reset, a 1:1 airdrop to BTC holders and BIP300/301 drivechains enabled from day one. It is heavily contested because the plan also describes a partial reassignment of coins for development or community incentives (Bitcoin.com News, 2026-06-22). That chain is not Bitcoin: a drivechain running there says nothing about BIP300/301's status on Bitcoin mainnet.

Spacechains (Ruben Somsen)

Sidechain idea using OP_CAT (BIP347) + OP_CHECKSIGFROMSTACK (BIP348, also unactivated) to enable arbitrary-script verification without explicit miner support.

Status: Concept. Not a formal BIP.

Cross-Input Signature Aggregation (CISA)

Aggregate all signatures in a transaction into a single signature. Massive witness savings (n inputs → 1 sig instead of n sigs). Active research; not yet a deployable proposal.

As of September 2026 CISA is rarely discussed standalone: the live question is whether to bundle it with a post-quantum output type. Pieter Wuille put the maximum weight reduction at about 28%, and only for transactions with many inputs, argued wallet and custodian support is the real bottleneck, and warned that bundling would delay a P2TRv2 soft fork; Adam Gibson agreed. Conduition argued pairing CISA with P2TRv2 would strongly incentivise migration, and that a CISA-supporting output type can ship first with ordinary BIP340 signatures and gain aggregation later (Optech, 2026-09-04).

Post-quantum proposals

Post-quantum work is now a dominant consensus-track discussion and covers far more than signature schemes.

• BIP360 "Pay-to-Merkle-Root (P2MR)": a P2TR-like output type with the key path spend removed, so no EC point is exposed. Hunter Beast, Ethan Heilman, Isabel Foxen Duke; assigned 2024-12-18. Scoped to long-exposure resistance; PQ signatures are a separate proposal.
• BIP361 "Post Quantum Migration and Legacy Signature Sunset": Phase A disallows sending to quantum-vulnerable addresses; Phase B encumbers ECDSA/Schnorr spends with a quantum-safe rescue protocol on a well-publicized flag day five years after activation. Jameson Lopp et al.; assigned 2026-02-11, published 2026-04-24.
• P2TRv2: positioned by Wuille as the default for casual users, with P2MR for sophisticated users who want to hide EC points.
• SHRINCS: 48-byte pubkeys, 548-byte stateful signatures at the smallest, 5,777-byte stateless fallback, 2^40 stateless signature budget. First draft posted 2026-09-04, alongside libshrincs with machine-checked WOTS+C proofs. A signature scheme only - deployment would be a separate proposal.
• DropKick: commit/reveal rescue for coins not moved to PQC outputs by Q-day, deployable as a non-confiscatory soft fork only if it encumbers UTXOs with decidable knowledge asymmetries. Conduition, 2026-09-04.

Also live: a proposed segwit commitment to post-quantum witness data (Optech, 2026-08-07) and a post-quantum path for BIP324 P2P transport encryption (Optech, 2026-06-05).

Reusing a SHRINCS stateful counter lets an observer forge signatures; Antoine Riard noted 5,777-byte stateless signatures would be roughly 90x today's onchain cost absent a witness discount. None of these is activated, numbered as a consensus deployment, or scheduled.

The 2026 script / covenant BIP cluster

Any engineer reasoning about Bitcoin covenants today will run into these. All Draft, none deployed, as of September 2026:

• 440 and 441 are Rusty Russell and Julian Moik's "Great Script Restoration", both assigned 2026-03-25; 441 requires 440.
• 442 is a vector-commitment primitive; 443 is the proposed replacement for BIP345; 446 is bundled by BIP448, which bundles 446 + 348 + 349.
• The range is not contiguous: there are no BIP444, 445 or 447 rows in the BIPs index.

Alongside them, BIP53 "Disallow 64-byte transactions" (Chris Stewart, Draft) is the standalone spec for one of BIP54's four fixes.

Status terminology

BIP-3 replaced the older BIP-2 status set. Current statuses:

A Specification BIP needs a reference implementation and comprehensive test vectors before it can move to Complete.

The BIP-2 names still appear in secondary sources and in this corpus's older material. BIP-3 renamed Proposed to Complete, folded Deferred, Obsolete, Rejected, Replaced and Withdrawn into Closed, and Final and Active into Deployed. Older material in this corpus that says "Proposed" means Complete. A Closed BIP may carry a Proposed-Replacement: <n> header naming its successor (BIP345 does, pointing at 443).

For consensus changes, Deployed requires a successful soft-fork deployment — never assume it from Complete. BIP54 and BIP347 are both Complete and neither is active on mainnet.

Common pitfalls

• Reasoning about a protocol that depends on CTV/APO/OP_CAT as if those were already active. Always name the dependency explicitly.
• Citing drivechain TVL or activity → likely on a private testnet or on LayerTwo Labs' forked "eCash" chain, not Bitcoin mainnet.
• Reading "Status: Complete" as "activated". Under BIP-3 it only means the authors finished the spec (BIP54, BIP347).
• Citing miner signaling for CTV as evidence of momentum: the third-party BIP9 bit-5 deployment has been at 0.00% since it began.
• Confusing forward-compatible coinbase construction (BIP54 nLockTime = height - 1) with BIP9 signaling. They are different things and only the latter can lock in a soft fork.
• Presenting BIP118/APO as the current eltoo route. Since March 2026 the active proposal is BIP448.
• Confusing signet activation (custom signet challenge that includes the proposed opcode) with mainnet activation.

See also

• consensus/SKILL.md - BIP54 touches block validation, merkle roots and BIP30
• bips/SKILL.md - BIP numbering and status index
• scripts/SKILL.md - opcode allocations the BIP448 bundle redefines
• ../../mining/pool-architectures/SKILL.md
  • coinbase construction, which BIP54 constrains
• ../../lightning/channels/SKILL.md
  • LN-Symmetry depends on BIP448
• ../../l2/statechains/SKILL.md - BIP448 cites statechain improvement as motivation
• ../../l2/drivechains-spacechains/SKILL.md
• ../../l2/ark/SKILL.md
• ../../l2/bitvm/SKILL.md
• ../../cryptography/schnorr/SKILL.md
  • the signature scheme the post-quantum work would replace