[0/4] A Bitcoin Scripting Proposal BIP Quartet

This blog post delves into a recent Bitcoin Improvement Proposal (BIP) draft introduced by Rusty Russell, focusing on the introduction of several new opcodes for Tapscript v2. The proposed enhancements aim to leverage scripting improvements and covenant facilities offered by OP_TX, addressing the restoration of opcodes and introspection capabilities to make script more versatile. This expansion is believed to not only enhance current functionalities but also pave the way for future optimizations through a more rounded scripting language.

The draft outlines a series of opcodes such as OP_CHECKSIGFROMSTACK, which essentially acts as a subset of OP_CHECKSIG but is designed specifically for checking a signature against a hash on the stack. This functionality is crucial for the efficient operation of CHECKSIG with OP_TX and OP_SHA256. Another notable inclusion is OP_SEGMENT, an opcode that remains a NOP but introduces the concept of script composability. It allows scripts to be appended without the immediate success triggered by OP_SUCCESS, enabling a transaction to ensure certain conditions are met while allowing for additional script conditions.

OP_BYTEREV and OP_ECPOINTADD are introduced as minimal requirements for the construction of ordered Merkle trees and Taproot spends, respectively. These additions address the directional discrepancy in hash comparisons and provide essential capabilities for Taproot constructions within script. Furthermore, the proposal includes OP_INTERNALKEY to optimize space usage for unspendable keypaths in Taproot, suggesting potential for further efficiency improvements in future versions.

A significant aspect of the proposal is the OP_MULTI opcode, which introduces a method to handle multiple inputs or outputs without introducing complex iteration into script. By prefixing this opcode, it allows subsequent opcodes to operate on more operands than usual, simplifying the handling of transaction elements like fee calculations.

The rationale behind these proposed opcodes stems from the limitations observed in Bitcoin script developed before the conception of Taproot. The draft highlights the necessity of these opcodes for creating Taproot trees in script and underscores the importance of generic introspection into transactions for arbitrary signature coverage and partial spending requirements. The proposal marks a milestone in Bitcoin scripting, shifting future opcode proposals towards optimizations that can be quantitatively assessed based on their impact on onchain space and overall implementation costs.

As of now, the draft awaits further input on potential missing fundamental building blocks, considerations for OP_INTERNALKEY as a possible OP_TX selector bit, and discussions on the ambition level of OP_MULTI. The absence of a reference implementation and detailed specifications signals an ongoing development phase, inviting feedback and suggestions from the Bitcoin development community.