A quantum resistance script only using op_ctv/op_txhash and no new signatures

Dec 18 - Feb 20, 2026

  • The email presents a detailed exploration of enhancing Bitcoin transactions' security against quantum attacks and signature forgery through a novel method combining OP_CHECKTEMPLATEVERIFY (OP_CTV) and OP_TXHASH/OP_CHECKTXHASHVERIFY protocols, as per BIP119 and a draft proposal.

This approach entails creating a multi-phase envelope to safeguard transactions. Initially, in Phase 0, it aims to channel all value into an Anchor envelope without locking down the final destinations or future templates, using OP_TXHASH to set conditions that prevent value leakage outside of this Anchor output. Subsequently, Phase 1 involves spending the Phase 0 UTXO to establish the Anchor UTXO on-chain, employing a Taproot script tree that offers two paths: a reveal path requiring a one-time secret for transactions adhering to a specific template via OP_CTV, and an escape hatch that operates without disclosing the secret but must match a different template, also enforced by OP_CTV. Phase 2 then allows choosing between these paths to spend the Anchor UTXO, with built-in security measures to protect against theft even if signatures are compromised.

This structure introduces restrictions that limit attackers to delaying or forcing transaction execution rather than enabling fund theft, attributing to the quantum-resistant design and reorg resistance provided by the relative timelock mechanism. Furthermore, the protocol supports graceful degradation against quantum advancements and eliminates the need for nodes to maintain historical transaction indices, making it prunable-friendly. For more technical details and demonstration code, refer to the provided Gist.

However, challenges arise from the construction's requirement for predetermined transaction (T) and expenditure (E) amounts at the creation of Phase 0 outputs, necessitating precise consolidation of these outputs to match the total CTV output values. This limitation complicates future transactions due to reduced flexibility. Moreover, the reliance on secp256k1 and NUMS points introduces quantum vulnerability, as these could be compromised by quantum adversaries, rendering the current construction not quantum-safe. The inability to redirect funds to a new, quantum-safe address upon withdrawal further exacerbates this issue, highlighting a lack of adaptability to emerging threats. To mitigate these concerns, adopting Conditioned Commitment Verification (CCV) in place of TXHASH for transaction enforcement is proposed, allowing for value flow enforcement and the integration and extraction of the CTV reveal spend at the time of spending, enhancing both security and usability.

Additionally, the discussion explores alternatives to relying on numerical points (NUMS) for operation, suggesting a fallback to the original system construction as a primary safety mechanism. This strategy limits potential damages from attacks to only causing disruption rather than expending resources from the system, emphasizing a robust baseline defense against malicious activities.

Furthermore, the conversation delineates important differences between P2TR and P2TSH script operations, particularly in terms of their susceptibility to quantum attacks. While P2TR requires a NUMS point for the internal key, potentially vulnerable to quantum adversaries, P2TSH does not suffer from this flaw, indicating a critical choice between script operation types for security considerations.

The incorporation of secret-reveal sequences in transaction protocols emerges as a critical defense against unauthorized transactions, ensuring that funds cannot be redirected without the correct secret, despite potential signature vulnerabilities. This mechanism, alongside the necessity for a signature that imposes a cost on attacks, forms a multifaceted security layer against unauthorized transactions and Miner Extractable Value (MEV) attacks.

Lastly, the email touches on proposals for a new version of SegWit that would enforce script-only evaluation by eliminating key-path spending, aiming to make signature forgery irrelevant. This could be implemented via a soft fork, introducing a new witness version with semantics enforced only by upgraded nodes. Utilizing CCV instead of TXHASH could address fee issues by enforcing value flow and embedding and extracting the CTV reveal spend at spend time, offering a potential resolution to identified challenges.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from high signal bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiDecoding BitcoinWarnet
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project.

Give Feedback