path: root/41/7da57368233fa4f9124f0741648f4d6d45cb37

Delivery-date: Thu, 06 Mar 2025 11:03:57 -0800
Received: from mail-oo1-f62.google.com ([209.85.161.62])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBEXDU67AMGQEXNW7BBI@googlegroups.com>)
	id 1tqGVg-0007Lc-61
	for bitcoindev@gnusha.org; Thu, 06 Mar 2025 11:03:57 -0800
Received: by mail-oo1-f62.google.com with SMTP id 006d021491bc7-60041dfef50sf881680eaf.0
        for <bitcoindev@gnusha.org>; Thu, 06 Mar 2025 11:03:56 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1741287830; cv=pass;
        d=google.com; s=arc-20240605;
        b=dEWO0y59DkCHgJK+bKtZI2Gvk4wci9UHKVvRPNoBi05RwWTeoXX5ieo71kONhsQANa
         wTBc2C4Yq5DoLAiBrqZtBjnrrKpc5baON2f5mi5fsXtHGJuCCFmxhWhFfE4ufVQD0aQA
         5wB8VQRuQm3bW5lW4Y7qHBzx+q26igWHweReuV/420q2GTDoJFGE7t7d8B927CyN198U
         PLpU57W+dWnefD5XAWcHbIUtTEyEQdooq7gX6Bk/3baSjxfjMUgKQKXXTHWU0AJbXND2
         AC+dbRhJP7SDJJ6Mt7nv9dm5HeCu3b0mkwTSs2U+yVfi4Iy5Q83FeKL6hxRatDTXX20m
         uLyA==
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:content-transfer-encoding
         :mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=;
        fh=mK1YCV2SAcJu/sZA5qIZrBO3uS1wOAk4E9oaLyZLae4=;
        b=Onr2oQv9G9EsJM1eQ3FkSK9oEcy5hXgLa0yJNLsG+tlEH5+Wcr5U/hcdvNSsqkBIkm
         AsHcmShNVCHp5VviptqPgQ1RC/zvq48MC2uNwIYDQDDpWXK2Fe0hF6/qocLLcqWWo1Bb
         CcLTPkCGfIAzD6N9vUSO4fv0Y53YTttdh3LpJ5nH0d7PTpQoXUFAx4sv9G3xpIJorJyn
         eUJRjo5EbJQWJ9Phm7i5Klpd+HOEUJxplIZn1/9/lSwH9ze4brVESEF3PSWKk0V42qeL
         GJqIsyEi+L79DO3S/gFexAZ5iJaysliolvq2e6OTRlYwOMTNGNP0GrDnYm7CLv7jEhtx
         AnHA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@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=1741287830; x=1741892630; 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
         :content-transfer-encoding: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=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=;
        b=jXk2fnV++6C/GbOLlQ0mQhxpegf0yJrvSErV3NZ+hivT1y9+2QZM++fpytqpoJ2lTL
         XkWhSOZ2wGYFIY6qAQJ/9y8YMmbFWXGhaSal4xcwmGc+/g0NJUadKTENBoexLkvYcta1
         GqBB6LJg2ctSVABVCeYnNuIclzEpd0cYene14cUHEKFF0KYv6sIA7iUb1zubdbX7zdEd
         WaMG66JS7kxhDJB3b3dfLOAYMuBNaiV+vGbMd0GZNJVp/tcGhQDGUcnwbw7/IfC1AXOE
         nLAS/KcjKaePC/IKyhNU82HG3I9hoBkU5olngeMFDPYa2DHjxadqBauy5ev0fZ+dCWAw
         iFAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741287830; x=1741892630;
        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
         :content-transfer-encoding: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=prnCbZQeVFyFXBdnafn08zD66ClGNcAqfJl+TUrl3uA=;
        b=Eg8WTQBT4Nd2/8mhfPS4K5rDOBfG/0yQ4zQtYluomU64WNFY/0VYcP6v3SeZmFn+eM
         bPsI1y3GENsjOAA43+at701nU4J8kemBA+TMwSv53qKTDTKQ1TX1HewnAVldENjMGM/K
         8OSw4gam1tCnnCtAaUEOZJffOaNwtu0DFgkKQ8+eSuKZ3zIxutT4FGoPBkwzaYqFAteh
         HOamXquL3ch1KjtV2GJ7e0rzLZ6+KuNUUkc4wezmJQIzIivMVQJF04ekFqNa05UD8etG
         41jrch+hOHE/ObQgZKHnu/EvCOB34ZjxIQyj3nQpiyDXTgfr0uKmYWTTP2S5Uybzsj1v
         K4Yg==
