Taking a second look at OP_EXPIRE

The recent discourse surrounding Bitcoin's development has seen a notable proposition: the introduction of an expiration date for transactions through a specific opcode, tentatively named OP_EXPIRE. This concept aims to address issues beyond just mitigating replace-cycling attacks associated with the Lightning Network (LN), suggesting a broader utility that remains underexplored within the community. Information about this opcode and its potential applications can be found in discussions on protocol design at Delving Bitcoin.

The inspiration for OP_EXPIRE arose from examining the implementation of coinswap on Bitcoin, as detailed in a project on GitHub (citadel-tech/coinswap). This implementation represents the first onchain BTC to BTC atomic swap, utilizing multisignature schemes (musigs) and Hashed Timelock Contracts (HTLCs) to facilitate coin swaps. However, a significant inefficiency was identified in the necessity of a final transaction by all participants to ensure security against potential theft via HTLCs. The rationale is that if HTLCs were not required, the new UTXO owner would already possess all necessary information for spending, thereby eliminating one transaction in the process. This aspect underscores the critical need for minimizing blockchain transactions to ensure a sustainable future for Bitcoin, particularly in maintaining a high network hash rate through adequate transaction fees.

OP_EXPIRE could potentially streamline contracts involving swaps and private key handovers by reducing the number of transactions required. Moreover, the opcode's functionality could extend to various other use cases when combined with other opcodes such as OP_CSFS and OP_CTV. For instance, it enables time-restricted delegations, contracts based on real-time data (e.g., prices or exchange rates confirmed by oracles), short-term approvals by owners or associated entities, and applications in voting or elections with specified time constraints for consensus. Such versatility demonstrates OP_EXPIRE's capacity to enhance contract and Layer 2 application designs significantly.

The proposed operation of OP_EXPIRE involves popping the top value on the stack, which represents the expiration block or time, and then assessing whether the UTXO has expired. Its implementation could allow for signed expiration heights/deltas on the stack, facilitating a wide range of contractual agreements and operations in conjunction with OP_CSFS, such as creating ephemeral key pairs for time-bound delegations.

Despite its potential benefits, the adoption of OP_EXPIRE carries certain trust assumptions and possible drawbacks, including the risk of funds being permanently lost due to untimely revocation transactions or manipulation by miners in a centralized mining context. These concerns highlight the need for careful consideration and community feedback on the opcode's design and implications.

In conclusion, the introduction of OP_EXPIRE into Bitcoin's script could offer significant improvements in transaction efficiency and contract flexibility. By addressing the current limitations and exploring its integration with existing opcodes, there lies a promising avenue for enhancing Bitcoin's functionality and ensuring its long-term viability.