path: root/f7/0dd0310b1144b0f4e08596c90a80609aee4e31

Delivery-date: Tue, 04 Mar 2025 23:48:32 -0800
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC22FLMMY4FRBRMDUC7AMGQEZZ6BZ6Q@googlegroups.com>)
	id 1tpjUU-0007Ki-Jo
	for bitcoindev@gnusha.org; Tue, 04 Mar 2025 23:48:32 -0800
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e5798866415sf13347871276.1
        for <bitcoindev@gnusha.org>; Tue, 04 Mar 2025 23:48:30 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741160904; cv=pass;
        d=google.com; s=arc-20240605;
        b=EhFBBiK4BNEpcNvT9brrK2lkCQEObPslaweZ0xp2l06xscbT+sy/HxzsDwvc8BVWAz
         r+RaDn45gAUAVI//AMfTM81NZogcVy5Rsue2xtJtqxDk90Kaa9hBrH7bQul+4VvEsGKl
         XOMzdTXqQ6q1dPtZBDO1p22nX+wJhNHDqs4X1PLpKmTZDlS52WZuovMf6B+X8c/iTxyo
         DxMcKMG2cLK1UVKYXyzOT41bdhKZRrr94gUVir7Uq1sDmWaMq6sDNXNuNo/KbLtcd8BO
         2TgpwQdVzsLIkVGJ5oWWELWmat9YeARyDvb4EfmALp84PoUu8hhghD2JoynaAshnUViu
         qaaA==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=Jq2l26wWhHNmxky4Zf4GFmTU2taqEFOmK4w32ncPXCQ=;
        fh=lPqziaDs5kVlMGCItVTHUMvxSI8G5q1kBms6NdNi44E=;
        b=O4+iLAzHK4eNva1zRTxZMFMkoFtBFAuF7LY57xyAilY8Ay20RFlA8q5JQRGo6Lhc4d
         Znfnmt0iiqHZlu8hfqOqC1CbR6DvOjJxDHP97zC8gZ7fa3mxZODsmbBju+BZUsPmHnie
         KdD+s6K6p5ViIpHoNvhAQher/crVxAjSMty49BmQczbDIUDzFTcfhJubsIe4JR6W0kUV
         HZgRBmpEOboN4HxGJi300I/hWNQKPqqXoyiw8WIRQGEzXLDKVDs3WAaKtBid6xURSO9g
         veHAUacf3O8M7pnt6LfRL5nhbJK+gokiPbjKf7gdPC9pMpFPt6ABes+xYThZLiQj0nD2
         wWqA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=GznCDc2O;
       spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) smtp.mailfrom=laolu32@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741160904; x=1741765704; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=Jq2l26wWhHNmxky4Zf4GFmTU2taqEFOmK4w32ncPXCQ=;
        b=en3reIVMYaRdiNG1kAdab+Z01Sj2YEWhoRu57xUa2TYfJAD+AtQIr3RcTxL5hlc+xl
         Eih1aJtZ7zuzr8Jp/7ZH0BqgBoUEpHIsANqEkLScN1ir8deI5r3XjhddXNACJUCv1fty
         8zlevGZtiUKODKSooXqG0j2AL/aMEcRr7Hl/rRDb6y9nOQmvbBthL5/wu7fQwoJsNnPI
         Oq9CDSmeyQqfikRNnq66Rq3kRilZOuQcFjR37mcRhTS0rPmShhCOiwizvcU0HBk9ACoV
         2G4ariDc1vtAttMy2Nz8oKU5p4ZSSesiv+5N7kLixay4qb5Cma8y6GdBbEj3nGZKUt8A
         wgmw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741160904; x=1741765704; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=Jq2l26wWhHNmxky4Zf4GFmTU2taqEFOmK4w32ncPXCQ=;
        b=HcMrzLxSwHUwel7quKBvWnt6rbIm25IE0rLFcflT8ehttwNsf6F9AhxXV/Ss3MjkkC
         SmUuv/CNgPjJpQzOShOrNhRH2MSLjS3WFJYu/JS5GfDP7fDNiBZjIp9FtT3TydJFcY9a
         t6y02eEsTtuC7jSrMUWfb88IlH9+qNAztG9VXYEiWBYyJ9/w3VyGApx5pcbFaGsrM3vf
         DyQfTRiG5t5SfqfcON+DZm8NFTbA0lS4LKmjgnXQXLlm9T55w/M6UTfBQOzYP7zTERhv
         iPxFoHC4Euk5zPYFAYF71vawSjLz61qmHIG7mMKLQEbFL/I5FVrG5HnYAlZPGywENP9i
         q/Ew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741160904; x=1741765704;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=Jq2l26wWhHNmxky4Zf4GFmTU2taqEFOmK4w32ncPXCQ=;
        b=imLbcGi/yrh7Fi+uAwL0els5no1b8NVJkopJU/L0ooGLTv1ly5bgmrJ5VpNDJY2+b7
         o3PeKb7zN5vKUCqyDwhGXZmcJyyP1ka7q3D00I0IdCRutR8fbkAgzzQO+kt9gOxXjPYS
         j6AfCj6BDF8+xZxI5HtY+tlZ068eqtA4vD+TE/Qsw1M/2rEKsSNdXGQ2tolGbKKZGK8N
         mlckZFzNezCCG7V2cfnvi+H2B8gjjYmbDeEuHZiHcnKQMQQx/Uq1EVBr/at+No+lczRP
         7XIETFbxnAy1iFfhHBma2JyS1x2jhSaV/zBwIhA+EKqTK22TAZN9ToV85DGvp7pUCnmn
         L0hw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXaluLwGSXXZu5sK0HW3SfqyElX0fpp9meHLnu0VyT4SpGx2BKO+Trg31edJ34KGrR257RvI4r7+tJU@gnusha.org
