Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id B9FE1C000B for ; Fri, 11 Feb 2022 17:42:26 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id A848741637 for ; Fri, 11 Feb 2022 17:42:26 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rYo9TV68mcgO for ; Fri, 11 Feb 2022 17:42:25 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by smtp4.osuosl.org (Postfix) with ESMTPS id 898804162F for ; Fri, 11 Feb 2022 17:42:25 +0000 (UTC) Received: by mail-yb1-xb2f.google.com with SMTP id v47so27059825ybi.4 for ; Fri, 11 Feb 2022 09:42:25 -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; bh=ezWaZMN2F5nXsKjgTz0rLrTkWAcShI8GITFTy2D+tUs=; b=DqzfJl7PcgR2lhuE6IGkE7nCcZMLYwXAeVJRD8Vc7ATzUEx0lkC8GdoIxas76DPz7Z SDO4d8juuGpijwdu4XnhrGv/ugXZzELExelOhQCq74aRgLU8cqNVPYNAU94JczsWwCcx bAdT/XnkD+JTTpprK3/V9Fc5N+j9p+Nvj13lFndKbSLlFpA9PWU/HU0+B/Y7H7gejDza CVo7jOSxoN9Gh1ckmkNtO3NZAhBIxxOCkbRSdQmGlUUspdKoaP8A5ikqBsyKaoeXFQ7k J82TdC6pSAvwvHYmmzwxDuY/Ov9Ehac5csir2Pa7/que8o/9k9ALLbMZBhaQK1ori/eh b/SA== 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=ezWaZMN2F5nXsKjgTz0rLrTkWAcShI8GITFTy2D+tUs=; b=LT6gK9WZkeGH4V3V9dR45dZD3JXDo8BJ6dFAP3Fl/PFz7Kt51uGSPBgQstF3bNL9P/ nj5kRYnqsmbIt5o/nmTEt5z6peuUmr9M4AGHOxUdmjbYCihn5nf4qYhnwO3r6Ghcr9S7 IHvarohfaVwBMPYRTIaAXA+M65tRm2+wMz2EWAMSH/6r+S0SUyfEiOxniboVRAUMR7Zx QJIBoRXifBX3qtRtYVJ1f6vQsKZf5WWVr2Qqugb6VPYfYXnF6HCdE5iT/7IkXURl8MNq WNeJMr685CxUFvVgKn/vV43rb/L+p1N83sTS0QQ66zLEuPkog+BaNtFc2DXm3BcfVYhR g/eA== X-Gm-Message-State: AOAM530+6zsx0RVzvOcsOu3VKxgxCciLEfeqv8hzwkU8KUvyDJI8uhVE n5RzcdnRcyITOq8jtTZvBOHcSIIH5XOePIpeFmk= X-Google-Smtp-Source: ABdhPJxHcLF8839eE95GnOTVaqdlNJtC3QLndbdrA7nDU5fybDlnLRRwrvnVMgqSsdLPjypAqcPDAx4ZcOtzSH0SgLk= X-Received: by 2002:a81:4417:: with SMTP id r23mr2910795ywa.222.1644601344129; Fri, 11 Feb 2022 09:42:24 -0800 (PST) MIME-Version: 1.0 References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> In-Reply-To: <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> From: "James O'Beirne" Date: Fri, 11 Feb 2022 12:42:11 -0500 Message-ID: To: "David A. Harding" , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000e9ffd505d7c196a4" Subject: Re: [bitcoin-dev] Recursive covenant opposition, or the absence thereof, was Re: 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, 11 Feb 2022 17:42:26 -0000 --000000000000e9ffd505d7c196a4 Content-Type: text/plain; charset="UTF-8" I don't oppose recursive covenants per se, but in prior posts I have expressed uncertainty about proposals that enable more "featureful" covenants by adding more kinds of computation into bitcoin script. Not that anyone here is necessarily saying otherwise, but I am very interested in limiting operations in bitcoin script to "verification" (vs. "computation") to the extent practical, and instead encouraging general computation be done off-chain. This of course isn't a new observation and I think the last few years have been very successful to that effect, e.g. the popularity of the "scriptless scripts" idea and Taproot's emphasis on embedding computational artifacts in key tweaks. My (maybe unfounded?) worry about opcodes like OP_CAT and OP_TX is that more logic will live in script than is necessary, and so the burden to verify the chain may grow and the extra "degrees of freedom" in script may make it harder to reason about. But I guess at this point there aren't alternative means to construct new kinds of sighashes that are necessary for some interesting covenants. One thing I like about CTV is that it buys a lot of functionality without increasing the "surface area" of script's design. In general I think there is a lot to be said for this "jets"-style approach[0] of codifying the script operations that you'd actually want to do into single opcodes. This adds functionality while introducing minimal surface area to script, giving script implementers more flexibility for, say, optimization. But of course this comes at the cost of precluding experimentation, and probably requiring more soft-forking. Though whether the place for script experimentation using more general-purpose opcodes on the main chain is another interesting debate... Sorry for going a little off-topic there. [0]: https://medium.com/blockstream/simplicity-jets-release-803db10fd589 On Thu, Feb 10, 2022 at 7:55 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev > wrote: > > Whether [recursive covenants] is an issue or not precluding this sort > > of design or not, I defer to others. > > For reference, I believe the last time the merits of allowing recursive > covenants was discussed at length on this list[1], not a single person > replied to say that they were opposed to the idea. > > I would like to suggest that anyone opposed to recursive covenants speak > for themselves (if any intelligent such people exist). Citing the risk > of recursive covenants without presenting a credible argument for the > source of that risk feels to me like (at best) stop energy[2] and (at > worst) FUD. > > -Dave > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019203.html > [2] > http://radio-weblogs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html > (thanks to AJ who told me about stop energy one time when I was > producing it) > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000e9ffd505d7c196a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't oppose recursive covenants per se, but in= prior posts I have expressed uncertainty about proposals that enable more = "featureful" covenants by adding more kinds of computation into b= itcoin script.

