bitcoin-dev
OP_Expire and Coinbase-Like Behavior: Making HTLCs Safer by Letting Transactions Expire Safely
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.