X-Gm-Message-State: AOJu0YwS+JJL6Ix+cWCoYX4IRB6gPOr5QWC+pvH3fH8+U1tjou2XxUTg
	fl9gCf20PZ90lvZEJ80e0mNFiZ1H474CqaaNnEksFtrpJhmDQlOS
X-Google-Smtp-Source: AGHT+IHkbWgoshVr0LWAxpkUQAbqVOBDCKaHTiViZExZNdGT8S1RHGYRQQWU65a4yj7cAdTP6Qi+RQ==
X-Received: by 2002:a05:6902:230f:b0:e5b:12a3:1ed2 with SMTP id 3f1490d57ef6-e611e31bec0mr2791219276.33.1741160904420;
        Tue, 04 Mar 2025 23:48:24 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVGlOMugPI9bQ190149vhGPlYx0kFf8bN9HnXI+nypPWWA==
Received: by 2002:a25:ab26:0:b0:e5e:109d:3123 with SMTP id 3f1490d57ef6-e609ef3e73els412743276.0.-pod-prod-02-us;
 Tue, 04 Mar 2025 23:48:21 -0800 (PST)
X-Received: by 2002:a05:690c:3388:b0:6f9:7920:e813 with SMTP id 00721157ae682-6fda2f08f6dmr30067727b3.4.1741160900930;
        Tue, 04 Mar 2025 23:48:20 -0800 (PST)
Received: by 2002:a05:690c:4787:b0:6fd:27d2:c7f1 with SMTP id 00721157ae682-6fda2a21eedms7b3;
        Tue, 4 Mar 2025 22:15:11 -0800 (PST)
X-Received: by 2002:a05:690c:6008:b0:6fd:6748:928a with SMTP id 00721157ae682-6fda3027cccmr27814457b3.29.1741155310869;
        Tue, 04 Mar 2025 22:15:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741155310; cv=none;
        d=google.com; s=arc-20240605;
        b=RgTKa4uCdS0y+I38hG5qckAhs55GfJVrJcm9fwGWNBjzq+AS9rFNGE+NKJzGe1Wr2T
         dqSMD8mF6blUcqbPVJcjnkTPz49nHvHbhEI6a+YNznucLI9vP7I/fqad1sAS6pJaoj9S
         p9PmfUoISSXH6mXOtL1EdsRQoN3sl1udQgkEcf3T3qDGhqcEQmcve27TPNZP2YRWNVDm
         k45mRrpK4rLe3KqoHFFiqQb0IsE6MI/dpJmfX6LwMRQsjBX9KwxJPFd+KsQ+4ifiaBmU
         q62C1I19ZZ1IkjCiA8l7SDIIGCf3xTUBItpI1vPFCSd66Viqp//GRNqMv4sCMRgnS8z8
         hwzQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=QbycKbhgkOMbu7rnjLRaT9FxHXy3j6hAJi8nHET6+2E=;
        fh=ZhIePvtzD2qBgm9PadABf9spV2moFvlPRwwE8o08T1o=;
        b=dlXG9UlHMMYsZ0QzjpMqbvV5UD1ijQ0dc2cXkvuibyCbEyr+wz1z4tmLGUV0yvvKST
         o086evd51qB5byI5rjtVqW0SwEEmxBqaW+CVyYUTV60unCzoCVsQTGJ1DR6CiKba5QOj
         2FirD6L6P4a3JvMfadg6xlMRuKe2LmNxLAcdwaJN4WWGAc2Xh/XQ459IpwOB0iRu4ynZ
         t/4M7ClG+WCGMVUipFfKYg8NQyFzx6Fqx/UahfrbAmHGJda8hcXwzIkuq80nWiXBK0ex
         HCsj4f/nIxwmHzmWIjkggyEPm37nJUmd/pXClaO7heUG+60YC6alvJv7EX1pctfgjsY4
         msWQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=GznCDc2O;
       spf=pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) smtp.mailfrom=laolu32@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com. [2607:f8b0:4864:20::112d])
        by gmr-mx.google.com with ESMTPS id 00721157ae682-6fd3cb71fb0si5960947b3.4.2025.03.04.22.15.10
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 04 Mar 2025 22:15:10 -0800 (PST)
Received-SPF: pass (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112d as permitted sender) client-ip=2607:f8b0:4864:20::112d;
Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-6f6ae4846c7so57468717b3.1
        for <bitcoindev@googlegroups.com>; Tue, 04 Mar 2025 22:15:10 -0800 (PST)
