path: root/b6/722ae985badf076827f83d0c754766d0276a77

Delivery-date: Wed, 05 Mar 2025 08:39:35 -0800
Received: from mail-oo1-f55.google.com ([209.85.161.55])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBPH4UG7AMGQEPOOHIBI@googlegroups.com>)
	id 1tprmP-0002YQ-OH
	for bitcoindev@gnusha.org; Wed, 05 Mar 2025 08:39:35 -0800
Received: by mail-oo1-f55.google.com with SMTP id 006d021491bc7-5f8d5e499a5sf4978020eaf.2
        for <bitcoindev@gnusha.org>; Wed, 05 Mar 2025 08:39:33 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741192767; cv=pass;
        d=google.com; s=arc-20240605;
        b=jIOTJAEydtS/xFDy901v4Oz6ejcmVqzNenvrpcQSJ4nw29TQf8YtsiAntLxNVOOCRD
         Ty4MuHJrieMEsYr7oDlKq17qNKS+Ue6F6rkXhg8N8eleZifHlvZG7rqpAqIvIOBc0/7k
         RdD5iRQgPIabTVvzD4x7/CIWkVEXoOOPAApYn6Z2QxoszeklLyB9KK2R/f/hxc/LiLO5
         LLGhvZcF35K2KcXn+aYmOvzk0Z4YEpMeDN+2YOJcVU0At/aqEIUXm9/ylk+wtKlkqexc
         tRz6ixuPBExXIYxxuj6xVKyPzRtbpQVwX7l/YUJ2wxn7muucLdN8HsznmKR8eJisy6sl
         D0PA==
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:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=;
        fh=0ZmcZD3ymjSeDp5pI+7DucfF6jwd3aZcshuQOyCMUPs=;
        b=dbpDRMoycB7wZ0rZ1cjIXLlZd7FytpmHCijRNKkwP69qimpABcuvI+2yfhi+YfxmKv
         r5t4Do90mPNuV2goT+HsedOrRqE+67N/v5Ui/jKEaE3jCQDRovz1l2Onl+MEqBS6XHzB
         amrPxrowk6tdDinF0dQuhAFKdL9jPVJmLoUCULHNxNG2o+SU5V15XpP1rJVobEmdJSMM
         dExV9r2o70aKKzZ2+PNvCSICFBra2MeGSz7Uct2BhKcXqoRdQK0gAoruwQtsXXeDWupt
         0r7969UeiNlax9LcVLfQ2oeGwD/O8aMz2yxgkR52s1Kb8Fy6rBtZVjkbLtPt+2xEyZr1
         yzCg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741192767; x=1741797567; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=;
        b=orhkALhvydB2qqfGLkhgUbQbYszA0+HDd2M/F8pG1vinGkrcD4aKMzfXysQZStI58D
         Yay/+4RpBuRb9PlDg5w1jwFQAotrAkQ1f5k8VkGpI/kk5sjzdegzis90Wjf0DNClxVK9
         1qdlLyPfT0ybglUdgP7tqpvePpyX6RiMZS+X4ZTbPytDijGIpgYhwjJVFKrB7BkapPIS
         s9cm1mnfyjRcNXJQAdH2+T+4o8ODndbHiN1Ot8xa6LPhmoU37D9g+LCmssN3HdVxm8x0
         TNX8ODfOryNP/iL8ahJ7YtEMVajwqO8ZhUVqtx41CDiwQcHdOUlIUxhsU+eg3yjuUUnk
         SyAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741192767; x=1741797567;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=voQUalEPG3bVY57pHT+LH1tX0ogShyfEqgWfNyglyrY=;
        b=pFHRZ0FDraUlRHqZgpHHbSmv0hXMSzxaHCJl/TO7xTDGdF9etM8I3HLheOKr94w9Ld
         2v9nAKpZxMou6bSYXEwEq4vNLmVZBNyHu81wcMN4XXTSoi61TtRJcI1Zbu0S3WYxlacn
         s9X9LaVzaWEEA2N782xt5L+b6AE7iTbJDe7GSLK75eoetpyFJUw685up+CDZUd//Pn2R
         dmtPIA7DZ94PxReO5X4OR+mPkhwcUMvsdg+Mf8LAM4ny3+8V+9S9G2QJLrYc21qAV9FH
         J11PKVo7IAyFdSaRKTBCjXyKmZRrB0J5SZf75HjV96claSIRZuSryJiSavEnfxiJgLpZ
         KxVw==
