From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 474EBC000E; Mon, 12 Jul 2021 05:01:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2F85D403FE; Mon, 12 Jul 2021 05:01:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGmvzj9H-23U; Mon, 12 Jul 2021 05:01:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp4.osuosl.org (Postfix) with ESMTPS id F3601403FC; Mon, 12 Jul 2021 05:01:25 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1m2o4G-0005Nb-01; Mon, 12 Jul 2021 15:01:22 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 12 Jul 2021 15:01:15 +1000 Date: Mon, 12 Jul 2021 15:01:15 +1000 From: Anthony Towns To: Jeremy Message-ID: <20210712050115.GA6250@erisian.com.au> References: <20210708084416.GB1339@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Score-int: -18 X-Spam-Bar: - Cc: Bitcoin Protocol Discussion , lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Eltoo / Anyprevout & Baked in Sequences X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2021 05:01:27 -0000 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) > 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