X-Gm-Gg: ASbGncuNzocQRi3Sc32Zoy7kv9zXZ+dAge+oE/h1aOo5zHP9AC5uEMUY65x+Phfij8Y
	2T4fm7NDPWt14MfJzvrB9LGtpa1WPZmVQgYqCcbvyOOwUfySjdmGlUQ0ZUoqty9LqWf06vqvHcK
	Kmc8/HzBqJ/9xp/bSamIiwBkS2ZC0=
X-Received: by 2002:a05:690c:4909:b0:6fb:3b2b:e73e with SMTP id
 00721157ae682-6fda2f4ebc5mr27247137b3.14.1741155310392; Tue, 04 Mar 2025
 22:15:10 -0800 (PST)
MIME-Version: 1.0
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
In-Reply-To: <Z8eUQCfCWjdivIzn@erisian.com.au>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Tue, 4 Mar 2025 22:14:59 -0800
X-Gm-Features: AQ5f1JrPLG8-93-D3XSBkuSO1f__0PlvLojbrycaJt_fsEO6PqwaPT-Syikwkh4
Message-ID: <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
To: Anthony Towns <aj@erisian.com.au>
Cc: bitcoindev@googlegroups.com
Content-Type: multipart/alternative; boundary="000000000000c664c4062f924fc5"
X-Original-Sender: laolu32@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=GznCDc2O;       spf=pass
 (google.com: domain of laolu32@gmail.com designates 2607:f8b0:4864:20::112d
 as permitted sender) smtp.mailfrom=laolu32@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

--000000000000c664c4062f924fc5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi AJ,

First a standard disclaimer: the contents of this email shouldn't be
interpreted as an endorsement of one covenants proposal over another.

> Since BIP 119's motivation is entirely concerned with its concept of
> covenants and avoiding what it calls recursive covenants

If we look at the motivation section of BIP 119, we find this sentence:

> This BIP introduces a simple covenant called a *template* which enables a
> limited set of highly valuable use cases without significant risk. BIP-11=
9
> templates allow for non-recursive fully-enumerated covenants with no
> dynamic state.

You appear to have latched onto the "non-recursive" aspect, ignoring the
subsequent qualifiers of "fully-enumerated" and "with no dynamic state".

The example that you've come up with to "directly undermine" the claimed
motivations of BIP 119 is still fully enumerated (the sole state is declare=
d
up front), and doesn't contain dynamic state (I can't spend the contract on
chain and do something like swap in another hash H, or signature S).

> I found it pretty inconvenient, which I don't think is a good indication
> of ecosystem readiness wrt deployment. (For me, the two components that
> are annoying is doing complicated taproot script path spends, and
> calculating CTV hashes)

What language/libraries did you use to produce the spend? In my own
development tooling of choice, producing complicated taproot script path
spends is pretty straight forward, so perhaps the inconvenience you ran int=
o
says more about your dev tooling than the ecosystem readiness.