Not that anyone here is necessarily= saying otherwise, but I am very interested in limiting operations in bitco= in script to "verification" (vs. "computation") to the = extent practical, and instead encouraging general computation be done off-c= hain. This of course isn't a new observation and I think the last few y= ears have been very successful to that effect, e.g. the popularity of the &= quot;scriptless scripts" idea and Taproot's emphasis on embedding = computational artifacts in key tweaks.

My (maybe u= nfounded?) worry about opcodes like OP_CAT and OP_TX is that more logic wil= l live in script than is necessary, and so the burden to verify the chain m= ay grow and the extra "degrees of freedom" in script may make it = harder to reason about. But I guess at this point there aren't alternat= ive means to construct new kinds of sighashes that are necessary for some i= nteresting covenants.

One thing I like about = CTV is that it buys a lot of functionality without increasing the "sur= face area" of script's design. In general I think there is a lot t= o be said for this "jets"-style approach[0] of codifying the scri= pt operations that you'd actually want to do into single opcodes. This = adds functionality while introducing minimal surface area to script, giving= script implementers more flexibility for, say, optimization. But of course= this comes at the cost of precluding experimentation, and probably requiri= ng more soft-forking. Though whether the place for script experimentation u= sing more general-purpose opcodes on the main chain is another interesting = debate...

Sorry for going a little off-topic there= .



On Thu, Feb 10, 2022 at 7:55= PM David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:=
On Mon, Feb 07,= 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Whether [recursive covenants] is an issue or not precluding this sort<= br> > of design or not, I defer to others.

For reference, I believe the last time the merits of allowing recursive
covenants was discussed at length on this list[1], not a single person
replied to say that they were opposed to the idea.

I would like to suggest that anyone opposed to recursive covenants speak for themselves (if any intelligent such people exist).=C2=A0 Citing the ris= k
of recursive covenants without presenting a credible argument for the
source of that risk feels to me like (at best) stop energy[2] and (at
worst) FUD.

-Dave

[1] https://lists.linux= foundation.org/pipermail/bitcoin-dev/2021-July/019203.html
[2] http://radio-weblo= gs.com/0107584/stories/2002/05/05/stopEnergyByDaveWiner.html
=C2=A0 =C2=A0 (thanks to AJ who told me about stop energy one time when I w= as
=C2=A0 =C2=A0 producing it)

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000e9ffd505d7c196a4--