X-Forwarded-Encrypted: i=2; AJvYcCXlN2mB3gT5UdsjJ/7Si6LDpkv8EW+KRbWrXa8pljLhVN3en/Y0BxcmaTYhz8CMnbFRIWaIVtsmLKfd@gnusha.org
X-Gm-Message-State: AOJu0YyeWHo9Pv0ZD/+g2bv6IyQCyp86Gp/RaFWqvUL2KDZzQAHOxVTu
	nShEl++hmwoNZoM1CFerSeu363N/HdgsN1Thocg/qnj8zThQ3l7w
X-Google-Smtp-Source: AGHT+IGsFRW0uVx7MYLBMnlPdmAXsIBXv8wkMXersIc+6geFepq2uSXqECtE4Cj+4rYX7SX7uoqkbw==
X-Received: by 2002:a05:6820:2711:b0:5fe:9d0b:f7a with SMTP id 006d021491bc7-6004a773d0fmr274800eaf.2.1741287828770;
        Thu, 06 Mar 2025 11:03:48 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVF37z4xPt8mJeu0/bk9LvfsiAty8NWtJ7vG9xmaEcHkpg==
Received: by 2002:a05:6820:229c:b0:600:108d:824b with SMTP id
 006d021491bc7-6003e89de89ls564903eaf.0.-pod-prod-05-us; Thu, 06 Mar 2025
 11:03:46 -0800 (PST)
X-Received: by 2002:a05:6808:3986:b0:3f3:d275:d873 with SMTP id 5614622812f47-3f697b5d5fbmr396243b6e.17.1741287826445;
        Thu, 06 Mar 2025 11:03:46 -0800 (PST)
Received: by 2002:a50:d759:0:b0:5d9:ef28:b33e with SMTP id 4fb4d7f45d1cf-5e59e6bc0admsa12;
        Thu, 6 Mar 2025 10:36:22 -0800 (PST)
X-Received: by 2002:a17:907:1c1f:b0:ac2:1793:adc3 with SMTP id a640c23a62f3a-ac252fb9688mr10356366b.41.1741286180100;
        Thu, 06 Mar 2025 10:36:20 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1741286180; cv=none;
        d=google.com; s=arc-20240605;
        b=k1G2gyIqO+vU1XFIUh0Ym7/UdXmuwoN4dT7UQ/5JZHkFJ+szU5huTqYq27585h58C6
         FhZ5kpXYZzXqfn+3lZISZ2mAN8kw0PkTQJNN7O/lOyaMWn1DlXsFkBzQLTwtOQbZPMLF
         vNO5z7JHPzwGmoru+GUhWTwASnuKI2txvItRIUnISX72ed3trRxAtFxwrdHMxzoE23xx
         YDAdpvzoBIURYhPNZhANfbzS1/9UbrguEN+nHnawc5AK/SF6vK6Cxpt32NoPZQYHZpSq
         GmK9zAEiQQ0oxrF0DQNh8EU33GF487J5ZeF8wGan3uFCSEMQgv/lvOQze3um+wMEcjER
         E6pw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature;
        bh=/w5R5jDabCkhMOkb9KsLxCm1ZWrDinEzTi2Z07WB3A4=;
        fh=sjkP8zjFS5lFlY+fNUHD47XPXx06dShKmNgWs4F+if8=;
        b=bayRwYSm4j79IhvBEKk6htkqzYkmwEu2gOs0dI/8nBzm7mggoIUxFU59e6WisWRaPc
         4zKeog4D9qqo9+UjotIAIPKDNuzKWeQgkZ/R38taT/3xecdUVjz2pc7+pRP4YLD3qBLW
         XWveEV9waiJpVMo3eaejj4G984M1ZUPqvuUz+i9KhN/bMHJghwGSTQ+jqUNDjgXMvTGo
         XANwzwwI1QQD5DCjjRONKEu1GMaJLmHv5iSHRXoinhXBHijOk/I9jr1IDPWnzI/mZoXY
         BAuEjhUBa543rdHRmgP2QAxzRvj0WKsjmrQkm+4bdKOJc2zxOdDJO4KzfHaaxH5z3iqr
         0uIg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch. [185.70.40.137])
        by gmr-mx.google.com with ESMTPS id a640c23a62f3a-ac23913076asi3690266b.0.2025.03.06.10.36.20
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Thu, 06 Mar 2025 10:36:20 -0800 (PST)
Received-SPF: pass (google.com: domain of moonsettler@protonmail.com designates 185.70.40.137 as permitted sender) client-ip=185.70.40.137;
Date: Thu, 06 Mar 2025 18:36:15 +0000
To: Greg Sanders <gsanders87@gmail.com>
From: "'moonsettler' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
Message-ID: <Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9YSgZpC013Lj4SI_WZR0N1iwbUiNze00tA=@protonmail.com>
In-Reply-To: <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com>
References: <Z8eUQCfCWjdivIzn@erisian.com.au> <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com> <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com> <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com>
Feedback-ID: 38540639:user:proton
X-Pm-Message-ID: 23a02cddfb57720ecf4ce31fd1239f1629eb8fe5
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Original-Sender: moonsettler@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=PPSazCWO;
       spf=pass (google.com: domain of moonsettler@protonmail.com designates
 185.70.40.137 as permitted sender) smtp.mailfrom=moonsettler@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: moonsettler <moonsettler@protonmail.com>
