OP_CHECKCONTRACTVERIFY and its amount semantic

Posted by halseth

Jun 13, 2025/11:11 UTC

The exploration of different methods for input script validation during transaction or block processing in btcd, similar to practices in bitcoind, reveals a complex landscape weighed between parallelism and the necessity for managing shared mutable states. The implementation attempts in btcd highlight the adaptability of Go's goroutines for distributing tasks, as detailed in the script validation section of the project's documentation. This flexibility introduces a decision-making process on whether to incorporate a shared state guarded by mutexes to facilitate parallel input validation or to opt for alternative approaches that might avoid such complexities.

One such alternative involves pre-checking the flow of intended amounts and utilizing CCV for data assertion during script execution, a method that simplifies integration into the script engine by minimizing direct interactions with it. This approach, referred to as "annex hints," offers a separation of concerns and paves the way for future enhancements, such as adding more functionalities via soft forks without modifying the script engine. It also opens up considerations for leveraging this technique alongside other script primitives, potentially allowing for the specification of fund flows per input which could be advantageous for creating partially signed transactions where the fund's direction is predetermined but outputs remain unspecified.

Another concept under consideration is the deferred checks framework, which might align well with btcd's capabilities. This framework suggests performing additional validations after a set of dependent inputs have been initially checked, fitting into the broader vision of enhancing batch signature validation processes. The idea of cross-input signature validation, or batch validation, is identified as an important feature to support in the future, indicating that none of the discussed approaches—shared state, annex hints, or deferred checks—should inherently obstruct the development of such a capability. Each method, however, comes with its own set of tradeoffs, emphasizing the need for careful consideration in choosing the path forward, especially in light of potential real-world applications and benchmarking outcomes.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

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

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

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

Give Feedback