[BIP Proposal] OP_TWEAKADD

In a recent discussion among Bitcoin developers, a few key technical points were raised regarding the evolution of Bitcoin Script and its implications for future protocol developments. One topic of debate was the decision to accept only x-only keys within a certain context, despite their current non-utilization in Bitcoin Script's execution environment. The rationale behind using x-only keys, specifically for Taproot output public keys, was questioned given their complexity and the lack of direct applicability within script operations. It was noted that earlier versions of the musig2 BIP had initially accepted x-only keys but later revisions shifted towards accepting normal compressed public keys for simplification purposes and to eliminate the need for one of the accumulator variables. This change was discussed in depth, with references made to the discussion that led to this amendment, highlighting the practical challenges and bugs encountered from the improper handling of x-only keys.

Another point of discussion focused on the handling of scalars greater than the curve order within Bitcoin's cryptographic operations. The suggestion was made to allow for modulo reduction of such scalars rather than outright failure. This approach would accommodate the direct use of hash outputs as scalar tweaks, despite the low probability of encountering a scalar greater than the curve order from a sha256 output. The potential for this to introduce a new form of witness malleability was acknowledged, yet it was questioned whether this remained a significant concern for developers, especially considering the advancements and changes in the Bitcoin network up to the year 2025.

The conversation also touched upon the proposed operational cost of a new op code in comparison to OP_CHECKSIG. The argument was made that the new op code, due to requiring an additional scalar base multiplication operation (excluding optimizations like the Strauss-Shamir trick), could justify a lower operational cost relative to OP_CHECKSIG. This perspective suggests a reevaluation of op code costs to better reflect the computational differences between these operations.

For further details on the discussions surrounding the acceptance of compressed public keys over x-only keys in the musig2 BIP, readers can refer to the documented conversation here.

These discussions underscore the ongoing technical deliberations within the Bitcoin development community aimed at refining and advancing the protocol. They reflect a collective effort to address complexities, optimize operations, and ensure the security and efficiency of Bitcoin scripting capabilities moving forward.