It's also worth pointing out that your example relies on private key
deletion, which if deemed acceptable, can be used to emulate CTV as is toda=
y
(though you can't create a self-referential loop that way afaict).

> For me, the bllsh/simplicity approach makes more sense as a design
> approach for the long term

Simplicity certainly has some brilliant devs working on it, but after all
these years it still seems to be struggling to exit research mode with some
"killer apps" on Liquid.

bllsh on the other hand is a very new (and cool!) project that has no
development uptake beyond its creator. Given its nascent state, it seems
rather premature to promote it as a long term solution.

Both of them are effectively a complete rewrite of Script, so compared to
some of the existing covenant proposals on the table (many of which have a
small core code footprint in the interpreter), they represent a radically
expanded scope (ecosystem changes, wallets, consensus code) and therefore
additional risks. The current Overton Window appears to be focused on a
small (LoC wise) package to enable a greater degree of permissionless
innovation on Bitcoin, while leaving the research landscape open for more
dramatic overhauls (bllsh/Simplicity) in the future.

-- Laolu


On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns <aj@erisian.com.au> wr=
ote:

> Hello world,
>
> Some people on twitter are apparently proposing the near-term activation =
of
> CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
>
>  https://x.com/JeremyRubin/status/1895676912401252588
>  https://x.com/lopp/status/1895837290209161358
>  https://x.com/stevenroose3/status/1895881757288996914
>  https://x.com/reardencode/status/1871343039123452340
>  https://x.com/sethforprivacy/status/1895814836535378055
>
> Since BIP 119's motivation is entirely concerned with its concept of
> covenants and avoiding what it calls recursive covenants, I think it
> is interesting to note that the combination of CSFS and CTV trivially
> enables the construction of a "recursive covenant" as BIP 119 uses those
> terms. One approach is as follows:
>
>  * Make a throwaway BIP340 private key X with 32-bit public key P.
>  * Calculate the tapscript "OP_OVER <P> OP_CSFS OP_VERIFY OP_CTV", and
>    its corresponding scriptPubKey K when combined with P as the internal
> public
>    key.
>  * Calculate the CTV hash corresponding to a payment of some specific
> value V
>    to K; call this hash H
>  * Calculate the BIP 340 signature for message H with private key X, call
> it S.
>  * Discard the private key X
>  * Funds sent to K can only be spent by the witness data "<H> <S>" that
> forwards
>    an amount V straight back to K.
>
> Here's a demonstration on mutinynet:
>
>
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy=
jejrmqqx525gsk5nr58
>
> I'd encourage people to try implementing that themselves with their
> preferred tooling; personally, I found it pretty inconvenient, which I
> don't think is a good indication of ecosystem readiness wrt deployment.
> (For me, the two components that are annoying is doing complicated
> taproot script path spends, and calculating CTV hashes)
>
> I don't believe the existence of a construction like this poses any
> problems in practice, however if there is going to be a push to activate
> BIP 119 in parallel with features that directly undermine its claimed
> motivation, then it would presumably be sensible to at least update
> the BIP text to describe a motivation that would actually be achieved by
> deployment.
>
> Personally, I think BIP 119's motivation remains very misguided:
>
>  - the things it describes are, in general, not "covenants" [0]
>  - the thing it avoids is not "recursion" but unbounded recursion
>  - avoiding unbounded recursion is not very interesting when arbitrarily
>    large recursion is still possible [1]
>  - despite claiming that "covenants have historically been widely
>    considering to be unfit for Bitcoin", no evidence for this claim has
>    been able to be provided [2,3]
>  - the opposition to unbounded recursion seems to me to either mostly
>    or entirely be misplaced fear of things that are already possible in
>    bitcoin and easily avoided by people who want to avoid it, eg [4]
>
> so, at least personally, I think almost any update to BIP 119's motivatio=
n
> section would be an improvement...
>
> [0]
> https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/
> [1] https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/
> [2]
> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2=
-4a82b580ba99-000000@email.amazonses.com/
> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> [4] https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au=
/
>
> Beyond being a toy example of a conflict with BIP 119's motivation
> section, I think the above script could be useful in the context of the
> "blind-merged-mining" component of spacechains [5]. For example, if
> the commitment was to two outputs, one the recursive step and the other
> being a 0sat ephemeral anchor, then the spend of the ephemeral anchor
> would allow for both providing fees conveniently and for encoding the
> spacechain block's commitment; competing spacechain miners would then
> just be rbf'ing that spend with the parent spacechain update remaining
> unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would
> need to be used to ensure the "one spacechain update per bitcoin block"
> rule. (I believe mutinynet doesn't support ephemeral anchors however, so
> I don't think there's anywhere this can be tested)
>
> [5]
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file=
-bmm-svg
>
> (For a spacechain, miners would want to be confident that the private key
> has been discarded. This confidence could be enhanced by creating X as a
> musig2 key by a federation, in which case provided any of the private key=
s
> used in generating X were correctly discarded, then everything is fine,
> but that's still a trust assumption. Simple introspection opcodes would
> work far better for this use case, both removing the trust assumption
> and reducing the onchain data required)
>
> If you're providing CTV and CSFS anyway, I don't see why you wouldn't
> provide the same or similar functionality via a SIGHASH flag so that you
> can avoid specifying the hash directly when you're signing it anyway,
> giving an ANYPREVOUT/NOINPUT-like feature directly.
>
> (Likewise, I don't see why you'd want to activate CAT on mainnet without
> also at least re-enabling SUBSTR, and potentially also the redundant
> LEFT and RIGHT operations)
>
> For comparison, bllsh [6,7] takes the approach of providing
> "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but
> for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV
> equivalent would then either involve simplying writing:
>
>    (=3D (bip342_txmsg 3) 0x.....)
>
> meaining "calculate the message hash of the current tx for SIGHASH_SINGLE=
,
> then evaluate whether the result is exactly equal to this constant"
> providing one of the standard sighashes worked for your use case, or
> replacing the bip342_txmsg opcode with a custom calculation of the tx
> hash, along the lines of the example reimplementation of bip342_txmsg
> for SIGHASH_ALL [8] in the probably more likely case that it didn't. If
> someone wants to write up the BIP 119 hashing formula in bllsh, I'd
> be happy to include that as an example; I think it should be a pretty
> straightforward conversion from the test-tx example.
>
> If bllsh were live today (eg on either signet or mainnet), and it were
> desired to softfork in a more optimised implementation of either CTV or
> ANYPREVOUT to replace people coding their own implementation in bllsh
> directly, both would simply involve replacing calls to "bip342_txmsg"
> with calls to a new hash calculation opcode. For CTV behaviour, usage
> would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO behaviour,
> usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That
> is, the underlying "I want to hash a message in such-and-such a way"
> looks the same, and how it's used is the wallet author's decision,
> not a matter of how the consensus code is written.
>
> I believe simplicity/simfony can be thought of in much the same way;
> with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour
> [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like
> behaviour [10].
>
> [6] https://github.com/ajtowns/bllsh/
> [7] https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224
> [8] https://github.com/ajtowns/bllsh/blob/master/examples/test-tx
> [9]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.=
simf
> [10]
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.s=
imf
>
> For me, the bllsh/simplicity approach makes more sense as a design
> approach for the long term, and the ongoing lack of examples of killer
> apps demonstrating big wins from limited slices of new functionality
> leaves me completely unexcited about rushing something in the short term.
> Having a flood of use cases that don't work out when looked into isn't
> a good replacement for a single compelling use case that does.
>
> Cheers,
> aj
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.c=
om.au
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com.

--000000000000c664c4062f924fc5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi AJ,<br><br>First a standard disclaimer: the conten=
ts of this email shouldn&#39;t be<br>interpreted as an endorsement of one c=
ovenants proposal over another.<br><br>&gt; Since BIP 119&#39;s motivation =
is entirely concerned with its concept of<br>&gt; covenants and avoiding wh=
at it calls recursive covenants<br><br>If we look at the motivation section=
 of BIP 119, we find this sentence: <br><br>&gt; This BIP introduces a simp=
le covenant called a *template* which enables a<br>&gt; limited set of high=
ly valuable use cases without significant risk. BIP-119<br>&gt; templates a=
llow for non-recursive fully-enumerated covenants with no<br>&gt; dynamic s=
tate. <br><br>You appear to have latched onto the &quot;non-recursive&quot;=
 aspect, ignoring the<br>subsequent qualifiers of &quot;fully-enumerated&qu=
ot; and &quot;with no dynamic state&quot;.<br><br>The example that you&#39;=
ve come up with to &quot;directly undermine&quot; the claimed<br>motivation=
s of BIP 119 is still fully enumerated (the sole state is declared<br>up fr=
ont), and doesn&#39;t contain dynamic state (I can&#39;t spend the contract=
 on<br>chain and do something like swap in another hash H, or signature S).=
<br><br>&gt; I found it pretty inconvenient, which I don&#39;t think is a g=
ood indication<br>&gt; of ecosystem readiness wrt deployment. (For me, the =
two components that<br>&gt; are annoying is doing complicated taproot scrip=
t path spends, and<br>&gt; calculating CTV hashes)<br><br>What language/lib=
raries did you use to produce the spend? In my own<br>development tooling o=
f choice, producing complicated taproot script path<br>spends is pretty str=
aight forward, so perhaps the inconvenience you ran into<br>says more about=
 your dev tooling than the ecosystem readiness.<br><br>It&#39;s also worth =
pointing out that your example relies on private key<br>deletion, which if =
deemed acceptable, can be used to emulate CTV as is today<br>(though you ca=
n&#39;t create a self-referential loop that way afaict).<br><br>&gt; For me=
, the bllsh/simplicity approach makes more sense as a design<br>&gt; approa=
ch for the long term<br><br>Simplicity certainly has some brilliant devs wo=
rking on it, but after all<br>these years it still seems to be struggling t=
o exit research mode with some<br>&quot;killer apps&quot; on Liquid.<br><br=
>bllsh on the other hand is a very new (and cool!) project that has no<br>d=
evelopment uptake beyond its creator. Given its nascent state, it seems<br>=
rather premature to promote it as a long term solution.<br><br>Both of them=
 are effectively a complete rewrite of Script, so compared to<br>some of th=
e existing covenant proposals on the table (many of which have a<br>small c=
ore code footprint in the interpreter), they represent a radically<br>expan=
ded scope (ecosystem changes, wallets, consensus code) and therefore<br>add=
itional risks. The current Overton Window appears to be focused on a<br>sma=
ll (LoC wise) package to enable a greater degree of permissionless<br>innov=
ation on Bitcoin, while leaving the research landscape open for more<br>dra=
matic overhauls (bllsh/Simplicity) in the future.<br><br>-- Laolu<br></div>=
<div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_sig=
nature"><div dir=3D"ltr"><br></div></div></div></div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue=
, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns &lt;<a href=3D"mailto:aj@eri=
sian.com.au">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">Hello world,<br>
<br>
Some people on twitter are apparently proposing the near-term activation of=
<br>
CTV and CSFS (BIP 119 and BIP 348 respectively), eg:<br>
<br>
=C2=A0<a href=3D"https://x.com/JeremyRubin/status/1895676912401252588" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/JeremyRubin/status/18956769=
12401252588</a><br>
=C2=A0<a href=3D"https://x.com/lopp/status/1895837290209161358" rel=3D"nore=
ferrer" target=3D"_blank">https://x.com/lopp/status/1895837290209161358</a>=
<br>
=C2=A0<a href=3D"https://x.com/stevenroose3/status/1895881757288996914" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/stevenroose3/status/1895881=
757288996914</a><br>
=C2=A0<a href=3D"https://x.com/reardencode/status/1871343039123452340" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/reardencode/status/18713430=
39123452340</a><br>
=C2=A0<a href=3D"https://x.com/sethforprivacy/status/1895814836535378055" r=
el=3D"noreferrer" target=3D"_blank">https://x.com/sethforprivacy/status/189=
5814836535378055</a><br>
<br>
Since BIP 119&#39;s motivation is entirely concerned with its concept of<br=
>
covenants and avoiding what it calls recursive covenants, I think it<br>
is interesting to note that the combination of CSFS and CTV trivially<br>
enables the construction of a &quot;recursive covenant&quot; as BIP 119 use=
s those<br>
terms. One approach is as follows:<br>
<br>
=C2=A0* Make a throwaway BIP340 private key X with 32-bit public key P.<br>
=C2=A0* Calculate the tapscript &quot;OP_OVER &lt;P&gt; OP_CSFS OP_VERIFY O=
P_CTV&quot;, and<br>
=C2=A0 =C2=A0its corresponding scriptPubKey K when combined with P as the i=
nternal public<br>
=C2=A0 =C2=A0key.<br>
=C2=A0* Calculate the CTV hash corresponding to a payment of some specific =
value V<br>
=C2=A0 =C2=A0to K; call this hash H<br>
=C2=A0* Calculate the BIP 340 signature for message H with private key X, c=
all it S.<br>
=C2=A0* Discard the private key X<br>
=C2=A0* Funds sent to K can only be spent by the witness data &quot;&lt;H&g=
t; &lt;S&gt;&quot; that forwards<br>
=C2=A0 =C2=A0an amount V straight back to K.<br>
<br>
Here&#39;s a demonstration on mutinynet:<br>
<br>
=C2=A0<a href=3D"https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafc=
sg2lf5jd33tznmyjejrmqqx525gsk5nr58" rel=3D"noreferrer" target=3D"_blank">ht=
tps://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejr=
mqqx525gsk5nr58</a><br>
<br>
I&#39;d encourage people to try implementing that themselves with their<br>
preferred tooling; personally, I found it pretty inconvenient, which I<br>
don&#39;t think is a good indication of ecosystem readiness wrt deployment.=
<br>
(For me, the two components that are annoying is doing complicated<br>
taproot script path spends, and calculating CTV hashes)<br>
<br>
I don&#39;t believe the existence of a construction like this poses any<br>
problems in practice, however if there is going to be a push to activate<br=
>
BIP 119 in parallel with features that directly undermine its claimed<br>
motivation, then it would presumably be sensible to at least update<br>
the BIP text to describe a motivation that would actually be achieved by<br=
>
deployment.<br>
<br>
Personally, I think BIP 119&#39;s motivation remains very misguided:<br>
<br>
=C2=A0- the things it describes are, in general, not &quot;covenants&quot; =
[0]<br>
=C2=A0- the thing it avoids is not &quot;recursion&quot; but unbounded recu=
rsion<br>
=C2=A0- avoiding unbounded recursion is not very interesting when arbitrari=
ly<br>
=C2=A0 =C2=A0large recursion is still possible [1]<br>
=C2=A0- despite claiming that &quot;covenants have historically been widely=
<br>
=C2=A0 =C2=A0considering to be unfit for Bitcoin&quot;, no evidence for thi=
s claim has<br>
=C2=A0 =C2=A0been able to be provided [2,3]<br>
=C2=A0- the opposition to unbounded recursion seems to me to either mostly<=
br>
=C2=A0 =C2=A0or entirely be misplaced fear of things that are already possi=
ble in<br>
=C2=A0 =C2=A0bitcoin and easily avoided by people who want to avoid it, eg =
[4]<br>
<br>
so, at least personally, I think almost any update to BIP 119&#39;s motivat=
ion<br>
section would be an improvement...<br>
<br>
[0] <a href=3D"https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@eris=
ian.com.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bit=
coindev/20220719044458.GA26986@erisian.com.au/</a><br>
[1] <a href=3D"https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com=
.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bitcoindev=
/87k0dwr015.fsf@rustcorp.com.au/</a><br>
[2] <a href=3D"https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4=
c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/" rel=3D"noreferrer" =
target=3D"_blank">https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355=
d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/</a><br>
[3] <a href=3D"https://x.com/Ethan_Heilman/status/1194624166093369345" rel=
=3D"noreferrer" target=3D"_blank">https://x.com/Ethan_Heilman/status/119462=
4166093369345</a><br>
[4] <a href=3D"https://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisi=
an.com.au/" rel=3D"noreferrer" target=3D"_blank">https://gnusha.org/pi/bitc=
oindev/20220217151528.GC1429@erisian.com.au/</a><br>
<br>
Beyond being a toy example of a conflict with BIP 119&#39;s motivation<br>
section, I think the above script could be useful in the context of the<br>
&quot;blind-merged-mining&quot; component of spacechains [5]. For example, =
if<br>
the commitment was to two outputs, one the recursive step and the other<br>
being a 0sat ephemeral anchor, then the spend of the ephemeral anchor<br>
would allow for both providing fees conveniently and for encoding the<br>
spacechain block&#39;s commitment; competing spacechain miners would then<b=
r>
just be rbf&#39;ing that spend with the parent spacechain update remaining<=
br>
unchanged. The &quot;nLockTime&quot; and &quot;sequences_hash&quot; commitm=
ent in CTV would<br>
need to be used to ensure the &quot;one spacechain update per bitcoin block=
&quot;<br>
rule. (I believe mutinynet doesn&#39;t support ephemeral anchors however, s=
o<br>
I don&#39;t think there&#39;s anywhere this can be tested)<br>
<br>
[5] <a href=3D"https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34=
906b16a5#file-bmm-svg" rel=3D"noreferrer" target=3D"_blank">https://gist.gi=
thub.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg</a><br>
<br>
(For a spacechain, miners would want to be confident that the private key<b=
r>
has been discarded. This confidence could be enhanced by creating X as a<br=
>
musig2 key by a federation, in which case provided any of the private keys<=
br>
used in generating X were correctly discarded, then everything is fine,<br>
but that&#39;s still a trust assumption. Simple introspection opcodes would=
<br>
work far better for this use case, both removing the trust assumption<br>
and reducing the onchain data required)<br>
<br>
If you&#39;re providing CTV and CSFS anyway, I don&#39;t see why you wouldn=
&#39;t<br>
provide the same or similar functionality via a SIGHASH flag so that you<br=
>
can avoid specifying the hash directly when you&#39;re signing it anyway,<b=
r>
giving an ANYPREVOUT/NOINPUT-like feature directly.<br>
<br>
(Likewise, I don&#39;t see why you&#39;d want to activate CAT on mainnet wi=
thout<br>
also at least re-enabling SUBSTR, and potentially also the redundant<br>
LEFT and RIGHT operations)<br>
<br>
For comparison, bllsh [6,7] takes the approach of providing<br>
&quot;bip340_verify&quot; (directly equivalent to CSFS), &quot;ecdsa_verify=
&quot; (same but<br>
for ECDSA rather than schnorr), &quot;bip342_txmsg&quot; and &quot;tx&quot;=
 opcodes. A CTV<br>
equivalent would then either involve simplying writing:<br>
<br>
=C2=A0 =C2=A0(=3D (bip342_txmsg 3) 0x.....)<br>
<br>
meaining &quot;calculate the message hash of the current tx for SIGHASH_SIN=
GLE,<br>
then evaluate whether the result is exactly equal to this constant&quot;<br=
>
providing one of the standard sighashes worked for your use case, or<br>
replacing the bip342_txmsg opcode with a custom calculation of the tx<br>
hash, along the lines of the example reimplementation of bip342_txmsg<br>
for SIGHASH_ALL [8] in the probably more likely case that it didn&#39;t. If=
<br>
someone wants to write up the BIP 119 hashing formula in bllsh, I&#39;d<br>
be happy to include that as an example; I think it should be a pretty<br>
straightforward conversion from the test-tx example.<br>
<br>
If bllsh were live today (eg on either signet or mainnet), and it were<br>
desired to softfork in a more optimised implementation of either CTV or<br>
ANYPREVOUT to replace people coding their own implementation in bllsh<br>
directly, both would simply involve replacing calls to &quot;bip342_txmsg&q=
uot;<br>
with calls to a new hash calculation opcode. For CTV behaviour, usage<br>
would look like &quot;(=3D (bipXXX_txmsg) 0x...)&quot; as above; for APO be=
haviour,<br>
usage would look like &quot;(bip340_verify KEY (bipXXX_txmsg) SIG)&quot;. T=
hat<br>
is, the underlying &quot;I want to hash a message in such-and-such a way&qu=
ot;<br>
looks the same, and how it&#39;s used is the wallet author&#39;s decision,<=
br>
not a matter of how the consensus code is written.<br>
<br>
I believe simplicity/simfony can be thought of in much the same way;<br>
with &quot;jet::bip_0340_verify&quot; taking a tx hash for SIGHASH-like beh=
aviour<br>
[9], or &quot;jet::eq_256&quot; comparing a tx hash and a constant for CTV-=
like<br>
behaviour [10].<br>
<br>
[6] <a href=3D"https://github.com/ajtowns/bllsh/" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/ajtowns/bllsh/</a><br>
[7] <a href=3D"https://delvingbitcoin.org/t/debuggable-lisp-scripts/1224" r=
el=3D"noreferrer" target=3D"_blank">https://delvingbitcoin.org/t/debuggable=
-lisp-scripts/1224</a><br>
[8] <a href=3D"https://github.com/ajtowns/bllsh/blob/master/examples/test-t=
x" rel=3D"noreferrer" target=3D"_blank">https://github.com/ajtowns/bllsh/bl=
ob/master/examples/test-tx</a><br>
[9] <a href=3D"https://github.com/BlockstreamResearch/simfony/blob/master/e=
xamples/p2pk.simf" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
BlockstreamResearch/simfony/blob/master/examples/p2pk.simf</a><br>
[10] <a href=3D"https://github.com/BlockstreamResearch/simfony/blob/master/=
examples/ctv.simf" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
BlockstreamResearch/simfony/blob/master/examples/ctv.simf</a><br>
<br>
For me, the bllsh/simplicity approach makes more sense as a design<br>
approach for the long term, and the ongoing lack of examples of killer<br>
apps demonstrating big wins from limited slices of new functionality<br>
leaves me completely unexcited about rushing something in the short term.<b=
r>
Having a flood of use cases that don&#39;t work out when looked into isn&#3=
9;t<br>
a good replacement for a single compelling use case that does.<br>
<br>
Cheers,<br>
aj<br>
<br>
-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au" rel=3D"noreferrer" target=3D"=
_blank">https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40eri=
sian.com.au</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.g=
mail.com</a>.<br />

--000000000000c664c4062f924fc5--