Published on: 2021-07-14T03:32:00+00:00
In a recent email exchange, Jeremy suggested that evaluating a script should only return one piece of information: "bool tx_is_invalid_script_failed." He argued that all other information, such as transaction fees, finality, and chain fork validity, should be obvious from parsing the transaction. However, he admitted that Bitcoin currently doesn't have this property. Jeremy provided an example of a transaction that will never be valid because it fails a specific rule from BIP 112. He also mentioned that transactions with timelocks can transition from invalid to valid once they pass a certain block height, but once they become invalid, they cannot become valid again for a given UTXO.The email exchange between Anthony Towns and Jeremy discussed the use of relative locktime and absolute locktime for the same input. Jeremy suggested disallowing this, but Anthony pointed out that overloading nSequence for per-input absolute locktime would prevent reusing it for per-input relative locktime. However, Anthony later mentioned a use case for this scenario in cut-through of PTLC refunds. The conversation then shifted to sequencing restrictions and evaluating scripts. Anthony proposed that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex, without needing to evaluate scripts or signatures to determine transaction finality. He suggested that evaluating a script should only return one bit of information, while other information like fee calculations and chain fork validity should be apparent from simple parsing of the transaction. Jeremy raised concerns about not having this property currently, but acknowledged its usefulness. They also briefly discussed sequence tagged keys, which have the property of a transaction being either valid or invalid without external information.In another email exchange, Jeremy suggested disallowing the use of both relative locktime and absolute locktime for the same input. However, AJ disagreed, considering ruling it out completely suboptimal. AJ explained that if nSequence is overloaded for per-input absolute locktime, it cannot be reused for per-input relative locktime. AJ also mentioned a use case for this scenario in cut-through of PTLC refunds when the timeout expires after the channel settlement delay. Jeremy asked about sequence tagged keys, and AJ responded that sequencing restrictions should be evident from a combination of nlocktime, nsequence, and annex. AJ proposed that evaluating a script should only return one bit of information, while other information should already be obvious from simple parsing of the transaction.The discussion seems to focus on disallowing the use of both relative locktime and absolute locktime for the same input. However, it is considered suboptimal to completely rule it out. The conversation also touches on sequence tagged keys and seeks opinions on them.In a recent Bitcoin-dev discussion, it was noted that overloading the CLTV clause makes it impossible to use Eltoo and an absolute lock time. It is also not possible to spend two inputs simultaneously if one requires a locktime specified by mediantime and the other by block height. A potential solution suggested was defining a new CSV type, but this would disallow using both relative locktime and absolute locktime for the same input. Instead, adding a per-input absolute locktime to the annex was proposed, which could also be used to add a commitment to a historical block hash to determine valid branches of chain splits or reorgs. Overall, there seems to be agreement that per-input locktimes would be beneficial and address multiple concerns.In a comment on Github, the author discussed the appropriateness of using anyprevout. They noted limitations and overloading issues when using it for eltoo. The author suggested options, including defining a new CSV type and creating a sequenced signature, to better support the eltoo use case. They also considered defining a new generic place for lock times in the annex. The author favored option 3 as it seemed closest to supporting Eltoo more effectively.
Updated on: 2023-08-02T04:22:56.125373+00:00