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 DA82CC000B for ; Mon, 31 Jan 2022 02:19:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C8C8A4024E for ; Mon, 31 Jan 2022 02:19:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 TeDNTBJ1dfd6 for ; Mon, 31 Jan 2022 02:19:02 +0000 (UTC) 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 0886540236 for ; Mon, 31 Jan 2022 02:19:01 +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 1nEMHQ-0005rm-PN; Mon, 31 Jan 2022 12:18:58 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Mon, 31 Jan 2022 12:18:52 +1000 Date: Mon, 31 Jan 2022 12:18:52 +1000 From: Anthony Towns To: James O'Beirne , Bitcoin Protocol Discussion Message-ID: <20220131021852.GA4149@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: - Subject: Re: [bitcoin-dev] TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT 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, 31 Jan 2022 02:19:02 -0000 On Thu, Jan 27, 2022 at 07:18:54PM -0500, James O'Beirne via bitcoin-dev wrote: > > I don't think implementing a CTV opcode that we expect to largely be > > obsoleted by a TXHASH at a later date is yielding good value from a soft > > fork process. > Caching for something > like TXHASH looks to me like a whole different ballgame relative to CTV, > which has a single kind of hash. I don't think caching is a particular problem even for the plethora of flags Russell described: you cache each value upon use, and reuse that cached item if it's needed for other signatures within the tx; sharing with BIP 143, 341 or 342 signatures as appropriate. Once everything's cached, each signature then only requires hashing about 32*17+4 = ~548 bytes, and you're only hashing each part of the transaction once in order to satisfy every possible flag. > Even if we were to adopt something like TXHASH, how long is it going to > take to develop, test, and release? I think the work to release something like TXHASH is all in deciding: - if TXHASH or CTV or something else is the better "UX" - what is a good tx to message algorithm and how it should be parametized - what's an appropriate upgrade path for the TXHASH/CTV/??? mechanism BIP 119 provides one answer to each of those, but you still have to do the work to decide if its a *good* answer to each of them. > My guess is "a while" - If we want to get a good answer to those questions, it might be true that it takes a while; but even if we want to rush ahead with more of a "well, we're pretty sure it's not going to be a disaster" attitude, we can do that with TXHASH (almost) as easily as with CTV. > The utility of vaulting seems > underappreciated among consensus devs and it's something I'd like to write > about soon in a separate post. I think most of the opposition is just that support for CTV seems to be taking the form "something must be done; this is something, therefore it must be done"... I'd be more comfortable if the support looked more like "here are the alternatives to CTV, and here's the advantages and drawbacks for each, here's how they interact with other ideas, and here's why we think, on balance, we think this approach is the best one". But mostly the alternatives are dismissed with "this will take too long" or "this enables recursive covenants which someone (we don't know who) might oppose". Cheers, aj