[0/4] A Bitcoin Scripting Proposal BIP Quartet

Their work, currently in draft form and available for review on GitHub, introduces several key innovations to Bitcoin scripting. These include a proposal for a variable operations (varops) budget to replace the traditional sigops budget, enabling limitations on script operations based on transaction weight, thereby allowing for the reactivation of previously disabled opcodes, increasing stack object size and capacity, and reintroducing arbitrary-length arithmetic operations with exclusively unsigned numbers.

A significant part of their proposal is the introduction of an opcode, OP_TX, designed to facilitate data introspection within scripts, making it easier to handle large data sets and expanding script functionality. Furthermore, they propose new opcodes tailored for Tapscript v2, such as OP_CHECKSIGFROMSTACK and OP_SEGMENT, aimed at optimizing Script's utility for a wide range of applications. For practical assessment, a prototype implementation has been used, details of which can be found at this GitHub repository. Rusty and Julian are open to feedback, signaling a willingness to engage in discussions about the future direction of Bitcoin scripting capabilities.

The varops budget introduced seeks to provide a flexible and comprehensive approach to evaluating script operations through a systematic cost framework based on stack data interactions. This addresses constraints on non-signature operations within Bitcoin's scripting mechanism that emerged due to restrictions implemented in version 0.3.1. The proposed cost model emphasizes the size of stack operands over their values and establishes upper limits on script sizes and stack object sizes to ensure efficiency even under extreme conditions. A transaction-wide varops budget is calculated by multiplying the total transaction weight by a fixed factor, enabling cross-input introspection and ensuring transactions adhere to set limits.

Moreover, the BIP proposes reinstating functionalities disabled since version 0.3.1, including re-enabling previously disabled opcodes and extending stack and numerical value limits, to revive Bitcoin scripting's full potential. Specific rules outlined ensure scripts do not exceed allocated budgets, with validation failing under conditions such as surpassing the varops budget or exceeding stack element size limits.

The introduction of OP_TX in Tapscript v2 represents a significant advancement in Bitcoin scripting, enabling explicit and efficient introspection of the current transaction. This expands the possibilities for creating complex, condition-based spending scripts. OP_TX's design supports extracting multiple values simultaneously into a single stack element, streamlining data access within scripts. Its implementation considers the computational cost associated with accessing transaction data, introducing a "varops cost" to maintain script execution integrity and efficiency.

In addition, the blog post discusses the ongoing development of Tapscript and the potential enhancement of its functionality within SegWit v1 32-byte witness programs. It highlights discussions around replacing the CODESEPARATOR opcode with SEGMENT, suggesting improvements in efficiency and script operation capabilities. The dialogue also covers advanced cryptographic techniques and proposals for constructing and verifying taproot addresses, emphasizing the importance of specific components in the calculation process and exploring sophisticated verification functions within cryptographic operations.

Lastly, the discussion on Tapscript v2 focuses on clarifying script selection mechanisms and enhancing Bitcoin development by proposing more precise naming conventions and functional selectors. Suggestions include renaming certain selectors for clarity and adding new ones to facilitate implementations of eltoo mechanisms and potentially redesign drivechains. This reflects an ongoing exploration of ways to refine and evolve Bitcoin scripting capabilities to support more sophisticated and secure transaction mechanisms, inviting further input and collaboration from the Bitcoin development community.