Reply-To: moonsettler <moonsettler@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 (-)

Hi All,

> I am less persuaded that consensus risk is particularly high for very nar=
rowly scoped changes
Agreed.

Some people out there seem to conflate execution risks with crypto-economic=
 incentives risks.
Better designed script systems obviously reduce execution risks and uninten=
ded consensus failure risks and make maintenance easier.
They also quiet easily blow the lid off other types of risks by nature of b=
eing better and more capable.

Paradoxically the more expressive bitcoin script becomes over time, the les=
s likely that a script system overhaul comes with a nasty surprise.

BR,
moonsettler


On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsanders87@gmail.com=
> wrote:

> > Of course it depends on the specifics, but rewriting a clean interprete=
r that we can actually reason about does not strike me as a necessarily ris=
kier approach than "just changing a few lines of code" in an interpreter th=
at hardly anyone knows how it really behaves in all cases.
>=20
> It's certainly something to consider when weighing further off Bitcoin Sc=
ript updates: From here is something like "Great Script Restoration" ever t=
he right choice vs a from scratch overhaul? I am less persuaded that consen=
sus risk is particularly high for very narrowly scoped changes, ignoring th=
e "fixed" costs of changing consensus, maintenance burden, MEVil risks, etc=
. The risk-reward ratio may be suboptimal of course.
> Greg
> On Wednesday, March 5, 2025 at 11:39:27=E2=80=AFAM UTC-5 Antoine Poinsot =
wrote:
>=20
> > Hi,
> >=20
> >=20
> > Just picking on one thing Laolu said:
> >=20
> > > The current Overton Window appears to be focused on a small (LoC wise=
) package to enable a greater degree of permissionless innovation on Bitcoi=
n
> >=20
> >=20
> > For what it's worth i'm not sure this is the correct focus. Bitcoin Scr=
ipt is so notoriously unpredictable and hard to reason about that most of w=
hat matters is outside of the lines of code changed. Of course it depends o=
n the specifics, but rewriting a clean interpreter that we can actually rea=
son about does not strike me as a necessarily riskier approach than "just c=
hanging a few lines of code" in an interpreter that hardly anyone knows how=
 it really behaves in all cases.
