path: root/57/483f1214bace90a33e02e05c5421b845c2f637

Delivery-date: Thu, 06 Mar 2025 09:37:11 -0800
Received: from mail-yw1-f188.google.com ([209.85.128.188])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDRIFMNQZANRBO52U67AMGQEUAOGOFA@googlegroups.com>)
	id 1tqF9h-0004xT-BQ
	for bitcoindev@gnusha.org; Thu, 06 Mar 2025 09:37:11 -0800
Received: by mail-yw1-f188.google.com with SMTP id 00721157ae682-6feb1097d64sf13430387b3.2
        for <bitcoindev@gnusha.org>; Thu, 06 Mar 2025 09:37:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741282623; x=1741887423; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=8+Gll0ED+LNY1L0uSucktPCRSzo+dnbdvmlAjyr9SHs=;
        b=mV2zLgQhSbkTHnF45KmMPq6y+xM5dzIWAnJ1Rg/V4QfnGORDOm3KCr6VikQ07GShWH
         Gh2+IFYTHmvwdGtXjUSF/bM0iXjPYbfZEw2JtENHu0RV51yYJinGAGWvio3twalBVCPs
         QsmBbUxP4bRJ0apRpCWniKk5Vk9JdjuQD6nfgK7FfD71rSBI+1+oJEDa6Zw1WWT8BrTo
         jJDa84nLulnd2KSiPZA36RfWZJYLxdG2highIASB8Lhx9ue0d0l/MdMU+tV3oA34a2nq
         w+YJJ6/4bAnCUQtD3rFwV+AEw1t8e0jiJLHr5Pu7Uns6ayiPWYZgH+f3z8UscM/4KtK1
         B86w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741282623; x=1741887423; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=8+Gll0ED+LNY1L0uSucktPCRSzo+dnbdvmlAjyr9SHs=;
        b=VFYHPUeybtUHvoQcMRcuuwVXlFe/PeegzirTQkOiyfiuHeaa2X4kCROR0MCTWmaa84
         qdYSkyaUdYAXm18I7N0XPnxs3w2Tm6xX5MKg6cIvNcUEBi3skC8iIRbX5JNRk93PXw44
         4dpBcdEYx5c0BexeHo6KkY6dIOPd/m93Oo1M+ecRBdwrNSTBQzN1vXFENNkq56HD1zuJ
         WCV8rqOFJ23yBjppwqGh3StXc0Py42y/yP12+mSk9q4OECLJ3RN0zCscXaDtaQPGbZXi
         Wysv8sU4xU97KWkQw+d5fyxd/Xwogqw3pTm4/Ols0Khvr9aB4lmWYBLVgYSYuvSua9hL
         zNEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741282623; x=1741887423;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=8+Gll0ED+LNY1L0uSucktPCRSzo+dnbdvmlAjyr9SHs=;
        b=ha60pc/F7ss+hSnwFbz6E2fUiwTWT2W1vD7OiPQsK5q7su5TDUWYQuKSdog41GSyPi
         4zWdv64vsYNy8d5Im5AP0SYtU3D7o2FHqSKjoa64iZz5eri5mdFvRsemIxdBSdw3ROnj
         bffXryP3svm6k1wLmelFr9C8lC4gHFWq4/mQY8wsL3zhyLw8zKTScsq7+hkW8gbJaIqE
         iGrb8PPNVILQNNRgf5dKl/9y+c4PKvRObIn7iJGDbQ+rijv6NYB+3ixZJnsO12NMCZN3
         likPyw8fFfwhN12HEyRHRxAJ0E551Fjs5etzlpI2h5R1r5ALatuQ641eMcZ1Wy3Z2y6t
         VtAg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXp2fr++6cI2m/j9OKURMPqXfnqLvxR/h4z07lcA7o1UI1toTw1szWC1g1JuVoCkL8Gt1UnXyQXVm8S@gnusha.org
