On Sun, Jul 11, 2021 at 10:01 PM Anthony Towns wrote: > On Thu, Jul 08, 2021 at 08:48:14AM -0700, Jeremy wrote: > > This would disallow using a relative locktime and an absolute > locktime > > for the same input. I don't think I've seen a use case for that so > far, > > but ruling it out seems suboptimal. > > I think you meant disallowing a relative locktime and a sequence > locktime? I > > agree it is suboptimal. > > No? If you overload the nSequence for a per-input absolute locktime > (well in the past for eltoo), then you can't reuse the same input's > nSequence for a per-input relative locktime (ie CSV). > > Apparently I have thought of a use for it now -- cut-through of PTLC > refunds when the timeout expires well after the channel settlement delay > has passed. (You want a signature that's valid after a relative locktime > of the delay and after the absolute timeout) > Ah -- I didn't mean a per input abs locktime, I mean the tx global locktime. I agree that at some point we should just separate all locktime types per input so we get rid of all weirdness/overlap. > > > What do you make of sequence tagged keys? > > I think we want sequencing restrictions to be obvious from some (simple) > combination of nlocktime/nsequence/annex so that you don't have to > evaluate scripts/signatures in order to determine if a transaction > is final. > > Perhaps there's a more general principle -- evaluating a script should > only return one bit of info: "bool tx_is_invalid_script_failed"; every > other bit of information -- how much is paid in fees (cf ethereum gas > calculations), when the tx is final, if the tx is only valid in some > chain fork, if other txs have to have already been mined / can't have > been mined, who loses funds and who gets funds, etc... -- should already > be obvious from a "simple" parsing of the tx. > > Cheers, > aj > > I don't think we have this property as is. E.g. consider the transaction: TX: locktime: None sequence: 100 scriptpubkey: 101 CSV How will you tell it is able to be included without running the script? I agree this is a useful property, but I don't think we can do it practically. What's nice is the transaction in this form cannot go from invalid to valid -- once invalid it is always invalid for a given UTXO. sequence tagged keys have this property -- a txn is either valid or invalid and that never changes w/o any external information needing to be passed up.