> >=20
> > Antoine
> >=20
> > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <lao...@gm=
ail.com> wrote:
> >=20
> > > Hi AJ,
> > >=20
> > > First a standard disclaimer: the contents of this email shouldn't be
> > > interpreted as an endorsement of one covenants proposal over another.
> > >=20
> > > > Since BIP 119's motivation is entirely concerned with its concept o=
f
> > > > covenants and avoiding what it calls recursive covenants
> > >=20
> > > If we look at the motivation section of BIP 119, we find this sentenc=
e:
> > >=20
> > > > This BIP introduces a simple covenant called a *template* which ena=
bles a
> > > > limited set of highly valuable use cases without significant risk. =
BIP-119
> > > > templates allow for non-recursive fully-enumerated covenants with n=
o
> > > > dynamic state.
> > >=20
> > > You appear to have latched onto the "non-recursive" aspect, ignoring =
the
> > > subsequent qualifiers of "fully-enumerated" and "with no dynamic stat=
e".
> > >=20
> > > The example that you've come up with to "directly undermine" the clai=
med
> > > motivations of BIP 119 is still fully enumerated (the sole state is d=
eclared
> > > up front), and doesn't contain dynamic state (I can't spend the contr=
act on
> > > chain and do something like swap in another hash H, or signature S).
> > >=20
> > > > I found it pretty inconvenient, which I don't think is a good indic=
ation
> > > > of ecosystem readiness wrt deployment. (For me, the two components =
that
> > > > are annoying is doing complicated taproot script path spends, and
> > > > calculating CTV hashes)
> > >=20
> > > What language/libraries did you use to produce the spend? In my own
> > > development tooling of choice, producing complicated taproot script p=
ath
> > > spends is pretty straight forward, so perhaps the inconvenience you r=
an into
> > > says more about your dev tooling than the ecosystem readiness.
> > >=20
> > > 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 i=
s today
> > > (though you can't create a self-referential loop that way afaict).
> > >=20
> > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > approach for the long term
> > >=20
> > > Simplicity certainly has some brilliant devs working on it, but after=
 all
> > > these years it still seems to be struggling to exit research mode wit=
h some
> > > "killer apps" on Liquid.
> > >=20
> > > 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 se=
ems
> > > rather premature to promote it as a long term solution.
> > >=20
> > > Both of them are effectively a complete rewrite of Script, so compare=
d to
> > > some of the existing covenant proposals on the table (many of which h=
ave a
> > > small core code footprint in the interpreter), they represent a radic=
ally
> > > expanded scope (ecosystem changes, wallets, consensus code) and there=
fore
> > > 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.
> > >=20
> > > -- Laolu
> > >=20
> > >=20
> > > On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns <a...@erisian.co=
m.au> wrote:
> > >=20
> > > > Hello world,
> > > >=20
> > > > Some people on twitter are apparently proposing the near-term activ=
ation of
> > > > CTV and CSFS (BIP 119 and BIP 348 respectively), eg:
> > > >=20
> > > > 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
> > > >=20
> > > > Since BIP 119's motivation is entirely concerned with its concept o=
f
> > > > covenants and avoiding what it calls recursive covenants, I think i=
t
> > > > is interesting to note that the combination of CSFS and CTV trivial=
ly
> > > > enables the construction of a "recursive covenant" as BIP 119 uses =
those
> > > > terms. One approach is as follows:
> > > >=20
> > > > * 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", a=
nd
> > > > its corresponding scriptPubKey K when combined with P as the intern=
al public
> > > > key.
> > > > * Calculate the CTV hash corresponding to a payment of some specifi=
c 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>" t=
hat forwards
> > > > an amount V straight back to K.
> > > >=20
> > > > Here's a demonstration on mutinynet:
> > > >=20
> > > > https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd3=
3tznmyjejrmqqx525gsk5nr58
> > > >=20
> > > > I'd encourage people to try implementing that themselves with their
> > > > preferred tooling; personally, I found it pretty inconvenient, whic=
h I
> > > > don't think is a good indication of ecosystem readiness wrt deploym=
ent.
> > > > (For me, the two components that are annoying is doing complicated
> > > > taproot script path spends, and calculating CTV hashes)
> > > >=20
> > > > 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 act=
ivate
> > > > BIP 119 in parallel with features that directly undermine its claim=
ed
> > > > motivation, then it would presumably be sensible to at least update
> > > > the BIP text to describe a motivation that would actually be achiev=
ed by
> > > > deployment.
> > > >=20
> > > > Personally, I think BIP 119's motivation remains very misguided:
> > > >=20
> > > > - 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 arbitra=
rily
> > > > 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 ha=
s
> > > > been able to be provided [2,3]
> > > > - the opposition to unbounded recursion seems to me to either mostl=
y
> > > > or entirely be misplaced fear of things that are already possible i=
n
> > > > bitcoin and easily avoided by people who want to avoid it, eg [4]
> > > >=20
> > > > so, at least personally, I think almost any update to BIP 119's mot=
ivation
> > > > section would be an improvement...
> > > >=20
> > > > [0] https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/
> > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/
> > > > [2] https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16=
...@email.amazonses.com/
> > > > [3] https://x.com/Ethan_Heilman/status/1194624166093369345
> > > > [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/
> > > >=20
> > > > 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 o=
ther
> > > > being a 0sat ephemeral anchor, then the spend of the ephemeral anch=
or
> > > > would allow for both providing fees conveniently and for encoding t=
he
> > > > spacechain block's commitment; competing spacechain miners would th=
en
> > > > just be rbf'ing that spend with the parent spacechain update remain=
ing
> > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV w=
ould
> > > > need to be used to ensure the "one spacechain update per bitcoin bl=
ock"
> > > > rule. (I believe mutinynet doesn't support ephemeral anchors howeve=
r, so
> > > > I don't think there's anywhere this can be tested)
> > > >=20
> > > > [5] https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906=
b16a5#file-bmm-svg
> > > >=20
> > > > (For a spacechain, miners would want to be confident that the priva=
te 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 priva=
te keys
> > > > used in generating X were correctly discarded, then everything is f=
ine,
> > > > but that's still a trust assumption. Simple introspection opcodes w=
ould
> > > > work far better for this use case, both removing the trust assumpti=
on
> > > > and reducing the onchain data required)
> > > >=20
> > > > 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 tha=
t you
> > > > can avoid specifying the hash directly when you're signing it anywa=
y,
> > > > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > > >=20
> > > > (Likewise, I don't see why you'd want to activate CAT on mainnet wi=
thout
> > > > also at least re-enabling SUBSTR, and potentially also the redundan=
t
> > > > LEFT and RIGHT operations)
> > > >=20
> > > > 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:
> > > >=20
> > > > (=3D (bip342_txmsg 3) 0x.....)
> > > >=20
> > > > 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, o=
r
> > > > replacing the bip342_txmsg opcode with a custom calculation of the =
tx
> > > > hash, along the lines of the example reimplementation of bip342_txm=
sg
> > > > 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 pret=
ty
> > > > straightforward conversion from the test-tx example.
> > > >=20
> > > > If bllsh were live today (eg on either signet or mainnet), and it w=
ere
> > > > desired to softfork in a more optimised implementation of either CT=
V or
> > > > ANYPREVOUT to replace people coding their own implementation in bll=
sh
> > > > directly, both would simply involve replacing calls to "bip342_txms=
g"
> > > > with calls to a new hash calculation opcode. For CTV behaviour, usa=
ge
> > > > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO beha=
viour,
> > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)". Tha=
t
> > > > 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.
> > > >=20
> > > > 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 behav=
iour
> > > > [9], or "jet::eq_256" comparing a tx hash and a constant for CTV-li=
ke
> > > > behaviour [10].
> > > >=20
> > > > [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/exam=
ples/p2pk.simf
> > > > [10] https://github.com/BlockstreamResearch/simfony/blob/master/exa=
mples/ctv.simf
> > > >=20
> > > > For me, the bllsh/simplicity approach makes more sense as a design
> > > > approach for the long term, and the ongoing lack of examples of kil=
ler
> > > > apps demonstrating big wins from limited slices of new functionalit=
y
> > > > 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 is=
n't
> > > > a good replacement for a single compelling use case that does.
> > > >=20
> > > > Cheers,
> > > > aj
> > > >=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, s=
end an email to bitcoindev+...@googlegroups.com.
> > > > To view this discussion visit https://groups.google.com/d/msgid/bit=
coindev/Z8eUQCfCWjdivIzn%40erisian.com.au.
> > >=20
> > > --
> > > You received this message because you are subscribed to the Google Gr=
oups "Bitcoin Development Mailing List" group.
> > > To unsubscribe from this group and stop receiving emails from it, sen=
d an email to bitcoindev+...@googlegroups.com.
> >=20
> > > To view this discussion visit https://groups.google.com/d/msgid/bitco=
indev/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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.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/=
Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9Y=
SgZpC013Lj4SI_WZR0N1iwbUiNze00tA%3D%40protonmail.com.