From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 2B830C000E; Thu, 8 Jul 2021 08:44:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 187AC402A8; Thu, 8 Jul 2021 08:44:28 +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 HiRZoKaELPiE; Thu, 8 Jul 2021 08:44: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 ABC9240271; Thu, 8 Jul 2021 08:44:26 +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 1m1Pdt-0002rL-8j; Thu, 08 Jul 2021 18:44:23 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 08 Jul 2021 18:44:16 +1000 Date: Thu, 8 Jul 2021 18:44:16 +1000 From: Anthony Towns To: Jeremy , Bitcoin Protocol Discussion Message-ID: <20210708084416.GB1339@erisian.com.au> References: 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: lightning-dev Subject: Re: [bitcoin-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: Thu, 08 Jul 2021 08:44:28 -0000 On Wed, Jul 07, 2021 at 06:00:20PM -0700, Jeremy via bitcoin-dev wrote: > This means that you're overloading the CLTV clause, which means it's impossible > to use Eltoo and use a absolute lock time, It's already impossible to simultaneously spend two inputs if one requires a locktime specified by mediantime and the other by block height. Having per-input locktimes would satisfy both concerns. > 1) Define a new CSV type (e.g. define (1<<31 && 1<<30) as being dedicated to > eltoo sequences). This has the benefit of giving a per input sequence, but the > drawback of using a CSV bit. Because there's only 1 CSV per input, this > technique cannot be used with a sequence tag. 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. Adding a per-input absolute locktime to the annex is what I've had in mind. That could also be used to cheaply add a commitment to an historical block hash (eg "the block at height 650,000 ended in cc6a") in order to disambiguate which branch of a chain split or reorg your tx is valid for. Cheers, aj