[0/4] A Bitcoin Scripting Proposal BIP Quartet

This proposal is meticulously designed to enhance the flexibility and functionality of Tapscript v2 by introducing several new opcodes and reinstating functionalities previously disabled. Central to this enhancement is the creation of OP_TX, an opcode that significantly expands the scripting system's ability to introspect current transactions efficiently. By facilitating direct access to transaction data, OP_TX empowers scripts to execute a broader range of conditional spending scenarios autonomously, adhering to Bitcoin's foundational principle of minimizing reliance on trusted third parties.

The proposal outlines the introduction of additional opcodes such as OP_CHECKSIGFROMSTACK, OP_SEGMENT, OP_BYTEREV, OP_ECPOINTADD, OP_INTERNALKEY, and OP_MULTI. Each opcode serves a specific purpose in optimizing script functionality, ranging from improving the efficiency of signature verification with OP_TX and OP_SHA256 to enabling script composability and facilitating the construction of ordered Merkle trees and Taproot spends. Notably, OP_MULTI offers a novel approach to handling multiple inputs or outputs, simplifying transaction element management and potentially streamlining fee calculations. These enhancements are grounded in addressing the limitations of pre-Taproot Bitcoin scripting, aiming to restore and expand upon its capabilities for creating Taproot trees and supporting sophisticated script operations.

A key aspect of the draft is the introduction of a "varops budget," a concept evolved from the traditional "sigops budget" framework established by SegWit. This new budgeting model aims to provide a more comprehensive and flexible method for assessing script operation costs, focusing on stack data interactions. By establishing systematic cost evaluations based on worst-case behavior, the varops budget seeks to balance script execution efficiency with the need for expanded scripting capabilities. The proposal carefully details the cost model, emphasizing operand size over value and setting upper limits on script and stack object sizes to ensure performance reliability even under extreme conditions.

Moreover, the BIP proposes upgrading the tapleaf version to 0xc2, re-enabling functionalities disabled since version 0.3.1, and addressing the operational limitations imposed by prior restrictions. Key features of this upgrade include the restoration of previously disabled opcodes, an increase in the maximum stack object size, and modifications to support arbitrary-length arithmetic operations. These changes reflect a concerted effort to rejuvenate Bitcoin's scripting potential, aligning with the vision of a programmable monetary system free from third-party dependencies.

The development and refinement of these proposals are documented in a reference implementation, highlighting the collaborative nature of this initiative. Rusty and Julian's work underscores a significant milestone in Bitcoin scripting, aiming not only to restore its original capabilities but also to introduce innovative solutions that broaden its applicability. Their openness to community feedback and contributions signals a commitment to a participatory development process, inviting further discussion and input to shape the future of Bitcoin scripting.