bitcoin-dev

OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely

Original Postby Peter Todd

Posted on: October 21, 2023 00:09 UTC

The email discusses a problem related to the spendability of the HTLC-timeout path and the HTLC-preimage path.

The issue is that after the HTLC-timeout path becomes spendable, the HTLC-preimage path remains spendable as well, which is not desired. The goal is to attach urgency to spending the HTLC-preimage to ensure it happens before the previous HTLC-timeout is mined.The email suggests introducing the concept of expiring the HTLC-preimage path. Traditionally, transactions are designed to remain valid forever to prevent them from becoming impossible to mine in the event of a large reorganization. However, the email proposes using OP_Expire and the Coinbase Bit soft-fork upgrade to make the HTLC-preimage path expire. By redefining a bit of the nVersion field, similar to how coinbase outputs work in Bitcoin, the outputs of such transactions would only become spendable after 100 more blocks have been mined. This approach ensures compatibility with existing nodes in a soft-fork upgrade.OP_Expire is introduced as an opcode that terminates script evaluation with an error under certain conditions. It requires the Coinbase Bit to be set and prevents a txout from being spent in a particular way. The reorg security of transactions using OP_Expire is no worse than transactions spending miner coinbases.The email also explains how HTLCs (Hashed Time Lock Contracts) would use OP_Expire. Whenever revealing the preimage on-chain is necessary for the secure functioning of the HTLC-using protocol, an appropriate OP_Expire is added to the pre-image branch of the script. This sets a deadline for the party receiving the preimage to get a transaction spending the preimage mined. If they fail to do so in time, control reverts to the other party who can spend the HTLC output without strict time constraints.Additionally, the email mentions the possibility of encoding the expiration height as a delta against a block-height nLockTime, instead of using a specific Coinbase Bit. In this variant, OP_Expire would check that the absolute expiration height is met.Overall, the email proposes solutions to address the problem of spendability in HTLC paths by introducing OP_Expire and the Coinbase Bit soft-fork upgrade or using delta encoding for expiration heights. These approaches ensure compatibility with existing nodes and provide a way to enforce time constraints for certain transactions.