Author: Anthony Towns 2021-07-12 05:01:15
Published on: 2021-07-12T05:01:15+00:00
In an email exchange, Jeremy suggests disallowing the use of a relative locktime and an absolute locktime for the same input. However, the idea of ruling it out seems suboptimal according to AJ. AJ explains that if you overload nSequence for a per-input absolute locktime, then the same input's nSequence cannot be reused for a per-input relative locktime. AJ also mentions a use case for this scenario - cut-through of PTLC refunds when the timeout expires well after the channel settlement delay has passed. Jeremy asks about sequence tagged keys, to which AJ responds that sequencing restrictions should be obvious from some simple combination of nlocktime/nsequence/annex, so that one does not have to evaluate scripts/signatures in order to determine if a transaction is final. AJ proposes a more general principle where evaluating a script should only return one bit of information: "bool tx_is_invalid_script_failed," while every other bit of information should already be obvious from a "simple" parsing of the transaction.
Updated on: 2023-05-21T03:15:39.074177+00:00