Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 45B5DC000B for ; Sat, 29 Jan 2022 17:14:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 2613B4088B for ; Sat, 29 Jan 2022 17:14:57 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com 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 38yFRAP1ZabN for ; Sat, 29 Jan 2022 17:14:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) by smtp4.osuosl.org (Postfix) with ESMTPS id 4E67440889 for ; Sat, 29 Jan 2022 17:14:56 +0000 (UTC) Received: by mail-qt1-x829.google.com with SMTP id y17so7848079qtx.9 for ; Sat, 29 Jan 2022 09:14:56 -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 :cc; bh=ERYL/RP5Z7fDhcvTs9TjmWwT+FSWx1VxYw4kYL0KM/4=; b=ewJzzVpKwUTuzrrLn1KwtQzCmnRuxAcX59eFn6Z6gRcbsrrA8FzEfKPe3T9ndE77Tj 6k7ySf2vCA7g/5dQwK8XmhWBPNFVoK50e7SCd4QTLiRvKSy+TG9Z5MO3TVng2+YPdM4N bFYByr73GiCzPWZ+ig5sc/b2HaJTBPBJJKk8Q/cmlc39KPcecR3MgpYDayPYXHpe/DI+ QL6k6wV10gbT5Y/3l+0alG0ks4GIZa2KAGGJKJVmv0MPqvmkehruSusZk8pTr2+PaXyQ CQ+OPVKvCuJRqaFlA4btJS/VIzlyB0bxAzvhXpx3T0CptIGKECIDlS6ADTphmyc8AHZd 6biA== 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:cc; bh=ERYL/RP5Z7fDhcvTs9TjmWwT+FSWx1VxYw4kYL0KM/4=; b=TdBJRNr+zJFRPIpLef8CZ3wh4b4pCpDAFA0c3mSRGsSkUaHyfI/vc5LDA4cw/vbeSN SVub0r/wTMZLyspiP+nE+6ygZD3xi0DrtfbZ3cp0rfHjsb52DPE8UXMWDtb7E2ZYnpwA gSfTZNNB0PkxYoqkZN19ZJICY/gDCEAS+nd6EvVI4jbvkGfbWZkq/mYArkefGizpyDNl U8jTOPzgEjD1R+erOLnO1bFPB+QlokMiEaM85U0eQpnSgIGRe/psP9wSI5NQGJ1Kk9qS an5a/pwFIUROW+aWbsJr3XKMIQV57V0Nc7xfwiib1VamyPBOeBBEE2x95qD0ahDIjwkK fMBA== X-Gm-Message-State: AOAM531FMjEi0QLyAikOIx7CBZKLReHW0wUopGYyTBUF4Z7KrvfEDJgF kYt6dl7531wXuu9CUOY8C1M7DBTdFT1+DE0bL15gtA== X-Google-Smtp-Source: ABdhPJwMvqAH4i1JlLQ5GEW8/FA5lgTuEwjuIpwxiI4v6ONn4p9p+Gha/1DYlxzY5Er0J9HTzVn6o6mXCvq4XqrfPdE= X-Received: by 2002:a05:622a:5ce:: with SMTP id d14mr9884890qtb.642.1643476495115; Sat, 29 Jan 2022 09:14:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "Russell O'Connor" Date: Sat, 29 Jan 2022 12:14:43 -0500 Message-ID: To: Jeremy Rubin Content-Type: multipart/alternative; boundary="000000000000b042f005d6bbb006" Cc: Bitcoin Protocol Discussion 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: Sat, 29 Jan 2022 17:14:57 -0000 --000000000000b042f005d6bbb006 Content-Type: text/plain; charset="UTF-8" The hash would normally also cover the hash flags in use, and would be different in those two cases. But yes, it seems at the last minute I did include a suggestion to disable covering the flag themselves in the hash and appear to have accidentally allowed for recursive covenants (a common occurrence when designing opcodes). On Sat, Jan 29, 2022 at 12:01 PM Jeremy Rubin wrote: > > > >> Perhaps there is some misunderstanding. TXHASH + CSFSV doesn't allow for >> complex or recursive covenants. Typically CAT is needed, at minimum, to >> create those sorts of things. TXHASH still amounts to deploying a >> non-recursive covenant construction. >> >> > This seems false to me. > > txhash scriptpubkey> txhash equalverify > > Is that not a recursive covenant? With a little extra work you can also > control for amounts and stuff. > > > >> --000000000000b042f005d6bbb006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The hash would normally also cover the has= h flags in use, and would be different in those two cases.

But yes, it seems at the last minute I did include a suggestion to= disable covering the flag themselves in the hash and appear to have accide= ntally allowed for recursive covenants (a common occurrence when designing = opcodes).

On Sat, Jan 29, 2022 at 12:01 PM Jeremy Rubin <j@rubin.io> wrote:
=
=


<= div class=3D"gmail_quote">

Perhaps th= ere is some misunderstanding.=C2=A0 TXHASH=C2=A0+ CSFSV doesn't allow f= or complex or recursive covenants.=C2=A0 Typically CAT is needed, at minimu= m, to create those sorts of things.=C2=A0 TXHASH still amounts to deploying= a non-recursive covenant construction.

=
<= div class=3D"gmail_quote">
<= div dir=3D"auto">
This seems false to me.=C2=A0<= /div>

<Only hash a single i= nput scriptpubkey> txhash <only hash a single output scriptpubkey>= txhash equalverify

Is t= hat not a recursive covenant? With a little extra work you can also control= for amounts and stuff.

=
<= div>
--000000000000b042f005d6bbb006--