A Taproot-native (re-)bindable transaction bundle proposal

In the realm of Bitcoin development, the intricacies of using OP_SIZE with Schnorr signatures versus its application in Pay to Witness Script Hash (P2WSH) contexts reveal significant differences in the effectiveness of demonstrating Proof of Work (PoW). Specifically, employing OP_SIZE directly with Schnorr signatures does not adequately expose the PoW behind it. This limitation is contrasted by the enhanced functionality observed when OP_SIZE is applied within P2WSH environments, where the smaller DER signature necessitates a higher amount of PoW. This distinction underscores the necessity for developers aiming to incorporate PoW alongside any conditions to pivot towards using P2WSH or revert to older, albeit non-standard, methodologies.

The dialogue extends into the potential resolution of these issues through the introduction of new opcodes such as OP_CAT. However, this solution is met with caution due to the possibility of enabling a broader spectrum of use cases that might introduce unforeseen side effects, including the implementation of BIP-300 or BIP-301 without necessitating an additional soft fork.

Further examination of Bitcoin's scripting capabilities highlights a nuanced discussion around the use of OP_CHECKMULTISIG in comparison to Taproot's OP_CHECKSIGADD. The former allows all signatures to sign the same z-value, which is beneficial when ECDSA serves as a 256-bit calculator. This utility remains vital even under the hypothetical scenario where secp256k1 is compromised, provided that OP_CHECKMULTISIG is not disabled. In contrast, Taproot introduces OP_CHECKSIGADD, making it considerably more challenging to enforce the same z-value across different signatures.

An exploration into legacy scripts unveils a peculiar method involving the transfer of coins from random Pay to Public Key (P2PK) outputs with out-of-bounds SIGHASH_SINGLE from known public keys with undisclosed private keys. This maneuver, however, faces limitations within the P2WSH framework due to the inability to control the z-value by the spender in a feasible manner. Additionally, the complexity increases with the realization that chaining different sighashes, particularly when transactions within the input can change, poses a risk of invalidating subsequent signatures in the chain. This is especially problematic in scenarios attempting to create a sequence of one-input-one-output signatures utilizing SIGHASH_SINGLE with ANYONECANPAY, as any alteration to an input or output within the chain results in the immediate invalidation of all following signatures.