From jlrubin at mit.edu Mon Jul 12 22:07:29 2021 From: jlrubin at mit.edu (Jeremy) Date: Mon, 12 Jul 2021 15:07:29 -0700 Subject: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences In-Reply-To: <20210712050115.GA6250@erisian.com.au> References: <20210708084416.GB1339@erisian.com.au> <20210712050115.GA6250@erisian.com.au> Message-ID: 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: