PR Review Club: BIP-348 (OP_CHECKSIGFROMSTACK) (regtest only)

[zaidmstrr]

Bitcoin Core PR Review Club

Session Details

• Date: 22-05-2025
• Time: IST 19:00 (UTC 13:30)
• Title: BIP-348 (OP_CHECKSIGFROMSTACK) (regtest only)
• PR: #32247

PR Summary

This PR implements OP_CHECKSIGFROMSTACK (OP_CSFS) under BIP-348, initially restricted to regtest only. It introduces a general-purpose opcode that allows Bitcoin Script to verify a digital signature over an arbitrary message, rather than only over the transaction being executed. This is a significant generalization compared to existing signature opcodes like OP_CHECKSIG, which are limited to verifying transaction-derived hashes.

Why This Matters

Bitcoin's current signature opcodes are powerful for authorizing UTXO spends but limited when it comes to general-purpose data authentication. By enabling arbitrary message verification, OP_CSFS unlocks a range of use cases that were previously difficult or impossible to implement directly on-chain:

• Paying for signatures: Enables trustless payments for digital signatures—useful in contract protocols.

• Delegation: Allows off-chain delegation of spending authority without building complex multisig schemes.

• Oracles: Supports external event-based contracts verified by signed oracle messages.

• Double-spend protection: Makes it feasible to build economic deterrents against double-spending.

Transaction Introspection Capabilities:
Combined with other opcodes (e.g. OP_CAT), CSFS allows introspection — the ability for scripts to inspect and reason about transaction data. This makes it possible to replicate features like OP_CHECKLOCKTIMEVERIFY or even the proposed SIGHASH_ANYPREVOUT entirely at the script level.

Prerequisites

Knowledge about Bitcoin scripts and opcodes is necessary.

Notes

1. Covenants and the Great Script Restoration:
   Covenants have been a long-debated topic in the Bitcoin space. In principle, they offer a powerful way to control how outputs are spent—enabling secure vaults, congestion control, recursive smart contracts, and more. However, covenants also raise concerns about fungibility, censorship, and unintended centralization. For this reason, the Bitcoin community has historically been cautious about covenant proposals.
   Roose praises Rusty Russell’s ongoing project called the Great Script Restoration (GSR), which is focused on restoring and enhancing Bitcoin Script's expressiveness by re-enabling previously disabled opcodes and introducing a new mechanism called VarOps—bounded variants of currently disabled operations that ensure computational safety. GSR also encourages introducing introspection-based opcodes—Script instructions that allow a program to examine transaction data—providing a foundation for covenant-like behaviors without introducing full general-purpose programming.
   Roose is aligned with this philosophy: rather than pushing for fully generalized covenants all at once, we should take small steps that deliver tangible utility, maintain security, and preserve Bitcoin's conservative culture.

2. OP_CHECKTEMPLATEVERIFY (CTV):
   CTV allows a script to specify exactly how an output must be spent in the future by asserting that the next transaction matches a predetermined template. It essentially restricts spending to a transaction with specific properties like outputs, locktimes, and fee rates. CTV is useful in constructing “pre-signed transaction” like behavior without the need to actually pre-sign anything.
   CTV is especially helpful in protocols that rely on chains of transactions like vaults, channel factories, and Ark, a proposed second-layer protocol. In all these systems, the need to create and store multiple pre-signed transactions introduces fragility and complexity. By using CTV, protocols can become more robust and flexible since the script enforces future spending conditions without the overhead of storing signatures.

3. OP_CHECKSIGFROMSTACK (CSFS):
   CSFS allows a script to validate a signature over arbitrary data (not just a transaction), with the data and public key both passed on the stack. This detaches signature verification from the structure of the spending transaction, enabling a level of abstraction that is vital for many smart contracts.
   CSFS is particularly helpful in modularizing contract logic. For example, BitVM and other optimistic rollups on Bitcoin use complex constructions where different components of the contract logic need to be proven off-chain and verified on-chain. CSFS allows for flexible verification of signatures tied to off-chain commitments, enabling more efficient and secure proofs.

4. Why These Two OpCodes Work Well Together?
   While each opcode provides important functionality, it is their combination that truly unlocks new design space in Bitcoin contracts. CTV handles the constraint of future transaction structure, while CSFS enables flexible verification of associated signatures. Together, they can replicate the behavior of more advanced proposals like OP_CAT + introspection, or even SIGHASH_ANYPREVOUT (used for Eltoo), without the same risks of overreach or complexity.
   Additionally, bundling them together in a single softfork reduces the social cost of proposing multiple consensus changes. If the community is going to engage in a BIP process, review, and activation planning, doing so for a two-opcode proposal that enables multiple real-world use cases is more efficient than doing it twice for each feature.

Questions

1. What do you understand by this new opcode CSFS?
2. How can proposals like covenants be beneficial by this opcode?
3. Which SigVersion does this OP_CHECKSIGFROMSTACK use?
4. What does the function EvalChecksigFromStack do?
5. What will happen when legacy nodes don't recognise this opcode?

Preparation Steps

1. Clone the Bitcoin Core repository if you haven't already:

   git clone https://github.com/bitcoin/bitcoin.git
   

2. Fetch and checkout the PR:

   cd bitcoin
   git fetch origin pull/[PR_NUMBER]/head:pr_review
   git checkout pr_review
   

3. Build and run tests (if applicable):

   cmake -B build
   cmake --build build
   

4. Review the code changes and consider the provided questions.

Joining the Session

The Jitsi link will be shared in the #announcements channel of the Bitshala Discord shortly before the session.

Looking forward to seeing you there!