Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ACFEEC000B for ; Fri, 28 Jan 2022 14:13:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 9C36281D65 for ; Fri, 28 Jan 2022 14:13:25 +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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rYJAJMYG-L15 for ; Fri, 28 Jan 2022 14:13:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8BF2681D5A for ; Fri, 28 Jan 2022 14:13:24 +0000 (UTC) Received: by mail-qk1-x72a.google.com with SMTP id b35so5090821qkp.6 for ; Fri, 28 Jan 2022 06:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=WBdp/EqTVK9bD9gTebZz0v8YF4CI7Urjmnb9lxVPanU=; b=2OphYNQ2xr4z8jO3L5nFJ+aD48aDdp1PVoKzloDoGDTLmh1bRPLMc8Y0eAlvgZmlyK vj5uXdVvaUZ+KcHDY1jlwL0K73qANQpFbMzpopheCRWvX5RQgP3RranQl+AsSFPZeHyz cw8bPfXQyk4OOCsWnZ4QvCLwaDUIRP6GeXTsHVPXFwM3E7pcWo1sUe+w5PW5us+MJ8m7 VGnPIroCCsdQ5QhNcYeqNMXF0YR1k/FSL/1nBWgwXq3XmulL+EQ3snmp+K5s0GPF+YnN K/EYzCsDYndhBjovjZ84CThYHyaAhIJHdvaudWhuweNbH2NyC8QYSJT7AF8VDRyIW25L JKvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=WBdp/EqTVK9bD9gTebZz0v8YF4CI7Urjmnb9lxVPanU=; b=QEq1wFMsThlLcPnXY42Urk+RTDYEx18IP22StL3ZqyiUS3DZ9Mv1PtjrJSY53rdSSR sSZ0PlOtnD1qQ8KoWLqvg+a6atmiNabtgZucfLjAzlcqe7W3O5mrAN8xLasQjZNzfSy9 vHylAFr5bpevMncEpR8kmCTDL+9gNwDaSxPp4q7D3Ghpo7xIDfAN72Ij6L0vEyao5Bye h3h5Lh/dCttqNjVvCt8oAJclcfLYerG4aZrYmSsVWHhPOPhUvOWGQ6M1133l4X4azoQG WMdBEaOOUUFzpCrTmYbRQwiqWSkZdRlAt3rRXor5NaJmsi87+wjoswY0f7St6lt2sxGR t6Ig== X-Gm-Message-State: AOAM530s974XRFIZv+qyaSGMN3FrtoLmohWCI/13LYWjQ7jb2+tHah4G 5q/3QWAcTSdet4DBadfqiDfXuqXmfXOjB7gb88Pkd55/is+9+Q== X-Google-Smtp-Source: ABdhPJy4s/OW0VEFZXY4h6WT/20KEWexB/3h4T2D3x4gp33wfspoMIw4u428yL5HaqQ78hryMR+0hW60exXIzy72Kbk= X-Received: by 2002:a37:9f86:: with SMTP id i128mr5892973qke.640.1643379203124; Fri, 28 Jan 2022 06:13:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Fri, 28 Jan 2022 09:13:11 -0500 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a24a4505d6a50954" 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: Fri, 28 Jan 2022 14:13:25 -0000 --000000000000a24a4505d6a50954 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne 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. > > This presumes the eventual adoption of TXHASH (or something like it). > You're presenting a novel idea that, as far as I know, hasn't had much time > to bake in public. Like Jeremy, I'm concerned by the combinatorial growth > of flags and the implications that has for testing. Caching for something > like TXHASH looks to me like a whole different ballgame relative to CTV, > which has a single kind of hash. > Let's not overstate the concern around the combinatorics of TXHASH. It's not like there is a vast amount of cross-flag interaction we are talking about here. There are also a combinatorial number of ways of assembling opcodes in Bitcoin script, but we aren't required to exhaustively test every single possible Script program. > Even if we were to adopt something like TXHASH, how long is it going to > take to develop, test, and release? My guess is "a while" - in the > meantime, users of Bitcoin are without a vault strategy that doesn't > require either presigning transactions with ephemeral keys (operationally > difficult) or multisig configurations that would make Rube Goldberg blush > (operationally difficult and precarious). The utility of vaulting seems > underappreciated among consensus devs and it's something I'd like to write > about soon in a separate post. > > > The strongest argument I can make in favour of CTV would be something > like: "We definitely want bare CTV and if we are going to add CTV to legacy > script (since we cannot use TXHASH in legacy script), then it is actually > easier not to exclude it from tapscript, even if we plan to add TXHASH to > tapscript as well." > > Another argument for CTV (which I find especially persuasive) is its > simplicity - it's relatively easy to reason about and, at this point, > pretty well understood. It seems like a low-risk change relative to some of > the other covenant proposals, nearly all of which elicit a good deal of > headscratching (at least from me) and seem to require not only larger > on-chain footprints but sizable code changes. > > > I am sensitive to technical debt and soft fork processes > > If OP_CTV ends up being the most practical approach for vaulting - among > other things - in terms of weight (which it seems to be at the moment) I > don't think "technical debt" is an applicable term. > Technical debt isn't a measure of weight of transactions. It's a measure of the code complexity needed to implement, in this case, a Bitcoin Script interpreter. By itself, adding a single new hash format for CTV isn't that complex, and it is certainly simpler than this TXHASH proposal. But then we need to add another two slightly different hash formats for APO support. And tomorrow we will need yet another set of transaction hash formats for the next thing, and so on, with each instance requiring going through its own soft-fork process. It is at that point we end up with something more complicated and with more deployment risk than if we had just done something like TXHASH at the very beginning. But unlike other programming environments, we cannot refactor our way out of such a situation. We cannot make a new script version while deprecating the old one. Our only option here is to be mindful of the long term implications of the design choices we are making today. --000000000000a24a4505d6a50954 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Jan 27, 2022 at 7:19 PM James O'Beirne <james.obeirne@gma= il.com> wrote:
> I don'= ;t think implementing a CTV opcode that we expect to largely=20 be obsoleted by a TXHASH at a later date is yielding good value from a=20 soft fork process.

