Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 10846C000B for ; Tue, 15 Feb 2022 18:57:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id F2DF782A0B for ; Tue, 15 Feb 2022 18:57:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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=gmail.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 7Iu7oxrIHhLp for ; Tue, 15 Feb 2022 18:57:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9AA6B80BB7 for ; Tue, 15 Feb 2022 18:57:48 +0000 (UTC) Received: by mail-lj1-x230.google.com with SMTP id o9so23272038ljq.4 for ; Tue, 15 Feb 2022 10:57:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAyXeYL3TRrQ9CIPCT0cdoBG/Gdctt/qhNX33wuMv1k=; b=VnSmG3+3jpc9Z9G7Y2cnmQeO4NKp/fFMeCAk3jq4IhfkbBQE2/qpME1ujdDXYxqid0 eDqPmvXvNuuV5kAyjYG2+U5KNSpB2vEi6Xp/yJZjGPkqOBVrTtV1MhDkNyPdkSEg+q25 p7LIxI2qUjk/bCQbyiI46YL/r9z1kIZSpKJ2sYKvQccQHF91ozyMgfuZK3cC0luoFn5Q Opu+O+q7Fu9m2bk747NtTqba1s8rCn8JuBvvKKgzPk6gEkO5b4brJ50SJmReGDpTKQqA GvxIF6h4PKgzkSZ/0T2aKa028y68OKXbROUqTIIrGwHF3HhHkDjUm56O4SF4jsVxw7o8 PqQA== 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=pAyXeYL3TRrQ9CIPCT0cdoBG/Gdctt/qhNX33wuMv1k=; b=pYYDH5mA0C8f//nz+mtMGjTT9GybondvE3Ef5UrkFcKSSWzzRIgiTWf1cBjzLgfDOS vbJPMsP1CjgpKhiy7qrAbRfw1H5Yf1MM5TlQWqigRdBc8v9sugGMTIm1sNrnDyuMQi1R DgNh94ohlNTvKWgxZlIMv3/hh7SwDLOTkaCVWwYk+O5bA5sJAbmCssYs2KIHSpBPMJB2 H+Dj2Hi5/RQ0I7XhLlmBqHqWcC+9nR1IlQsg5LQT/uR0/IAkGKXfnguf+Xs4UpfzWHd+ aqmuChP3dic0j12vet8b3qsr0cauUoLkb94GFY5c1iDUASBPkV+qojIvUyAEZ6AVO21l kibg== X-Gm-Message-State: AOAM532t4Vod4vGIyjO/9WP2jroMrxv3TK1RHCBoRnEmPQBfmityKR5B Thqy8pmT8FliiPhp28Yyxx5MUGR09v/noLc+wBk= X-Google-Smtp-Source: ABdhPJzUoXxT+NXVPXvryGB1U6X/3b9mR2UWgm9WYRhGtob18JUI7og5g9ZnvRIcaOkcf34AzyLtdLMCBwmGVc2D38k= X-Received: by 2002:a2e:9793:: with SMTP id y19mr270442lji.425.1644951466361; Tue, 15 Feb 2022 10:57:46 -0800 (PST) MIME-Version: 1.0 References: <87leymuiu8.fsf@rustcorp.com.au> <87k0dwr015.fsf@rustcorp.com.au> In-Reply-To: <87k0dwr015.fsf@rustcorp.com.au> From: Jeremy Rubin Date: Tue, 15 Feb 2022 10:57:35 -0800 Message-ID: To: Rusty Russell Content-Type: multipart/alternative; boundary="000000000000d3459805d8131b44" 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: Tue, 15 Feb 2022 18:57:50 -0000 --000000000000d3459805d8131b44 Content-Type: text/plain; charset="UTF-8" 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. I think for your point the inverse seems to hold: for the limited situations we might want to set up, CTV often ends up being sufficient because usually we can enumerate all the possible outcomes we'd like (or at least find a mapping onto such a construction). CTV is indeed very powerful, but as I demonstrated above, not powerful in the same way ("Complexity Class") that OP_TX or TXHASH might be. At the very least we should clearly understand *what* and *why* we are advocating for more sophisticated designs and have a thorough understanding of the protocol complexity we are motivated to introduce the expanded functionality. Further, if one advocates for TX/TXHASH on a featureful basis, it's at least a technical ACK on the functionality CTV is introducing (as it is a subset) and perhaps a disagreement on project management, which I think is worth noting. There is a very wide gap between "X is unsafe" and "I prefer Y which X is a subset of ''. I'll close by repeating : Whether that [the recursive/open ended properties] is an issue or not precluding this sort of design or not, I defer to others. Best, Jeremy Best, Jeremy -- @JeremyRubin On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell wrote: > Jeremy Rubin writes: > > Rusty, > > > > Note that this sort of design introduces recursive covenants similarly to > > how I described above. > > > > Whether that is an issue or not precluding this sort of design or not, I > > defer to others. > > Good point! > > But I think it's a distinction without meaning: AFAICT iterative > covenants are possible with OP_CTV and just as powerful, though > technically finite. I can constrain the next 100M spends, for > example: if I insist on those each having incrementing nLocktime, > that's effectively forever. > > Thanks! > Rusty. > --000000000000d3459805d8131b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Rusty,

Please see my post in the other=C2=A0email thread= =C2=A0https://lists= .linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html

The differences in this regard are several, and worth understanding bey= ond "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 actio= n in any order requires factorially many pre-computations, not just linear = or constant. For reference, 24! is about 2**80. Whereas for a more interpre= tive 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 e= numerated: 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 a= ble to expand to a-priori
3) Combinin= g 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 a= re. E.g., Output 0 matches Input 0, Output 1 matches Output 2.

I thin= k for your point the inverse seems to hold: for the limited situations we m= ight want to set up, CTV often ends up being sufficient because usually we = can enumerate all the possible outcomes we'd like (or at least find a m= apping onto such a construction). CTV is indeed very powerful, but as I dem= onstrated above, not powerful in the same way ("Complexity Class"= ) that OP_TX or TXHASH might be.
<= br>
At the very least we should clear= ly understand what=C2=A0and why=C2=A0we are advocating for mo= re sophisticated designs and have a thorough understanding of the protocol = complexity we are motivated to introduce the expanded functionality.=C2=A0F= urther, if one advocates for TX/TXHASH on a featureful basis, it's at l= east a technical ACK on the functionality CTV is introducing (as it is a su= bset) and perhaps a disagreement on project management, which I think is wo= rth noting. There is a very wide gap between "X is unsafe" and &q= uot;I prefer Y which X is a subset of ''.

I'll close by repeating : Whether that [the recursive/ope= n ended properties] is an issue or not precluding this sort of design or no= t, I defer to others.

Best,

Jeremy




<= /div>
Best,

Jeremy


On Tue, Feb 15, 2022= at 12:46 AM Rusty Russell <rusty@rustcorp.com.au> wrote:
<= /div>
Jeremy Rubin <jeremy.l.rubin@gmail.com&g= t; writes:
> Rusty,
>
> Note that this sort of design introduces recursive covenants similarly= to
> how I described above.
>
> Whether that is an issue or not precluding this sort of design or not,= I
> defer to others.

Good point!

But I think it's a distinction without meaning: AFAICT iterative
covenants are possible with OP_CTV and just as powerful, though
technically finite.=C2=A0 I can constrain the next 100M spends, for
example: if I insist on those each having incrementing nLocktime,
that's effectively forever.

Thanks!
Rusty.
--000000000000d3459805d8131b44--