From aj at erisian.com.au Thu Jul 8 08:44:16 2021 From: aj at erisian.com.au (Anthony Towns) Date: Thu, 8 Jul 2021 18:44:16 +1000 Subject: [Lightning-dev] [bitcoin-dev] Eltoo / Anyprevout & Baked in Sequences In-Reply-To: References: Message-ID: <20210708084416.GB1339@erisian.com.au> 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