[0/4] A Bitcoin Scripting Proposal BIP Quartet

This BIP proposes a significant upgrade to the Bitcoin script capabilities, reinstating functionalities that were disabled in version 0.3.1 due to security concerns. The proposal introduces a new tapleaf version (0xc2) that restores pre-0.3.1 script functions and enhances the scripting language to accommodate modern use cases without compromising the network's integrity. The key features of this upgrade include the re-enabling of previously disabled opcodes, an increase in the maximum stack object size to 4,000,000 bytes, and an extension of the total stack byte limit to 8,000,000 bytes. Additionally, the maximum number of stack objects is raised to 32,768, while numerical values are no longer restricted to 32 bits and are treated as unsigned.

The motivation behind these changes stems from the limitations imposed on Bitcoin's scripting since version 0.3.1, which aimed to mitigate vulnerabilities related to excessive computational time and memory usage. These restrictions curtailed the ability to define precise spending conditions, diverging from the vision of programmable money without reliance on third parties. By increasing operational capabilities and limits within a taproot leaf with version 0xc2, this BIP seeks to revive the full potential of Bitcoin scripting.

For execution, specific rules are outlined to ensure scripts do not exceed allocated budgets for computational resources, with validation failing under conditions such as surpassing the varops budget or exceeding stack element size limits. The rationale for these rules includes the necessity of limiting memory usage to prevent denial-of-service attacks and accommodating potential use cases like including entire transactions on the stack.

Several opcodes are redefined or reintroduced, altering their behavior to read and write numbers in a more flexible manner, reflecting changes in how arithmetic and bit operations are handled. This includes adjustments to opcodes for checking lock time and sequence verifies, alongside modifications to arithmetic opcodes to support variable-length unsigned integers. The document details the re-enabling of fifteen opcodes removed in earlier versions and provides comprehensive explanations for the rationale behind these decisions, focusing on ensuring the system's integrity while expanding its capabilities.

The proposal also considers the computational complexity of certain operations, introducing varops costs for newly enabled or modified opcodes to maintain equilibrium between functionality and resource consumption. Notably, it places restrictions on hashing opcodes and revises the costs associated with various operations to reflect their impact on the network's performance.

In conclusion, this BIP signifies a pivotal evolution in Bitcoin scripting, aiming to restore and enhance the system's flexibility and capability. By carefully balancing improvements with safeguards against abuse, it proposes a framework that could significantly broaden the scope of possible applications on the Bitcoin network. The ongoing development of this proposal is documented in a reference implementation, signifying an active effort to refine and implement these changes. The initiative has garnered support and contributions from multiple individuals, underscoring its significance and the collaborative effort driving its progress.