Author: Anthony Towns 2021-07-12 05:01:15
Published on: 2021-07-12T05:01:15+00:00
In an email conversation between Jeremy and AJ on July 8, 2021, the two discussed the use of relative locktime and absolute locktime for the same input. While Jeremy believed that there was no use case for it, AJ argued that ruling it out would be suboptimal. However, he later realized that overloading the nSequence for a per-input absolute locktime could result in not being able to reuse the same input's nSequence for a per-input relative locktime. AJ then mentioned a use case for this scenario, which involves cut-through of PTLC refunds when the timeout expires well after the channel settlement delay has passed. He also discussed the concept of sequence tagged keys and suggested that sequencing restrictions should be obvious from some simple combination of nlocktime/nsequence/annex so that scripts/signatures don't have to be evaluated to determine if a transaction is final. Finally, AJ proposed a general principle where evaluating a script should only return one bit of information, "bool tx_is_invalid_script_failed," and all other details such as fees, finality of the transaction, validity in a chain fork, dependencies on other transactions, and fund distribution should be evident from a simple parsing of the transaction.
Updated on: 2023-05-23T15:21:56.644842+00:00