X-Gm-Message-State: AOJu0Yy8vY81g3VhiF921l+aMsJq/Px8jwu+qe6WwQTsL11ksy+Tjpgv
	eF+yl27pMiTHuNQ1CHpSnOoXP37jSHGU0y39AiBwaNFIJxPmVQr1
X-Google-Smtp-Source: AGHT+IFotB7D6ByX4uD2vTaaEjTOwMfF+N5d2niQ7u7n/ci4Zj3PzhhquPrJvmP0l1gwV8Y2LJZHDg==
X-Received: by 2002:a05:6902:2e05:b0:e5e:1389:cb2f with SMTP id 3f1490d57ef6-e635c1f26b0mr238227276.45.1741282623330;
        Thu, 06 Mar 2025 09:37:03 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVHT/zvfv8YXNwiFNuUfErKUiCxIxPgSgzazPDnteQqR+w==
Received: by 2002:a25:5882:0:b0:e60:873d:ae8f with SMTP id 3f1490d57ef6-e63489dcd4dls1193402276.2.-pod-prod-09-us;
 Thu, 06 Mar 2025 09:36:59 -0800 (PST)
X-Received: by 2002:a05:690c:6f12:b0:6f9:b189:3ccb with SMTP id 00721157ae682-6febf2dff27mr3772697b3.17.1741282619616;
        Thu, 06 Mar 2025 09:36:59 -0800 (PST)
Received: by 2002:a05:690c:3388:b0:6ef:590d:3213 with SMTP id 00721157ae682-6fda287d365ms7b3;
        Thu, 6 Mar 2025 09:17:43 -0800 (PST)
X-Received: by 2002:a05:690c:6101:b0:6fb:9495:1650 with SMTP id 00721157ae682-6febf2c3b41mr2884117b3.11.1741281461984;
        Thu, 06 Mar 2025 09:17:41 -0800 (PST)
Date: Thu, 6 Mar 2025 09:17:41 -0800 (PST)
From: Greg Sanders <gsanders87@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com>
In-Reply-To: <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
 <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1082_1986608000.1741281461451"
X-Original-Sender: gsanders87@gmail.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 (/)

------=_Part_1082_1986608000.1741281461451
Content-Type: multipart/alternative; 
	boundary="----=_Part_1083_651608687.1741281461451"

------=_Part_1083_651608687.1741281461451
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Of course it depends on the specifics, but rewriting a clean interpreter=
=20
that we can actually reason about does not strike me as a necessarily=20
riskier approach than "just changing a few lines of code" in an interpreter=
=20
that hardly anyone knows how it really behaves in all cases.

It's certainly something to consider when weighing further off Bitcoin=20
Script updates: From here is something like "Great Script Restoration" ever=
=20
the right choice vs a from scratch overhaul? I am less persuaded that=20
consensus risk is particularly high for very narrowly scoped changes,=20
ignoring the "fixed" costs of changing consensus, maintenance burden, MEVil=
=20
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 wr=
ote:

> Hi,
>
> Just picking on one thing Laolu said:
>
> The current Overton Window appears to be focused on a small (LoC wise)=20
> package to enable a greater degree of permissionless innovation on Bitcoi=
n
>
>
> For what it's worth i'm not sure this is the correct focus. Bitcoin Scrip=
t=20
> is so notoriously unpredictable and hard to reason about that most of wha=
t=20
> matters is outside of the lines of code changed. Of course it depends on=
=20
> the specifics, but rewriting a clean interpreter that we can actually=20
> reason about does not strike me as a necessarily riskier approach than=20
> "just changing a few lines of code" in an interpreter that hardly anyone=
=20
> knows how it really behaves in all cases.
>
> Antoine
> On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <
> lao...@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:=
=20
>
> > This BIP introduces a simple covenant called a *template* which enables=
 a
