Author: Jeremy 2021-07-12 22:07:29
Published on: 2021-07-12T22:07:29+00:00
In an email conversation between Anthony Towns and Jeremy on July 11, 2021, they discussed the use of a relative locktime and an absolute locktime for the same input in Bitcoin transactions. There was a disagreement over whether it should be disallowed or not. Towns suggested that using nSequence for a per-input absolute locktime would prevent reusing the same input's nSequence for a per-input relative locktime. He also mentioned a possible use case for this: cut-through of PTLC refunds when the timeout expires well after the channel settlement delay has passed. However, Jeremy clarified that he meant disallowing a relative locktime and a sequence locktime. The conversation then moved on to the topic of sequence tagged keys and sequencing restrictions. Towns shared his opinion that sequencing restrictions should be obvious from some simple combination of nlocktime/nsequence/annex so that one doesn't have to evaluate scripts/signatures to determine if a transaction is final. He proposed a general principle that evaluating a script should only return one bit of info: "bool tx_is_invalid_script_failed," while all other information should already be obvious from a "simple" parsing of the transaction. Jeremy pointed out that they don't currently have this property in Bitcoin transactions. He gave an example of a transaction that cannot be included without running the script and argued that although it is a useful property, it may not be practical. They both agreed that sequence tagged keys have the property of a transaction being either valid or invalid, which never changes without any external information needing to be passed up. Finally, they expressed their desire to separate all locktime types per input to get rid of all weirdness/overlap.
Updated on: 2023-06-03T05:04:31.727849+00:00