X-Forwarded-Encrypted: i=2; AJvYcCV1E/Z7yvlbJLbkrLo/0g914eK+Vewg5SvOmJDyoavcg80JdC7He74DqxpZ7ClWaOSsrfDqdpeYLcn4@gnusha.org
X-Gm-Message-State: AOJu0Yzph3jV8mtZMf0VUo4VuiM4gh+VSfDtE/k1+xk3kxzrpcQssWTY
	YFeUuKSyUek3KhG1TKGvSEOZgT9LE2aTZ5+dnQSJZ29JjWYaXQgJ
X-Google-Smtp-Source: AGHT+IEhea8yBMsxo8e1vYPxSE2SVb78ohl8YjwocfIvTJlbAlXcFAExmhBlFQqt7muu2sJ+RrB7aQ==
X-Received: by 2002:a05:6820:180b:b0:5fe:9a72:3dea with SMTP id 006d021491bc7-600334786e6mr2037053eaf.1.1741192767235;
        Wed, 05 Mar 2025 08:39:27 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVEpJk5+08jQLFrnQDQRboZ0xTVAatb4fsi89eQIqkU76g==
Received: by 2002:a4a:a508:0:b0:600:38e0:9fba with SMTP id 006d021491bc7-6003ea298e8ls890eaf.2.-pod-prod-08-us;
 Wed, 05 Mar 2025 08:39:24 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCWg404PhOoYCFADGY56OKZgrdLxJtYaxatbE9oFIwCyol7i14uNQEhSLJCe11cjjqXdfgZRqnXjIfh6@googlegroups.com
X-Received: by 2002:a05:6808:211c:b0:3f4:1b5f:9336 with SMTP id 5614622812f47-3f683157233mr2353495b6e.10.1741192764311;
        Wed, 05 Mar 2025 08:39:24 -0800 (PST)
Received: by 2002:a50:d4d9:0:b0:5d0:c760:dcfa with SMTP id 4fb4d7f45d1cf-5e59e69922fmsa12;
        Wed, 5 Mar 2025 08:14:36 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCXcLaz8hriE/zmKJZtARljBoJV2RrpbOXmF4lsgFcmea7i82oWsnJ5i/HFphWEGrxLeKoWyS8vBOE76@googlegroups.com
X-Received: by 2002:a05:6402:3490:b0:5de:3c29:e834 with SMTP id 4fb4d7f45d1cf-5e59f486c04mr4009424a12.27.1741191273895;
        Wed, 05 Mar 2025 08:14:33 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741191273; cv=none;
        d=google.com; s=arc-20240605;
        b=USt1EQoIihT0IY8psmmAs3GqvN3g3LSD2SEhQb1pHogOHf+U6/XzB6T73BPCfL1ib8
         9zmtbEKjL8HhycZ14qaDj6S1Okt3G8i/mOUQ8XYfFgaEu/uuzicDkHZpJNsPoU9xfmAN
         Y3bsJv3py1Odx1vW8tTvo7a09ONLCuDd/z1G/iaKReyf94/Xhllg3UZ8VH47KHfKIxzl
         d7XwFxTV+NuQC7V647MWM+zssWNO5nN6ZXt4MbhkbtzbJz3F3DqmeWVrwA25IPwVXAWr
         NiPUH14NiFQ9ic87uYL0ObDiN36uz1d6A+R0wuuMKEPsFBtbefwVxDP4DJnwATHD6Dqc
         ssQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=Rr6y2IFibHhIOC0HjwziiiHH5YFpByjiUDevbh0utQU=;
        fh=88ulwFhtu4sa9m0DaXx398b7a6WEA2oL1r9zBcWUF+A=;
        b=dJkkglDKq9stJjF21l/iXfwPgqVFvP1LOneGCuiBu+y6iPiX+v7ywAwHk5N6Dw4EDD
         IbJLUtRTZ4cf4OGrL5P39oi9RkNkZOGFzkkf6yxIy6XBdq3gRm9Er0PGjVeHA318iz10
         CCIuESNpKy+lrKU5j55fSqylpv8deG+TxvGT2WPKrZg3dLyfbbo09fb21L5lPRqjslOe
         OCs7FeMpkmBO/OHY7gy2TCCOmwCTwzAtRQzdofv1/s3yLt72hD4eMb60dxdMufKoFnSd
         UlaSeMCguhTPs/F1rjmX2cceIJBDPU3BKkjRncQBDQ/Ep5DczBVxcUySv08+602IPTYd
         8BfQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-10629.protonmail.ch (mail-10629.protonmail.ch. [79.135.106.29])
        by gmr-mx.google.com with ESMTPS id 4fb4d7f45d1cf-5e4c3b9d63fsi689845a12.2.2025.03.05.08.14.33
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 05 Mar 2025 08:14:33 -0800 (PST)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.29 as permitted sender) client-ip=79.135.106.29;
Date: Wed, 05 Mar 2025 16:14:26 +0000
To: Olaoluwa Osuntokun <laolu32@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Anthony Towns <aj@erisian.com.au>, bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Message-ID: <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com>
In-Reply-To: <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
References: <Z8eUQCfCWjdivIzn@erisian.com.au> <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 0f5d15d4037617c951770d7266254d873b1d9fca
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=TQiPWAIH;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 79.135.106.29 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)

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