> > limited set of highly valuable use cases without significant risk.=20
> BIP-119
> > templates allow for non-recursive fully-enumerated covenants with no
> > dynamic state.=20
>
> 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=20
> declared
> 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 indicatio=
n
> > 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=
=20
> into
> 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=20
> today
> (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 <a...@erisian.com.au=
> wrote:
>
>> Hello world,
>>
>> Some people on twitter are apparently proposing the near-term activation=
=20
>> 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=20
>> public
>> key.
>> * Calculate the CTV hash corresponding to a payment of some specific=20
>> value V
>> to K; call this hash H
>> * Calculate the BIP 340 signature for message H with private key X, call=
=20
>> it S.
>> * Discard the private key X
>> * Funds sent to K can only be spent by the witness data "<H> <S>" that=
=20
>> forwards
>> 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/20220719044...@erisian.com.au/=20
>> <https://gnusha.org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/=
>
>> [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/=20
>> <https://gnusha.org/pi/bitcoindev/87k0dwr015.fsf@rustcorp.com.au/>
>> [2]=20
>> https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@email=
.amazonses.com/=20
>> <https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16-43b0-81=
d2-4a82b580ba99-000000@email.amazonses.com/>
>> [3] https://x.com/Ethan_Heilman/status/1194624166093369345
>> [4] https://gnusha.org/pi/bitcoindev/2022021715...@erisian.com.au/=20
>> <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]=20
>> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#fil=
e-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]=20
>> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk=
.simf
>> [10]=20
>> 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
>>
>> --=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to bitcoindev+...@googlegroups.com.
>> To view this discussion visit=20
>> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.=
com.au
>> .
>>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
>
> To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQ=
jG6PMMXvgkzLwXgCHWxNV_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/=
17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com.

------=_Part_1083_651608687.1741281461451
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div>&gt;=C2=A0<span style=3D"font-family: Arial, sans-serif; color: rgb(0,=
 0, 0);">Of course it depends on the specifics, but rewriting a clean inter=
preter that we can actually reason about does not=C2=A0</span><span style=
=3D"font-family: Arial, sans-serif;">strike me as a necessarily riskier app=
roach than "just changing a few lines of code" in an interpreter that hardl=
y anyone knows how it really behaves in all cases.</span></div><div><div st=
yle=3D"font-family: Arial, sans-serif;"><br />It's certainly something to c=
onsider when weighing further off Bitcoin Script updates: From here is some=
thing like "Great Script Restoration" ever the right choice vs a from scrat=
ch overhaul? I am less persuaded that consensus risk is particularly high f=
or very narrowly scoped changes, ignoring the "fixed" costs of changing con=
sensus, maintenance burden, MEVil risks, etc. The risk-reward ratio may be =
suboptimal of course.</div><br /></div><div>Greg</div><div class=3D"gmail_q=
uote"><div dir=3D"auto" class=3D"gmail_attr">On Wednesday, March 5, 2025 at=
 11:39:27=E2=80=AFAM UTC-5 Antoine Poinsot wrote:<br/></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb=
(204, 204, 204); padding-left: 1ex;"><div style=3D"font-family:Arial,sans-s=
erif;font-size:14px">Hi,</div><div style=3D"font-family:Arial,sans-serif;fo=
nt-size:14px"><br></div><div style=3D"font-family:Arial,sans-serif;font-siz=
e:14px"></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">Ju=
st picking on 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;col=
or:rgb(102,102,102)"><div>The current Overton Window appears to be focused =
on a small (LoC wise) package to enable a greater degree of permissionless =
innovation on Bitcoin</div></blockquote><div><br></div></div><div style=3D"=
font-family:Arial,sans-serif;font-size:14px"><div><span style=3D"font-famil=
y:Arial,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);backgrou=
nd-color:rgb(255,255,255)">For what it&#39;s worth i&#39;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 the specifics, but rewriting a clean inter=
preter that we can actually reason about does not </span>strike me as a nec=
essarily riskier approach than &quot;just changing a few lines of code&quot=
; in an interpreter that hardly anyone knows how it really behaves in all c=
ases.<br><br>Antoine<br></div></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =20
            </div>
