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 ZmnSCPxj

Posted on: October 23, 2023 11:10 UTC

The email discusses an alternate design proposal for taproot annex.

The proposed design includes adding an nExpiryTime field in the taproot annex, which indicates that the transaction must not exist in a block at or above the specified height. The mempool should categorize transactions into buckets based on their nExpiryTime, and when a block is reached, all buckets with an nExpiryTime less than that block height should be dropped. Additionally, the proposal suggests adding an OP_CHECKEXPIRYTIMEVERIFY opcode, which checks if the nExpiryTime exists and has a value equal to or less than the top of the stack.

The primary difference between this proposal and the one suggested by Peter Todd is that while Peter's proposal introduces an implicit field for the value that OP_EXPIRE will put in CTransaction, this proposal suggests an explicit field for it in the taproot annex. The rationale behind this choice is that "explicit is better than implicit", and it is believed that non-Bitcoin-core implementations would be able to implement the design more effectively with the use of transaction buckets being explicitly treated in the nExpiryTime field.

Overall, the email presents an alternative design approach for taproot annex, highlighting the inclusion of an nExpiryTime field and an OP_CHECKEXPIRYTIMEVERIFY opcode, aiming for a more explicit and potentially better-implemented solution.