Author: Jeremy 2021-07-12 22:07:29
Published on: 2021-07-12T22:07:29+00:00
The email exchange between Anthony Towns and Jeremy discusses the use of relative locktime and absolute locktime for the same input. While Jeremy argues that disallowing this seems suboptimal, Anthony points out that overloading nSequence for per-input absolute locktime would prevent reusing the same input's nSequence for per-input relative locktime. However, he later mentions a use case for such an approach in cut-through of PTLC refunds. The conversation then shifts to sequencing restrictions and evaluating scripts. Anthony suggests that sequencing restrictions should be obvious from a simple combination of nlocktime/nsequence/annex so that it isn't necessary to evaluate scripts/signatures to determine if a transaction is final. He proposes that evaluating a script should only return one bit of information - "bool tx_is_invalid_script_failed" - while all other information such as fee calculations, transaction finality, and chain fork validity should be apparent from a simple parsing of the transaction. Jeremy raises a concern that they don't currently have this property, and provides an example of a transaction with a scriptpubkey that utilizes CSV without any indication of its ability to be included without running the script. However, he acknowledges that having transactions with this property would be useful, but may not be practical. Finally, they briefly discuss sequence tagged keys which have the property of a transaction being either valid or invalid without any external information needed to be passed up.
Updated on: 2023-06-15T00:17:40.893762+00:00