</div>
<div></div><div>
        On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun &lt;<a=
 href data-email-masked rel=3D"nofollow">lao...@gmail.com</a>&gt; wrote:<br=
>
        </div><div><blockquote type=3D"cite">
            <div dir=3D"ltr"><div>Hi AJ,<br><br>First a standard disclaimer=
: the contents of this email shouldn&#39;t be<br>interpreted as an endorsem=
ent of one covenants proposal over another.<br><br>&gt; Since BIP 119&#39;s=
 motivation is entirely concerned with its concept of<br>&gt; covenants and=
 avoiding what it calls recursive covenants<br><br>If we look at the motiva=
tion section of BIP 119, we find this sentence: <br><br>&gt; This BIP intro=
duces 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;=
 templates allow for non-recursive fully-enumerated covenants with no<br>&g=
t; dynamic state. <br><br>You appear to have latched onto the &quot;non-rec=
ursive&quot; aspect, ignoring the<br>subsequent qualifiers of &quot;fully-e=
numerated&quot; and &quot;with no dynamic state&quot;.<br><br>The example t=
hat you&#39;ve come up with to &quot;directly undermine&quot; the claimed<b=
r>motivations of BIP 119 is still fully enumerated (the sole state is decla=
red<br>up front), 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 s=
ignature S).<br><br>&gt; I found it pretty inconvenient, which I don&#39;t =
think is a good indication<br>&gt; of ecosystem readiness wrt deployment. (=
For me, the two components that<br>&gt; are annoying is doing complicated t=
aproot script path spends, and<br>&gt; calculating CTV hashes)<br><br>What =
language/libraries did you use to produce the spend? In my own<br>developme=
nt tooling of choice, producing complicated taproot script path<br>spends i=
s pretty straight forward, so perhaps the inconvenience you ran into<br>say=
s 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>deletio=
n, which if deemed acceptable, can be used to emulate CTV as is today<br>(t=
hough you can&#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; approach for the long term<br><br>Simplicity certainly has some brill=
iant devs working on it, but after all<br>these years it still seems to be =
struggling to exit research mode with some<br>&quot;killer apps&quot; on Li=
quid.<br><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 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<b=
r>some of the existing covenant proposals on the table (many of which have =
a<br>small core code footprint in the interpreter), they represent a radica=
lly<br>expanded scope (ecosystem changes, wallets, consensus code) and ther=
efore<br>additional risks. The current Overton Window appears to be focused=
 on a<br>small (LoC wise) package to enable a greater degree of permissionl=
ess<br>innovation on Bitcoin, while leaving the research landscape open for=
 more<br>dramatic overhauls (bllsh/Simplicity) in the future.<br><br>-- Lao=
lu<br></div><div><div data-smartmail=3D"gmail_signature" class=3D"gmail_sig=
nature" dir=3D"ltr"><div dir=3D"ltr"><br></div></div></div></div><br><div c=
lass=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"ltr">On Tue, Mar 4, 2=
025 at 5:06=E2=80=AFPM Anthony Towns &lt;<a href rel=3D"noreferrer nofollow=
 noopener" data-email-masked>a...@erisian.com.au</a>&gt; wrote:<br></div><b=
lockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex" class=3D"gmail_quote">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>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/JeremyRubin/=
status/1895676912401252588" target=3D"_blank" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://x.com/JeremyRubin/status/1895=
676912401252588&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOv=
Vaw3HlNHoFlM78lbDP0CNmOxr">https://x.com/JeremyRubin/status/189567691240125=
2588</a><br>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/lopp/status/=
1895837290209161358" target=3D"_blank" data-saferedirecturl=3D"https://www.=
google.com/url?hl=3Den&amp;q=3Dhttps://x.com/lopp/status/189583729020916135=
8&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw0SF_Id45F_a=
6rN04L8QVvL">https://x.com/lopp/status/1895837290209161358</a><br>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/stevenroose3=
/status/1895881757288996914" target=3D"_blank" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Den&amp;q=3Dhttps://x.com/stevenroose3/status/18=
95881757288996914&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DA=
OvVaw3vROxWHd7Q34fcCnXHQcYJ">https://x.com/stevenroose3/status/189588175728=
8996914</a><br>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/reardencode/=
status/1871343039123452340" target=3D"_blank" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Den&amp;q=3Dhttps://x.com/reardencode/status/1871=
343039123452340&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOv=
Vaw2Ns0_6hYGXT4r2or_aaiMa">https://x.com/reardencode/status/187134303912345=
2340</a><br>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/sethforpriva=
cy/status/1895814836535378055" target=3D"_blank" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Den&amp;q=3Dhttps://x.com/sethforprivacy/statu=
s/1895814836535378055&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=
=3DAOvVaw2gHRrld4WLPfWJQ7krOwxl">https://x.com/sethforprivacy/status/189581=
4836535378055</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>
 * Make a throwaway BIP340 private key X with 32-bit public key P.<br>
 * Calculate the tapscript &quot;OP_OVER &lt;P&gt; OP_CSFS OP_VERIFY OP_CTV=
&quot;, and<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 &quot;&lt;H&gt; &l=
t;S&gt;&quot; that forwards<br>
   an amount V straight back to K.<br>
<br>
Here&#39;s a demonstration on mutinynet:<br>
<br>
 <a rel=3D"noreferrer nofollow noopener" href=3D"https://mutinynet.com/addr=
ess/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58" target=
=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;=
q=3Dhttps://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tzn=
myjejrmqqx525gsk5nr58&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=
=3DAOvVaw1_K5mZrFaWqfrDcJpfipwC">https://mutinynet.com/address/tb1p0p5027sh=
f4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58</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>
 - the things it describes are, in general, not &quot;covenants&quot; [0]<b=
r>
 - the thing it avoids is not &quot;recursion&quot; but unbounded recursion=
<br>
 - avoiding unbounded recursion is not very interesting when arbitrarily<br=
>
   large recursion is still possible [1]<br>
 - despite claiming that &quot;covenants have historically been widely<br>
   considering to be unfit for Bitcoin&quot;, no evidence for this claim ha=
s<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&#39;s motivat=
ion<br>
section would be an improvement...<br>
<br>
[0] <a rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.org/pi/b=
itcoindev/20220719044458.GA26986@erisian.com.au/" target=3D"_blank" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.=
org/pi/bitcoindev/20220719044458.GA26986@erisian.com.au/&amp;source=3Dgmail=
&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw1UOtcsLAyvZSV-p6mmAmfQ">https:/=
/gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/</a><br>
[1] <a rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.org/pi/b=
itcoindev/87k0dwr015.fsf@rustcorp.com.au/" target=3D"_blank" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.org/pi/=
bitcoindev/87k0dwr015.fsf@rustcorp.com.au/&amp;source=3Dgmail&amp;ust=3D174=
1365406084000&amp;usg=3DAOvVaw1D2V601pLw3C9DCkIjaX7w">https://gnusha.org/pi=
/bitcoindev/87k0dwr...@rustcorp.com.au/</a><br>
[2] <a rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.org/pi/b=
itcoindev/0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@emai=
l.amazonses.com/" target=3D"_blank" data-saferedirecturl=3D"https://www.goo=
gle.com/url?hl=3Den&amp;q=3Dhttps://gnusha.org/pi/bitcoindev/0100017ee6472e=
02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com/&amp;sou=
rce=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw25cD8vTK_qWCABZYNggw=
zm">https://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@emai=
l.amazonses.com/</a><br>
[3] <a rel=3D"noreferrer nofollow noopener" href=3D"https://x.com/Ethan_Hei=
lman/status/1194624166093369345" target=3D"_blank" data-saferedirecturl=3D"=
https://www.google.com/url?hl=3Den&amp;q=3Dhttps://x.com/Ethan_Heilman/stat=
us/1194624166093369345&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;us=
g=3DAOvVaw2TqRs28pL4YMruwNY8mocF">https://x.com/Ethan_Heilman/status/119462=
4166093369345</a><br>
[4] <a rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.org/pi/b=
itcoindev/20220217151528.GC1429@erisian.com.au/" target=3D"_blank" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gnusha.o=
rg/pi/bitcoindev/20220217151528.GC1429@erisian.com.au/&amp;source=3Dgmail&a=
mp;ust=3D1741365406084000&amp;usg=3DAOvVaw3kr9R0VGqChAdkmyR4iwJd">https://g=
nusha.org/pi/bitcoindev/2022021715...@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 rel=3D"noreferrer nofollow noopener" href=3D"https://gist.github.com=
/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg" target=3D"_blan=
k" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps=
://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5%23file-bmm-=
svg&amp;source=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw3fa4Kk7Z_=
P63pjjiOO-hzK">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34=
906b16a5#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>
   (=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 rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/ajto=
wns/bllsh/" target=3D"_blank" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Den&amp;q=3Dhttps://github.com/ajtowns/bllsh/&amp;source=3Dgmail&=
amp;ust=3D1741365406084000&amp;usg=3DAOvVaw0b7I5vevGDwRuYS5E3aEZu">https://=
github.com/ajtowns/bllsh/</a><br>
[7] <a rel=3D"noreferrer nofollow noopener" href=3D"https://delvingbitcoin.=
org/t/debuggable-lisp-scripts/1224" target=3D"_blank" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t=
/debuggable-lisp-scripts/1224&amp;source=3Dgmail&amp;ust=3D1741365406084000=
&amp;usg=3DAOvVaw1Ggx0Zs8Ge7ERCSgLlQklJ">https://delvingbitcoin.org/t/debug=
gable-lisp-scripts/1224</a><br>
[8] <a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/ajto=
wns/bllsh/blob/master/examples/test-tx" target=3D"_blank" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/ajtown=
s/bllsh/blob/master/examples/test-tx&amp;source=3Dgmail&amp;ust=3D174136540=
6084000&amp;usg=3DAOvVaw1I-1TMO1oTR0ebwlgLQPl9">https://github.com/ajtowns/=
bllsh/blob/master/examples/test-tx</a><br>
[9] <a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/Bloc=
kstreamResearch/simfony/blob/master/examples/p2pk.simf" target=3D"_blank" d=
ata-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://g=
ithub.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf&amp;so=
urce=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw3P1RHXKpP50XWPMSi7C=
s-C">https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2=
pk.simf</a><br>
[10] <a rel=3D"noreferrer nofollow noopener" href=3D"https://github.com/Blo=
ckstreamResearch/simfony/blob/master/examples/ctv.simf" target=3D"_blank" d=
ata-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://g=
ithub.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf&amp;sou=
rce=3Dgmail&amp;ust=3D1741365406084000&amp;usg=3DAOvVaw3MIwH7SdLNmyI_yns-40=
bQ">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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
To view this discussion visit <a rel=3D"noreferrer nofollow noopener" href=
=3D"https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian=
.com.au" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/u=
rl?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjd=
ivIzn%2540erisian.com.au&amp;source=3Dgmail&amp;ust=3D1741365406085000&amp;=
usg=3DAOvVaw23Sjh7G9lr5639T6bKhQAL">https://groups.google.com/d/msgid/bitco=
indev/Z8eUQCfCWjdivIzn%40erisian.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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br></blockquote></div><div><blockquote typ=
e=3D"cite">
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail=
.com" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.=
com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%=
2540mail.gmail.com&amp;source=3Dgmail&amp;ust=3D1741365406085000&amp;usg=3D=
AOvVaw1h-b_Jb7d9tJ1bw9ybsBhh">https://groups.google.com/d/msgid/bitcoindev/=
CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com</a>.<b=
r>

        </blockquote><br>
    </div></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/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.com</a>.<br />

------=_Part_1083_651608687.1741281461451--

------=_Part_1082_1986608000.1741281461451--