This presumes the = eventual adoption of TXHASH (or something like it). You're presenting a= novel idea that, as far as I know, hasn't had much time to bake in pub= lic. Like Jeremy, I'm concerned by the combinatorial growth of flags an= d the implications that has for testing. Caching for something like TXHASH = looks to me like a whole different ballgame relative to CTV, which has a si= ngle kind of hash.

Let= 's not overstate the concern around the combinatorics=20 of TXHASH. =C2=A0 It's not like there is a vast amount of cross-flag in= teraction we are talking about here.=C2=A0 There are also a combinatorial n= umber of ways of assembling=20 opcodes in Bitcoin script, but we aren't required to exhaustively test = every single possible Script program.
=C2=A0
Even if we were to a= dopt something like TXHASH, how long is it going to take to develop, test, = and release? My guess is "a while" - in the meantime, users of Bi= tcoin are without a vault strategy that doesn't require either presigni= ng transactions with ephemeral keys (operationally difficult) or multisig c= onfigurations that would make Rube Goldberg blush (operationally difficult = and precarious). The utility of vaulting seems underappreciated among conse= nsus devs and it's something I'd like to write about soon in a sepa= rate post.

> The strongest= argument I can make in favour of CTV would be something=20 like: "We definitely want bare CTV and if we are going to add CTV to= =20 legacy script (since we cannot use TXHASH in legacy script), then it is=20 actually easier not to exclude it from tapscript, even if we plan to add TXHASH to tapscript as well."

Another argume= nt for CTV (which I find especially persuasive) is its simplicity - it'= s relatively easy to reason about and, at this point, pretty well understoo= d. It seems like a low-risk change relative to some of the other covenant p= roposals, nearly all of which elicit a good deal of headscratching (at leas= t from me) and seem to require not only larger on-chain footprints but siza= ble code changes.
=C2=A0
<= div>> I am sensitive to technical debt and soft fork=C2=A0processes

If OP_CTV ends up be= ing the most practical approach for vaulting - among other things - in term= s of weight (which it seems to be at the moment) I don't think "te= chnical debt" is an applicable term.

Technical debt isn't a measure of weight of transa= ctions.=C2=A0 It's a measure of the code complexity needed to implement= , in this case, a Bitcoin Script interpreter.

By i= tself, adding a single new hash format for CTV isn't that complex, and = it is certainly simpler than this TXHASH proposal.=C2=A0 But then we need t= o add another two slightly different hash formats for APO support.=C2=A0 An= d tomorrow we will need yet another set of transaction hash formats for the= next thing, and so on, with each instance requiring going through its own = soft-fork process.=C2=A0 It is at that point we end up with something more = complicated and with more deployment risk than if we had just done somethin= g like TXHASH at the very beginning.=C2=A0 But unlike other programming env= ironments, we cannot refactor our way out of such a situation.=C2=A0 We can= not make a new script version while deprecating the old one.=C2=A0 Our only= option here is to be mindful of the long term implications of the design c= hoices we are making today.
--000000000000a24a4505d6a50954--