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

Posted by ZmnSCPxj

Oct 23, 2023/11:10 UTC

The email discusses an alternate design proposal for adding an nExpiryTime field in taproot annex. This field indicates that a transaction must not exist in a block at or above the specified height. The suggestion is to categorize transactions in the mempool into buckets based on their nExpiryTime, and if a block is reached, all buckets with nExpiryTime less than that block height should be dropped.

Additionally, the proposal suggests adding an OP_CHECKEXPIRYTIMEVERIFY opcode, which behaves similarly to the OP_EXPIRE opcode proposed by Peter Todd. The opcode checks if the nExpiryTime field exists and has a value equal to or less than the top of the stack. The main difference between this proposal and Peter's is that this proposal suggests an explicit field for nExpiryTime in the taproot annex, while Peter's proposal proposes an implicit field in CTransaction.

The author emphasizes that the use of explicit fields is preferable, as it makes the design more clear and easier to implement by non-Bitcoin-core implementations. The hope is that this approach will improve the implementation of the design across different implementations.

Overall, the email presents an alternative design for incorporating an nExpiryTime field and suggests using explicit fields for better implementation clarity.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback