Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 48CDFC000B for ; Wed, 16 Feb 2022 04:10:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 22D9240154 for ; Wed, 16 Feb 2022 04:10:33 +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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=blockstream-com.20210112.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9RfzDuggnm4 for ; Wed, 16 Feb 2022 04:10:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by smtp2.osuosl.org (Postfix) with ESMTPS id 8D9D84010E for ; Wed, 16 Feb 2022 04:10:31 +0000 (UTC) Received: by mail-qt1-x835.google.com with SMTP id x5so968900qtw.10 for ; Tue, 15 Feb 2022 20:10:31 -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=1B+P4Tqvusqq09myjyArp4VCoy7juVeKJSrg7CaUcOA=; b=jMC3XLzjB5MsGsHKw5pPZMMhcMhAnirICjaYqGgJhOcEMpS4jYFdUvEbdthhhh19HG 4I7pOsuoVTgVMB9oLKdgAoRvtMAP9FCc/fGTgAtRKXLLT2Qqd8Dy/tQSFs8owkKbC+/A HpXSga/ZApgyx/+QywG3NhrqqkTV09hSHbwBmCUg7luql6P9FgftMhwvl/g2y0fYLSqZ AQdOBSNE+6t8eEw9mbpgCqjBLOYrLPwLIhKwsQ71efJFsbLTEuXFlMY3dKt5C3G2i8/d /vszjmerJWJ82pIWuGPFiV8RxaN1Y95B+jJBmZodhsD/7nw0Pc/xsCUYFRn7PGubROcR pkmw== 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=1B+P4Tqvusqq09myjyArp4VCoy7juVeKJSrg7CaUcOA=; b=XW/ArXGFfoeSrIrFin9ODxBMBRbJGCigPq6fvuAaQe12l+PBoNBV7OWcRUxJ2Q8CEH 6g9QpM5DeJ3sGoDb77RfwbQTW99fSluVXbaiSfEy0oTpTuPU2R9frS8z1kWLqjNAme8S bJ/HL/nSkehjyQSQPnEOe4DzAPjurY0G4tbIPCV2SEmR35tpKVtXmoQwEoTkDggmr3im Ms7kPD2RHcV9iKVeQaKQs0NaxI3Ce9Jfh16yHuY+uPJiv9Gz5nMXhgfqaoj4AZEGI5eS 2MkAixYmp3YKf1+AiAKsvh5QwKbaB1nkk6Mdt1u7BtJn/qnDwaLDY9v37hqZ4h54krGI 2d5w== X-Gm-Message-State: AOAM5326RWED4OcBkkomXe++jZS729wLXZ7lyllMAh8VVBFtYNZjlFra vmRZEHYialxnuB5u9cBsVzux4Mv+NZ2lL144BQ9+IdpOA4Q= X-Google-Smtp-Source: ABdhPJyTahjbMqDR0aJDu8WeZ7aTTgOqLOCNn+AGCt8a9Ws0PY5UAHmx2BZ+YEJGrTwkxZL/KaZ/GSma2RFLuhOmJPo= X-Received: by 2002:a05:622a:592:b0:2dc:ed48:7a54 with SMTP id c18-20020a05622a059200b002dced487a54mr683141qtb.289.1644984630246; Tue, 15 Feb 2022 20:10:30 -0800 (PST) MIME-Version: 1.0 References: <87leymuiu8.fsf@rustcorp.com.au> <87k0dwr015.fsf@rustcorp.com.au> <87a6err1h5.fsf@rustcorp.com.au> In-Reply-To: <87a6err1h5.fsf@rustcorp.com.au> From: "Russell O'Connor" Date: Tue, 15 Feb 2022 23:10:19 -0500 Message-ID: To: Rusty Russell Content-Type: multipart/alternative; boundary="0000000000008c1a8905d81ad4c4" 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: Wed, 16 Feb 2022 04:10:33 -0000 --0000000000008c1a8905d81ad4c4 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell wrote: > Jeremy Rubin writes: > > Hi Rusty, > > > > Please see my post in the other email thread > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html > > > > The differences in this regard are several, and worth understanding > beyond > > "you can iterate CTV". I'd note a few clear examples for showing that > "CTV > > is just as powerful" is not a valid claim: > > > > 1) CTV requires the contract to be fully enumerated and is non-recursive. > > For example, a simple contract that allows n participants to take an > action > > in any order requires factorially many pre-computations, not just linear > or > > constant. For reference, 24! is about 2**80. Whereas for a more > > interpretive covenant -- which is often introduced with the features for > > recursion -- you can compute the programs for these addresses in constant > > time. > > 2) CTV requires the contract to be fully enumerated: For example, a > simple > > contract one could write is "Output 0 script matches Output 1", and the > set > > of outcomes is again unbounded a-priori. With CTV you need to know the > set > > of pairs you'd like to be able to expand to a-priori > > 3) Combining 1 and 2, you could imagine recursing on an open-ended thing > > like creating many identical outputs over time but not constraining what > > those outputs are. E.g., Output 0 matches Input 0, Output 1 matches > Output > > 2. > > Oh agreed. It was distinction of "recursive" vs "not recursive" which > was less useful in this context. > > "limited to complete enumeration" is the more useful distinction: it's a > bright line between CTV and TXHASH IMHO. > If TXHASH is limited to requiring the flags be included in the hash (as is done with sighash) I believe TXHASH has the same "up front" nature that CTV has. --0000000000008c1a8905d81ad4c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 15, 2022 at 10:45 PM Rusty Russell <rusty@rustcorp.com.au> wrote:
Jeremy Rubin <jeremy.l.rubin@gmail.com> writes:
> Hi Rusty,
>
> Please see my post in the other email thread
> https://lists.= linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html
>
> The differences in this regard are several, and worth understanding be= yond
> "you can iterate CTV". I'd note a few clear examples for= showing that "CTV
> is just as powerful" is not a valid claim:
>
> 1) CTV requires the contract to be fully enumerated and is non-recursi= ve.
> For example, a simple contract that allows n participants to take an a= ction
> in any order requires factorially many pre-computations, not just line= ar or
> constant. For reference, 24! is about 2**80. Whereas for a more
> interpretive covenant -- which is often introduced with the features f= or
> recursion -- you can compute the programs for these addresses in const= ant
> time.
> 2) CTV requires the contract to be fully enumerated: For example, a si= mple
> contract one could write is "Output 0 script matches Output 1&quo= t;, and the set
> of outcomes is again unbounded a-priori. With CTV you need to know the= set
> of pairs you'd like to be able to expand to a-priori
> 3) Combining 1 and 2, you could imagine recursing on an open-ended thi= ng
> like creating many identical outputs over time but not constraining wh= at
> those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Ou= tput
> 2.

Oh agreed.=C2=A0 It was distinction of "recursive" vs "not r= ecursive" which
was less useful in this context.

"limited to complete enumeration" is the more useful distinction:= it's a
bright line between CTV and TXHASH IMHO.

If TXHASH is limited to requiring the flags be included in the hash (as i= s done with sighash) I believe TXHASH has the same "up front" nat= ure that CTV has.
--0000000000008c1a8905d81ad4c4--