Hi,

Just picking on one thing Laolu said:

> The current Overton Window appears to be focused on a small (LoC wise) pa=
ckage to enable a greater degree of permissionless innovation on Bitcoin

For what it's worth i'm not sure this is the correct focus. Bitcoin Script =
is so notoriously unpredictable and hard to reason about that most of what =
matters is outside of the lines of code changed. Of course it depends on th=
e specifics, but rewriting a clean interpreter that we can actually reason =
about does not strike me as a necessarily riskier approach than "just chang=
ing a few lines of code" in an interpreter that hardly anyone knows how it =
really behaves in all cases.

Antoine

On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <laolu32@gmail=
.com> wrote:

> 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-1=
19
>> 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 decla=
red
> 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 i=
nto
> 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 to=
day
> (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 so=
me
> "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> =
wrote:
>
>> 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 pu=
blic
>> key.
>> * Calculate the CTV hash corresponding to a payment of some specific val=
ue 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 f=
orwards
>> an amount V straight back to K.
>>
>> Here's a demonstration on mutinynet:
>>
>> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznm=
yjejrmqqx525gsk5nr58
>>
>> 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 motivati=
on
>> 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.a=
u/
>>
>> 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 ke=
y
>> 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 ke=
ys
>> 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_SINGL=
E,
>> 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.simf
>>
>> 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 Group=
s "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n email to [bitcoindev+unsubscribe@googlegroups.com](mailto:bitcoindev%2Bun=
subscribe@googlegroups.com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoind=
ev/Z8eUQCfCWjdivIzn%40erisian.com.au.
>
> --
> 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/bitcoinde=
v/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com.

--=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/=
1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLo=
QhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;">Hi,</div><d=
iv style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px;">Just picking o=
n one thing Laolu said:<br><blockquote style=3D"border-left: 3px solid rgb(=
200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px; color=
: rgb(102, 102, 102);"><div>The current Overton Window appears to be focuse=
d on a small (LoC wise) package to enable a greater degree of permissionles=
s innovation on Bitcoin</div></blockquote><div><br></div><div><span style=
=3D"font-family: Arial, sans-serif; font-size: 14px; font-weight: 400; colo=
r: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">For what it's worth=
 i'm not sure this is the correct focus. Bitcoin Script is so notoriously u=
npredictable and hard to reason about that most of what matters is outside =
of the lines of code changed. Of course it depends on the specifics, but re=
writing a clean interpreter that we can actually reason about does not </sp=
an>strike me as a necessarily riskier approach than "just changing a few li=
nes of code" in an interpreter that hardly anyone knows how it really behav=
es in all cases.<br><br>Antoine<br></div></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div>
<div class=3D"protonmail_quote">
        On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun &lt;la=
olu32@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            <div dir=3D"ltr"><div>Hi AJ,<br><br>First a standard disclaimer=
: the contents of this email shouldn't be<br>interpreted as an endorsement =
of one covenants proposal over another.<br><br>&gt; Since BIP 119's motivat=
ion is entirely concerned with its concept of<br>&gt; covenants and avoidin=
g what it calls recursive covenants<br><br>If we look at the motivation sec=
tion of BIP 119, we find this sentence: <br><br>&gt; This BIP introduces a =
simple covenant called a *template* which enables a<br>&gt; limited set of =
highly valuable use cases without significant risk. BIP-119<br>&gt; templat=
es allow for non-recursive fully-enumerated covenants with no<br>&gt; dynam=
ic state. <br><br>You appear to have latched onto the "non-recursive" aspec=
t, ignoring the<br>subsequent qualifiers of "fully-enumerated" and "with no=
 dynamic state".<br><br>The example that you've come up with to "directly u=
ndermine" the claimed<br>motivations of BIP 119 is still fully enumerated (=
the sole state is declared<br>up front), and doesn't contain dynamic state =
(I can't spend the contract on<br>chain and do something like swap in anoth=
er hash H, or signature S).<br><br>&gt; I found it pretty inconvenient, whi=
ch I don't think is a good indication<br>&gt; of ecosystem readiness wrt de=
ployment. (For me, the two components that<br>&gt; are annoying is doing co=
mplicated taproot script path spends, and<br>&gt; calculating CTV hashes)<b=
r><br>What language/libraries did you use to produce the spend? In my own<b=
r>development tooling of choice, producing complicated taproot script path<=
br>spends is pretty straight forward, so perhaps the inconvenience you ran =
into<br>says more about your dev tooling than the ecosystem readiness.<br><=
br>It'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 toda=
y<br>(though you can'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; approach for the long term<br><br>Simplicity certainly has some br=
illiant devs working on it, but after all<br>these years it still seems to =
be struggling to exit research mode with some<br>"killer apps" on Liquid.<b=
r><br>bllsh on the other hand is a very new (and cool!) project that has no=
<br>development uptake beyond its creator. Given its nascent state, it seem=
s<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 the existing covenant proposals on the table (many of which have a<br>sm=
all core code footprint in the interpreter), they represent a radically<br>=
expanded scope (ecosystem changes, wallets, consensus code) and therefore<b=
r>additional risks. The current Overton Window appears to be focused on a<b=
r>small (LoC wise) package to enable a greater degree of permissionless<br>=
innovation on Bitcoin, while leaving the research landscape open for more<b=
r>dramatic overhauls (bllsh/Simplicity) in the future.<br><br>-- Laolu<br><=
/div><div><div data-smartmail=3D"gmail_signature" class=3D"gmail_signature"=
 dir=3D"ltr"><div dir=3D"ltr"><br></div></div></div></div><br><div class=3D=
"gmail_quote gmail_quote_container"><div class=3D"gmail_attr" dir=3D"ltr">O=
n Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns &lt;<a href=3D"mailto:a=
j@erisian.com.au" rel=3D"noreferrer nofollow noopener">aj@erisian.com.au</a=
>&gt; wrote:<br></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">Hel=
lo 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>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
x.com/JeremyRubin/status/1895676912401252588">https://x.com/JeremyRubin/sta=
tus/1895676912401252588</a><br>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
x.com/lopp/status/1895837290209161358">https://x.com/lopp/status/1895837290=
209161358</a><br>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
x.com/stevenroose3/status/1895881757288996914">https://x.com/stevenroose3/s=
tatus/1895881757288996914</a><br>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
x.com/reardencode/status/1871343039123452340">https://x.com/reardencode/sta=
tus/1871343039123452340</a><br>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
x.com/sethforprivacy/status/1895814836535378055">https://x.com/sethforpriva=
cy/status/1895814836535378055</a><br>
<br>
Since BIP 119'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 "recursive covenant" as BIP 119 uses those<br=
>
terms. One approach is as follows:<br>
<br>
 * Make a throwaway BIP340 private key X with 32-bit public key P.<br>
 * Calculate the tapscript "OP_OVER &lt;P&gt; OP_CSFS OP_VERIFY OP_CTV", an=
d<br>
   its corresponding scriptPubKey K when combined with P as the internal pu=
blic<br>
   key.<br>
 * Calculate the CTV hash corresponding to a payment of some specific value=
 V<br>
   to K; call this hash H<br>
 * Calculate the BIP 340 signature for message H with private key X, call i=
t S.<br>
 * Discard the private key X<br>
 * Funds sent to K can only be spent by the witness data "&lt;H&gt; &lt;S&g=
t;" that forwards<br>
   an amount V straight back to K.<br>
<br>
Here's a demonstration on mutinynet:<br>
<br>
 <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https://=
mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx52=
5gsk5nr58">https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5=
jd33tznmyjejrmqqx525gsk5nr58</a><br>
<br>
I'd encourage people to try implementing that themselves with their<br>
preferred tooling; personally, I found it pretty inconvenient, which I<br>
don'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'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's motivation remains very misguided:<br>
<br>
 - the things it describes are, in general, not "covenants" [0]<br>
 - the thing it avoids is not "recursion" but unbounded recursion<br>
 - avoiding unbounded recursion is not very interesting when arbitrarily<br=
>
   large recursion is still possible [1]<br>
 - despite claiming that "covenants have historically been widely<br>
   considering to be unfit for Bitcoin", no evidence for this claim has<br>
   been able to be provided [2,3]<br>
 - the opposition to unbounded recursion seems to me to either mostly<br>
   or entirely be misplaced fear of things that are already possible in<br>
   bitcoin 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's motivation<=
br>
section would be an improvement...<br>
<br>
[0] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/">https:/=
/gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/</a><br>
[1] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/">https://gnusha=
.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/</a><br>
[2] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b5=
80ba99-000000@email.amazonses.com/">https://gnusha.org/pi/bitcoindev/010001=
7ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/=
</a><br>
[3] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://x.com/Ethan_Heilman/status/1194624166093369345">https://x.com/Ethan_Heil=
man/status/1194624166093369345</a><br>
[4] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/">https://=
gnusha.org/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/</a><br>
<br>
Beyond being a toy example of a conflict with BIP 119's motivation<br>
section, I think the above script could be useful in the context of the<br>
"blind-merged-mining" 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's commitment; competing spacechain miners would then<br>
just be rbf'ing that spend with the parent spacechain update remaining<br>
unchanged. The "nLockTime" and "sequences_hash" commitment in CTV would<br>
need to be used to ensure the "one spacechain update per bitcoin block"<br>
rule. (I believe mutinynet doesn't support ephemeral anchors however, so<br=
>
I don't think there's anywhere this can be tested)<br>
<br>
[5] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-sv=
g">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#fil=
e-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'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're providing CTV and CSFS anyway, I don't see why you wouldn't<br>
provide the same or similar functionality via a SIGHASH flag so that you<br=
>
can avoid specifying the hash directly when you're signing it anyway,<br>
giving an ANYPREVOUT/NOINPUT-like feature directly.<br>
<br>
(Likewise, I don't see why you'd want to activate CAT on mainnet without<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>
"bip340_verify" (directly equivalent to CSFS), "ecdsa_verify" (same but<br>
for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. A CTV<br>
equivalent would then either involve simplying writing:<br>
<br>
   (=3D (bip342_txmsg 3) 0x.....)<br>
<br>
meaining "calculate the message hash of the current tx for SIGHASH_SINGLE,<=
br>
then evaluate whether the result is exactly equal to this constant"<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't. If<br>
someone wants to write up the BIP 119 hashing formula in bllsh, I'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 "bip342_txmsg"<br>
with calls to a new hash calculation opcode. For CTV behaviour, usage<br>
would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO behaviour,<b=
r>
usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". That<br>
is, the underlying "I want to hash a message in such-and-such a way"<br>
looks the same, and how it's used is the wallet author'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 "jet::bip_0340_verify" taking a tx hash for SIGHASH-like behaviour<br>
[9], or "jet::eq_256" comparing a tx hash and a constant for CTV-like<br>
behaviour [10].<br>
<br>
[6] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://github.com/ajtowns/bllsh/">https://github.com/ajtowns/bllsh/</a><br>
[7] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://delvingbitcoin.org/t/debuggable-lisp-scripts/1224">https://delvingbitcoi=
n.org/t/debuggable-lisp-scripts/1224</a><br>
[8] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://github.com/ajtowns/bllsh/blob/master/examples/test-tx">https://github.co=
m/ajtowns/bllsh/blob/master/examples/test-tx</a><br>
[9] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf">h=
ttps://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.sim=
f</a><br>
[10] <a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"http=
s://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf">h=
ttps://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't work out when looked into isn'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 "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a target=3D"_blank" href=3D"mailto:bitcoindev%2Bunsubscribe@google=
groups.com" rel=3D"noreferrer nofollow noopener">bitcoindev+unsubscribe@goo=
glegroups.com</a>.<br>
To view this discussion visit <a target=3D"_blank" rel=3D"noreferrer nofoll=
ow noopener" href=3D"https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCW=
jdivIzn%40erisian.com.au">https://groups.google.com/d/msgid/bitcoindev/Z8eU=
QCfCWjdivIzn%40erisian.com.au</a>.<br>
</blockquote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail=
.com" target=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups=
.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgC=
HWxNV_Q%40mail.gmail.com</a>.<br>

        </blockquote><br>
    </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/1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JU=
i1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLo=
QhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo%3D%40protonmail.com</a>.<br />

--b1=_kIbr1iOY6KQRAL0ZOxt5MQsbjEcNeQ7u1qq0JIp0Xo--