path: root/ef/e43dcc1c44a3a3e1b38c0f6135a000c97cda2d

Delivery-date: Thu, 06 Mar 2025 13:27:19 -0800
Received: from mail-yw1-f190.google.com ([209.85.128.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBLFGVC7AMGQEC5J2R6A@googlegroups.com>)
	id 1tqIkO-0003U2-Nw
	for bitcoindev@gnusha.org; Thu, 06 Mar 2025 13:27:19 -0800
Received: by mail-yw1-f190.google.com with SMTP id 00721157ae682-6fd779c17efsf30984767b3.0
        for <bitcoindev@gnusha.org>; Thu, 06 Mar 2025 13:27:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1741296431; x=1741901231; 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=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=;
        b=B0/iVkGCra3hQXLNNmDPPIBRbFkUsf5xzwvbT2S06o2f49cS/Vl8QZ4nLOJzXVnKiu
         Fihsy31iFLnxwidf5vbbdxzsLA/fWDs/XA6q0il93CVz63x4gAvyGNpnrHFApZfOFUYq
         8k34kReFd285fjVj0apazxnhq5GhrypMkegsuX7QOpVDuk8uIBvjJwIxV4w3otCAwVEV
         ZhILj8Q36IBjXMdYeZt1o8r/eu8OQu1WKzXvedo0cKh19zlue72qWhrO557+VLbkhMAT
         HS3Jhi+qcmxKj7s0PRUtUjPa/PQbh9vT0fLpS0DDstAGEPvF+FzLJ6cph0prxUSb5Q6X
         CeNw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1741296431; x=1741901231; 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=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=;
        b=N+WK3n6wH6vJw1WHNjYvBWTvZSD626TGtXx5lP4uUUekBjdSEr+YykWqoxZmIBkQFX
         s8oS90GYbHQGck2pjNqErrrOc0OC5bDSpjaae2kJaLBt/skAHJ+DKTcU1Sf+ITJS2Hji
         JjSjubIpP6OwH9WDnA6z0pP5CjEdqE1ePRy1uZzl4nbhlBQeWk1oHsVbJsX3rBwc96Y2
         DYWCc0w0sX7S141NJ6LA8TfCIMoSaMwexnENO3HYIKdFXb7+dYVxeNn6Lp9akgNaUPBG
         xQKG9qwOkFqXAV9QYmiM+y5uykzkgpsrPvXEknZKyxgqSpyNHdaB+QedOzkwx9DLHNqR
         6SCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1741296431; x=1741901231;
        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=ybfBOz4FG6gub+wMRQoagWo2hmG9jFCHQCTGCnHflEo=;
        b=LP42tqtsq4VVOnyEdfESTjW9RmgViesiwTWwhrxA44GSDSlcql9i3sLIB6ME6JF6oR
         rneXRuO3/4w8mGybF5O6QREcu3WhCSj4qiMh8depg/q/8HCb5nFPeEmR2Vrips4Mbex+
         KlnL9OWDHqHGLf81T8iqkdMdj5Np4TXTNr8eJSbeFGEacID/3durQg/nA3XbzkgDyHGb
         dR46LdCYhjW8NA2kM6FG+AfHWj+5KVoxJeKf1diFAQ9QmO1irAPrpoNTpim3RILFCf+r
         B5FpiktKrdHxj8YooFLlTIo4lOX6KujRRCGDkwHXLw2Rw5eEbFUAELZEV+Ir/f/fzlE5
         c7pA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCX5qFW3UUQ3JqFggvpMqKBYaw18zO7QrETL4waZ95dgtIOG7oJyBmmIL+xzOD0GkD78kcycq+Avxvlh@gnusha.org
X-Gm-Message-State: AOJu0YxsM/4xehlkpOYTH8TiVOBIWfvquiJJKuKGZkSg86qcqHCHB0r3
	nzB/BD8TSvUW66J6fxOK0Zx1L0jNkCaT2LMKWIWZDfEnFnQt2nUe
X-Google-Smtp-Source: AGHT+IG8fbwmGusBfgvuF7FnQxKBTqcKROeKtEYpCXuDbY26RHWOz1b4qrSIK3j2D/VLpWq7xvj49A==
X-Received: by 2002:a05:6902:2101:b0:e60:e14a:df7b with SMTP id 3f1490d57ef6-e634793fc80mr6949396276.12.1741296430853;
        Thu, 06 Mar 2025 13:27:10 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVFh9XyrQ/kbtPYulwY+Nnww5Vr1WYih2EIAo2px/t+xSg==
Received: by 2002:a25:264b:0:b0:e5b:3877:6d59 with SMTP id 3f1490d57ef6-e6347ead2c9ls1550066276.0.-pod-prod-05-us;
 Thu, 06 Mar 2025 13:27:08 -0800 (PST)
X-Received: by 2002:a05:690c:6382:b0:6fb:ab27:5748 with SMTP id 00721157ae682-6febf3aea3bmr15032627b3.33.1741296428078;
        Thu, 06 Mar 2025 13:27:08 -0800 (PST)
Received: by 2002:a05:690c:c92:b0:6fe:b496:fc0e with SMTP id 00721157ae682-6feb4970ec6ms7b3;
        Thu, 6 Mar 2025 13:26:25 -0800 (PST)
X-Received: by 2002:a05:690c:6088:b0:6f5:2793:2897 with SMTP id 00721157ae682-6febf37b72bmr16291757b3.30.1741296383533;
        Thu, 06 Mar 2025 13:26:23 -0800 (PST)
Date: Thu, 6 Mar 2025 13:26:23 -0800 (PST)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn@googlegroups.com>
In-Reply-To: <Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9YSgZpC013Lj4SI_WZR0N1iwbUiNze00tA=@protonmail.com>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
 <1JkExwyWEPJ9wACzdWqiu5cQ5WVj33ex2XHa1J9Uyew-YF6CLppDrcu3Vogl54JUi1OBExtDnLoQhC6TYDH_73wmoxi1w2CwPoiNn2AcGeo=@protonmail.com>
 <17e7eb49-77b7-4f2f-be40-a6649e610ce5n@googlegroups.com>
 <Gfgs0GeY513WBZ1FueJBVhdl2D-8QD2NqlBaP0RFGErYbHLE-dnFBN_rbxnTwzlolzpjlx0vo9YSgZpC013Lj4SI_WZR0N1iwbUiNze00tA=@protonmail.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_40072_1428590326.1741296383124"
X-Original-Sender: antoine.riard@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_40072_1428590326.1741296383124
Content-Type: multipart/alternative; 
	boundary="----=_Part_40073_468764918.1741296383124"

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

Hi all,

> After that, one can build a script:=20
<proof-of-target-UTXO-mining=3Dcommitment_tx"
> OP_CSFS> OR <<bounty_timelock> <OP_CHECKLOCKTIMEVERIFY>=20
<recursive_bounty_sig |
> SIGHASH_SINGLE> OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold attacker=
=20
can
> make the funding UTXO amount available as a "anyone-can-spend" and force=
=20
a re-
> commitment to the same tx-withholding script.

Correcting myself, after more thinking I believe to get a non-forgeable=20
"proof-of
-target-UTXO-mining" there should be a merkle branch proof of the txid back=
=20
to
the mined block. Otherwise, any participant in the target UTXO /=20
transaction (e.g
a LN channel) can confirm the target transaction to execute the contracting=
=20
protocol
according to its semantics _and_ generate the "proof-of-target-UTXO-mining"=
=20
to
claim the "anyone-can-spend" bribing output.

So to do a merkle branch proof, script would have to be of the rough form=
=20
e.g:
< <leaf_node_ab> <OP_SHA256> <OP_CAT> <leaf_node_cd> <OP_SHA256> <OP_CAT>,=
=20
or
any equivalent opcode primitive allowing to get concatenation in the script=
.

For the design of a TxWithhold, all that you wish is a proof-of-existence=
=20
of a
block B + transaction T (in the mathematical sense). That way if a timelock=
=20
is
reached after X blocks, and no proof-of-existence as been brought until=20
then,
this logically implies that B + T do not exist. Or at least have not been=
=20
published,
which for the purpose of the chain being the publication space and=20
anti-double-spend
oracle of UTXO spends is the same.

I don't believe with OP_CHECKSIGFROMSTACK alone you can build such=20
proof-of-target-UTXO
-mining, though I'm not sure of such statement. All cov primitives=20
proposals are coming
without formal analysis of the limits of the expressivity extensions, there=
=20
has been
progress since OP_EVAL, though it's always tooling on a subset of current=
=20
Bitcoin
Script not extension.

At the very least, and in reference to what is described in naumenkogs's=20
original
TxWithhold article, the introduction of OP_CSFS let you have m-of-n oracles=
=20
doing
attestations in the script that a block has been confirmed, eventually with=
=20
a tx.
This is already a powerful building block for TxWithhold. At first thought,=
=20
I don't
see how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design=
=20
the scope
is reduced.

On the distinction between execution risks with crypto-economic incentives=
=20
risks
brought by some on this thread, this is unclear what is meant exactly. Of=
=20
course
with execution risks, it might more think affecting full-node security (e.g=
=20
a DoS
vector, reason a lot of opcodes were disabled back in ~2010), though it=20
could be
just a risk of misuage of the primitive by use-cases toolchain (e.g=20
generating=20
a consensus-invalid tx due to misuse of the timelock flags) or an attack=20
driven
by crypto-ecnomic incentives (e.g selfish-mining or block-withholding=20
attack at
the miner-level). Though even for a simple DoS, one can evaluate the CPU /=
=20
bandwidth
cost in quantitative terms to gauge if it's a serious risk, there is an=20
area of
uncertainty, or it's not a risk.

When we we talk about security risks, one has to see things that it's more=
=20
a continuum,
where an attacker vector can be used as a building block for more=20
sophisticated
attacks. In the original bitcoin paper, crypto-incentives themselves are=20
weighted
to evaluate the soundness of the system in section 6. and in section 11.

Best,
Antoine
OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d7b4d448f2895a1b70b2886e9d8

Le jeudi 6 mars 2025 =C3=A0 19:03:48 UTC, moonsettler a =C3=A9crit :

> Hi All,
>
> > I am less persuaded that consensus risk is particularly high for very=
=20
> narrowly scoped changes
> Agreed.
>
> Some people out there seem to conflate execution risks with=20
> crypto-economic incentives risks.
> Better designed script systems obviously reduce execution risks and=20
> unintended consensus failure risks and make maintenance easier.
> They also quiet easily blow the lid off other types of risks by nature of=
=20
> being better and more capable.
>
> Paradoxically the more expressive bitcoin script becomes over time, the=
=20
> less likely that a script system overhaul comes with a nasty surprise.
>
> BR,
> moonsettler
>
>
> On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders <gsand...@gmail.com=
>=20
> wrote:
>
> > > Of course it depends on the specifics, but rewriting a clean=20
> interpreter that we can actually reason about does not strike me as a=20
> necessarily riskier approach than "just changing a few lines of code" in =
an=20
> interpreter that hardly anyone knows how it really behaves in all cases.
> >=20
> > It's certainly something to consider when weighing further off Bitcoin=
=20
> Script updates: From here is something like "Great Script Restoration" ev=
er=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, MEV=
il=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 Poinso=
t 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=20
> wise) package to enable a greater degree of permissionless innovation on=
=20
> Bitcoin
> > >=20
> > >=20
> > > For what it's worth i'm not sure this is the correct focus. Bitcoin=
=20
> Script is so notoriously unpredictable and hard to reason about that most=
=20
> of what matters is outside of the lines of code changed. Of course it=20
> depends on the specifics, but rewriting a clean interpreter that we can=
=20
> actually reason about does not strike me as a necessarily riskier approac=
h=20
> than "just changing a few lines of code" in an interpreter that hardly=20
> anyone knows how it really behaves in all cases.
> > >=20
> > > Antoine
> > >=20
> > > On Wednesday, March 5th, 2025 at 1:14 AM, Olaoluwa Osuntokun <
> lao...@gmail.com> wrote:
> > >=20
> > > > Hi AJ,
> > > >=20
> > > > First a standard disclaimer: the contents of this email shouldn't b=
e
> > > > interpreted as an endorsement of one covenants proposal over anothe=
r.
> > > >=20
> > > > > Since BIP 119's motivation is entirely concerned with its concept=
=20
> of
> > > > > covenants and avoiding what it calls recursive covenants
> > > >=20
> > > > If we look at the motivation section of BIP 119, we find this=20
> sentence:
> > > >=20
> > > > > This BIP introduces a simple covenant called a *template* which=
=20
> enables a
> > > > > limited set of highly valuable use cases without significant risk=
.=20
> BIP-119
> > > > > templates allow for non-recursive fully-enumerated covenants with=
=20
> no
> > > > > dynamic state.
> > > >=20
> > > > You appear to have latched onto the "non-recursive" aspect, ignorin=
g=20
> the
> > > > subsequent qualifiers of "fully-enumerated" and "with no dynamic=20
> state".
> > > >=20
> > > > The example that you've come up with to "directly undermine" the=20
> 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=20
> contract 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=20
> indication
> > > > > of ecosystem readiness wrt deployment. (For me, the two component=
s=20
> 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=
=20
> path
> > > > spends is pretty straight forward, so perhaps the inconvenience you=
=20
> ran into
> > > > says more about your dev tooling than the ecosystem readiness.
> > > >=20
> > > > It's also worth pointing out that your example relies on private ke=
y
> > > > deletion, which if deemed acceptable, can be used to emulate CTV as=
=20
> is 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 desig=
n
> > > > > approach for the long term
> > > >=20
> > > > Simplicity certainly has some brilliant devs working on it, but=20
> after all
> > > > these years it still seems to be struggling to exit research mode=
=20
> with 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=
=20
> seems
> > > > rather premature to promote it as a long term solution.
> > > >=20
> > > > Both of them are effectively a complete rewrite of Script, so=20
> compared to
> > > > some of the existing covenant proposals on the table (many of which=
=20
> have a
> > > > small core code footprint in the interpreter), they represent a=20
> radically
> > > > expanded scope (ecosystem changes, wallets, consensus code) and=20
> therefore
> > > > additional risks. The current Overton Window appears to be focused=
=20
> on a
> > > > small (LoC wise) package to enable a greater degree of permissionle=
ss
> > > > innovation on Bitcoin, while leaving the research landscape open fo=
r=20
> 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.=
com.au>=20
> wrote:
> > > >=20
> > > > > Hello world,
> > > > >=20
> > > > > Some people on twitter are apparently proposing the near-term=20
> activation 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=
=20
> of
> > > > > covenants and avoiding what it calls recursive covenants, I think=
=20
> it
> > > > > is interesting to note that the combination of CSFS and CTV=20
> trivially
> > > > > enables the construction of a "recursive covenant" as BIP 119 use=
s=20
> 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",=
=20
> and
> > > > > its corresponding scriptPubKey K when combined with P as the=20
> internal public
> > > > > key.
> > > > > * Calculate the CTV hash corresponding to a payment of some=20
> specific value V
> > > > > to K; call this hash H
> > > > > * Calculate the BIP 340 signature for message H with private key=
=20
> X, call it S.
> > > > > * Discard the private key X
> > > > > * Funds sent to K can only be spent by the witness data "<H> <S>"=
=20
> that forwards
> > > > > an amount V straight back to K.
> > > > >=20
> > > > > Here's a demonstration on mutinynet:
> > > > >=20
> > > > >=20
> https://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33tznmy=
jejrmqqx525gsk5nr58
> > > > >=20
> > > > > I'd encourage people to try implementing that themselves with the=
ir
> > > > > preferred tooling; personally, I found it pretty inconvenient,=20
> which I
> > > > > don't think is a good indication of ecosystem readiness wrt=20
> deployment.
> > > > > (For me, the two components that are annoying is doing complicate=
d
> > > > > taproot script path spends, and calculating CTV hashes)
> > > > >=20
> > > > > I don't believe the existence of a construction like this poses a=
ny
> > > > > problems in practice, however if there is going to be a push to=
=20
> activate
> > > > > BIP 119 in parallel with features that directly undermine its=20
> claimed
> > > > > motivation, then it would presumably be sensible to at least upda=
te
> > > > > the BIP text to describe a motivation that would actually be=20
> achieved 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=20
> 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=
=20
> has
> > > > > been able to be provided [2,3]
> > > > > - the opposition to unbounded recursion seems to me to either=20
> mostly
> > > > > or entirely be misplaced fear of things that are already possible=
=20
> in
> > > > > 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=
=20
> motivation
> > > > > section would be an improvement...
> > > > >=20
> > > > > [0]=20
> https://gnusha.org/pi/bitcoindev/20220719044...@erisian.com.au/
> > > > > [1] https://gnusha.org/pi/bitcoindev/87k0dwr...@rustcorp.com.au/
> > > > > [2]=20
> 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 motivatio=
n
> > > > > section, I think the above script could be useful in the context=
=20
> of the
> > > > > "blind-merged-mining" component of spacechains [5]. For example, =
if
> > > > > the commitment was to two outputs, one the recursive step and the=
=20
> other
> > > > > being a 0sat ephemeral anchor, then the spend of the ephemeral=20
> anchor
> > > > > would allow for both providing fees conveniently and for encoding=
=20
> the
> > > > > spacechain block's commitment; competing spacechain miners would=
=20
> then
> > > > > just be rbf'ing that spend with the parent spacechain update=20
> remaining
> > > > > unchanged. The "nLockTime" and "sequences_hash" commitment in CTV=
=20
> would
> > > > > need to be used to ensure the "one spacechain update per bitcoin=
=20
> block"
> > > > > rule. (I believe mutinynet doesn't support ephemeral anchors=20
> however, so
> > > > > I don't think there's anywhere this can be tested)
> > > > >=20
> > > > > [5]=20
> https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5#file=
-bmm-svg
> > > > >=20
> > > > > (For a spacechain, miners would want to be confident that the=20
> private key
> > > > > has been discarded. This confidence could be enhanced by creating=
=20
> X as a
> > > > > musig2 key by a federation, in which case provided any of the=20
> private keys
> > > > > used in generating X were correctly discarded, then everything is=
=20
> fine,
> > > > > but that's still a trust assumption. Simple introspection opcodes=
=20
> would
> > > > > work far better for this use case, both removing the trust=20
> assumption
> > > > > and reducing the onchain data required)
> > > > >=20
> > > > > If you're providing CTV and CSFS anyway, I don't see why you=20
> wouldn't
> > > > > provide the same or similar functionality via a SIGHASH flag so=
=20
> that you
> > > > > can avoid specifying the hash directly when you're signing it=20
> anyway,
> > > > > giving an ANYPREVOUT/NOINPUT-like feature directly.
> > > > >=20
> > > > > (Likewise, I don't see why you'd want to activate CAT on mainnet=
=20
> without
> > > > > also at least re-enabling SUBSTR, and potentially also the=20
> redundant
> > > > > LEFT and RIGHT operations)
> > > > >=20
> > > > > For comparison, bllsh [6,7] takes the approach of providing
> > > > > "bip340_verify" (directly equivalent to CSFS), "ecdsa_verify"=20
> (same but
> > > > > for ECDSA rather than schnorr), "bip342_txmsg" and "tx" opcodes. =
A=20
> 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=20
> SIGHASH_SINGLE,
> > > > > then evaluate whether the result is exactly equal to this constan=
t"
> > > > > providing one of the standard sighashes worked for your use case,=
=20
> or
> > > > > replacing the bip342_txmsg opcode with a custom calculation of th=
e=20
> tx
> > > > > hash, along the lines of the example reimplementation of=20
> bip342_txmsg
> > > > > for SIGHASH_ALL [8] in the probably more likely case that it=20
> 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=20
> pretty
> > > > > straightforward conversion from the test-tx example.
> > > > >=20
> > > > > If bllsh were live today (eg on either signet or mainnet), and it=
=20
> were
> > > > > desired to softfork in a more optimised implementation of either=
=20
> CTV or
> > > > > ANYPREVOUT to replace people coding their own implementation in=
=20
> bllsh
> > > > > directly, both would simply involve replacing calls to=20
> "bip342_txmsg"
> > > > > with calls to a new hash calculation opcode. For CTV behaviour,=
=20
> usage
> > > > > would look like "(=3D (bipXXX_txmsg) 0x...)" as above; for APO=20
> behaviour,
> > > > > usage would look like "(bip340_verify KEY (bipXXX_txmsg) SIG)".=
=20
> That
> > > > > is, the underlying "I want to hash a message in such-and-such a=
=20
> 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=
=20
> way;
> > > > > with "jet::bip_0340_verify" taking a tx hash for SIGHASH-like=20
> behaviour
> > > > > [9], or "jet::eq_256" comparing a tx hash and a constant for=20
> CTV-like
> > > > > 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]=20
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.=
simf
> > > > > [10]=20
> https://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.s=
imf
> > > > >=20
> > > > > For me, the bllsh/simplicity approach makes more sense as a desig=
n
> > > > > approach for the long term, and the ongoing lack of examples of=
=20
> killer
> > > > > apps demonstrating big wins from limited slices of new=20
> functionality
> > > > > leaves me completely unexcited about rushing something in the=20
> short term.
> > > > > Having a flood of use cases that don't work out when looked into=
=20
> isn'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 Googl=
e=20
> Groups "Bitcoin Development Mailing List" group.
> > > > > To unsubscribe from this group and stop receiving emails from it,=
=20
> send an email to bitcoindev+...@googlegroups.com.
> > > > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.c=
om.au
> .
> > > >=20
> > > > --
> > > > You received this message because you are subscribed to the Google=
=20
> Groups "Bitcoin Development Mailing List" group.
> > > > To unsubscribe from this group and stop receiving emails from it,=
=20
> send an email to bitcoindev+...@googlegroups.com.
> > >=20
> > > > 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=20
> Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to bitcoindev+...@googlegroups.com.
> > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a664=
9e610ce5n%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/=
7535451a-d92a-44fb-9ce1-bc0c8ea4e73bn%40googlegroups.com.

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

Hi all,<br /><br />&gt; After that, one can build a script: &lt;proof-of-ta=
rget-UTXO-mining=3Dcommitment_tx"<br />&gt; OP_CSFS&gt; OR &lt;&lt;bounty_t=
imelock&gt; &lt;OP_CHECKLOCKTIMEVERIFY&gt; &lt;recursive_bounty_sig |<br />=
&gt; SIGHASH_SINGLE&gt; OP_CHECKSIG. Using SIGHASH_SINGLE the TxWithhold at=
tacker can<br />&gt; make the funding UTXO amount available as a "anyone-ca=
n-spend" and force a re-<br />&gt; commitment to the same tx-withholding sc=
ript.<br /><br />Correcting myself, after more thinking I believe to get a =
non-forgeable "proof-of<br />-target-UTXO-mining" there should be a merkle =
branch proof of the txid back to<br />the mined block. Otherwise, any parti=
cipant in the target UTXO / transaction (e.g<br />a LN channel) can confirm=
 the target transaction to execute the contracting protocol<br />according =
to its semantics _and_ generate the "proof-of-target-UTXO-mining" to<br />c=
laim the "anyone-can-spend" bribing output.<br /><br />So to do a merkle br=
anch proof, script would have to be of the rough form e.g:<br />&lt; &lt;le=
af_node_ab&gt; &lt;OP_SHA256&gt; &lt;OP_CAT&gt; &lt;leaf_node_cd&gt; &lt;OP=
_SHA256&gt; &lt;OP_CAT&gt;, or<br />any equivalent opcode primitive allowin=
g to get concatenation in the script.<br /><br />For the design of a TxWith=
hold, all that you wish is a proof-of-existence of a<br />block B + transac=
tion T (in the mathematical sense). That way if a timelock is<br />reached =
after X blocks, and no proof-of-existence as been brought until then,<br />=
this logically implies that B + T do not exist. Or at least have not been p=
ublished,<br />which for the purpose of the chain being the publication spa=
ce and anti-double-spend<br />oracle of UTXO spends is the same.<br /><br /=
>I don't believe with OP_CHECKSIGFROMSTACK alone you can build such proof-o=
f-target-UTXO<br />-mining, though I'm not sure of such statement. All cov =
primitives proposals are coming<br />without formal analysis of the limits =
of the expressivity extensions, there has been<br />progress since OP_EVAL,=
 though it's always tooling on a subset of current Bitcoin<br />Script not =
extension.<br /><br />At the very least, and in reference to what is descri=
bed in naumenkogs's original<br />TxWithhold article, the introduction of O=
P_CSFS let you have m-of-n oracles doing<br />attestations in the script th=
at a block has been confirmed, eventually with a tx.<br />This is already a=
 powerful building block for TxWithhold. At first thought, I don't<br />see=
 how you can have the equivalent with OP_CHECKTEMPLATEVERIFY, by design the=
 scope<br />is reduced.<br /><br />On the distinction between execution ris=
ks with crypto-economic incentives risks<br />brought by some on this threa=
d, this is unclear what is meant exactly. Of course<br />with execution ris=
ks, it might more think affecting full-node security (e.g a DoS<br />vector=
, reason a lot of opcodes were disabled back in ~2010), though it could be<=
br />just a risk of misuage of the primitive by use-cases toolchain (e.g ge=
nerating <br />a consensus-invalid tx due to misuse of the timelock flags) =
or an attack driven<br />by crypto-ecnomic incentives (e.g selfish-mining o=
r block-withholding attack at<br />the miner-level). Though even for a simp=
le DoS, one can evaluate the CPU / bandwidth<br />cost in quantitative term=
s to gauge if it's a serious risk, there is an area of<br />uncertainty, or=
 it's not a risk.<br /><br />When we we talk about security risks, one has =
to see things that it's more a continuum,<br />where an attacker vector can=
 be used as a building block for more sophisticated<br />attacks. In the or=
iginal bitcoin paper, crypto-incentives themselves are weighted<br />to eva=
luate the soundness of the system in section 6. and in section 11.<br /><br=
 />Best,<br />Antoine<br />OTS hash: 2c3e2e41ed67484f5d58138413cfca7f0aba5d=
7b4d448f2895a1b70b2886e9d8<br /><br /><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">Le jeudi 6 mars 2025 =C3=A0 19:03:48 UTC, mo=
onsettler a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); pad=
ding-left: 1ex;">Hi All,
<br>
<br>&gt; I am less persuaded that consensus risk is particularly high for v=
ery narrowly scoped changes
<br>Agreed.
<br>
<br>Some people out there seem to conflate execution risks with crypto-econ=
omic incentives risks.
<br>Better designed script systems obviously reduce execution risks and uni=
ntended consensus failure risks and make maintenance easier.
<br>They also quiet easily blow the lid off other types of risks by nature =
of being better and more capable.
<br>
<br>Paradoxically the more expressive bitcoin script becomes over time, the=
 less likely that a script system overhaul comes with a nasty surprise.
<br>
<br>BR,
<br>moonsettler
<br>
<br>
<br>On Thursday, March 6th, 2025 at 6:17 PM, Greg Sanders &lt;<a href data-=
email-masked rel=3D"nofollow">gsand...@gmail.com</a>&gt; wrote:
<br>
<br>&gt; &gt; Of course it depends on the specifics, but rewriting a clean =
interpreter that we can actually reason about does not strike me as a neces=
sarily 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 cas=
es.
<br>&gt;=20
<br>&gt; It&#39;s certainly something to consider when weighing further off=
 Bitcoin Script updates: From here is something like &quot;Great Script Res=
toration&quot; ever the right choice vs a from scratch overhaul? I am less =
persuaded that consensus risk is particularly high for very narrowly scoped=
 changes, ignoring the &quot;fixed&quot; costs of changing consensus, maint=
enance burden, MEVil risks, etc. The risk-reward ratio may be suboptimal of=
 course.
<br>&gt; Greg
<br>&gt; On Wednesday, March 5, 2025 at 11:39:27=E2=80=AFAM UTC-5 Antoine P=
oinsot wrote:
<br>&gt;=20
<br>&gt; &gt; Hi,
<br>&gt; &gt;=20
<br>&gt; &gt;=20
<br>&gt; &gt; Just picking on one thing Laolu said:
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; The current Overton Window appears to be focused on a sm=
all (LoC wise) package to enable a greater degree of permissionless innovat=
ion on Bitcoin
<br>&gt; &gt;=20
<br>&gt; &gt;=20
<br>&gt; &gt; 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 ab=
out that most of what matters is outside of the lines of code changed. Of c=
ourse it depends on the specifics, but rewriting a clean interpreter that w=
e can actually reason about does not strike me as a necessarily riskier app=
roach than &quot;just changing a few lines of code&quot; in an interpreter =
that hardly anyone knows how it really behaves in all cases.
<br>&gt; &gt;=20
<br>&gt; &gt; Antoine
<br>&gt; &gt;=20
<br>&gt; &gt; 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; wro=
te:
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; Hi AJ,
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; First a standard disclaimer: the contents of this email =
shouldn&#39;t be
<br>&gt; &gt; &gt; interpreted as an endorsement of one covenants proposal =
over another.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Since BIP 119&#39;s motivation is entirely concerne=
d with its concept of
<br>&gt; &gt; &gt; &gt; covenants and avoiding what it calls recursive cove=
nants
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; If we look at the motivation section of BIP 119, we find=
 this sentence:
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; This BIP introduces a simple covenant called a *tem=
plate* which enables a
<br>&gt; &gt; &gt; &gt; limited set of highly valuable use cases without si=
gnificant risk. BIP-119
<br>&gt; &gt; &gt; &gt; templates allow for non-recursive fully-enumerated =
covenants with no
<br>&gt; &gt; &gt; &gt; dynamic state.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; You appear to have latched onto the &quot;non-recursive&=
quot; aspect, ignoring the
<br>&gt; &gt; &gt; subsequent qualifiers of &quot;fully-enumerated&quot; an=
d &quot;with no dynamic state&quot;.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; The example that you&#39;ve come up with to &quot;direct=
ly undermine&quot; the claimed
<br>&gt; &gt; &gt; motivations of BIP 119 is still fully enumerated (the so=
le state is declared
<br>&gt; &gt; &gt; up front), and doesn&#39;t contain dynamic state (I can&=
#39;t spend the contract on
<br>&gt; &gt; &gt; chain and do something like swap in another hash H, or s=
ignature S).
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; I found it pretty inconvenient, which I don&#39;t t=
hink is a good indication
<br>&gt; &gt; &gt; &gt; of ecosystem readiness wrt deployment. (For me, the=
 two components that
<br>&gt; &gt; &gt; &gt; are annoying is doing complicated taproot script pa=
th spends, and
<br>&gt; &gt; &gt; &gt; calculating CTV hashes)
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; What language/libraries did you use to produce the spend=
? In my own
<br>&gt; &gt; &gt; development tooling of choice, producing complicated tap=
root script path
<br>&gt; &gt; &gt; spends is pretty straight forward, so perhaps the inconv=
enience you ran into
<br>&gt; &gt; &gt; says more about your dev tooling than the ecosystem read=
iness.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; It&#39;s also worth pointing out that your example relie=
s on private key
<br>&gt; &gt; &gt; deletion, which if deemed acceptable, can be used to emu=
late CTV as is today
<br>&gt; &gt; &gt; (though you can&#39;t create a self-referential loop tha=
t way afaict).
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; For me, the bllsh/simplicity approach makes more se=
nse as a design
<br>&gt; &gt; &gt; &gt; approach for the long term
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; Simplicity certainly has some brilliant devs working on =
it, but after all
<br>&gt; &gt; &gt; these years it still seems to be struggling to exit rese=
arch mode with some
<br>&gt; &gt; &gt; &quot;killer apps&quot; on Liquid.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; bllsh on the other hand is a very new (and cool!) projec=
t that has no
<br>&gt; &gt; &gt; development uptake beyond its creator. Given its nascent=
 state, it seems
<br>&gt; &gt; &gt; rather premature to promote it as a long term solution.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; Both of them are effectively a complete rewrite of Scrip=
t, so compared to
<br>&gt; &gt; &gt; some of the existing covenant proposals on the table (ma=
ny of which have a
<br>&gt; &gt; &gt; small core code footprint in the interpreter), they repr=
esent a radically
<br>&gt; &gt; &gt; expanded scope (ecosystem changes, wallets, consensus co=
de) and therefore
<br>&gt; &gt; &gt; additional risks. The current Overton Window appears to =
be focused on a
<br>&gt; &gt; &gt; small (LoC wise) package to enable a greater degree of p=
ermissionless
<br>&gt; &gt; &gt; innovation on Bitcoin, while leaving the research landsc=
ape open for more
<br>&gt; &gt; &gt; dramatic overhauls (bllsh/Simplicity) in the future.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; -- Laolu
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; On Tue, Mar 4, 2025 at 5:06=E2=80=AFPM Anthony Towns &lt=
;<a href data-email-masked rel=3D"nofollow">a...@erisian.com.au</a>&gt; wro=
te:
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Hello world,
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Some people on twitter are apparently proposing the=
 near-term activation of
<br>&gt; &gt; &gt; &gt; CTV and CSFS (BIP 119 and BIP 348 respectively), eg=
:
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; <a href=3D"https://x.com/JeremyRubin/status/1895676=
912401252588" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/JeremyRubin/status/1=
895676912401252588&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3D=
AOvVaw2lSpj1NoqkKmufXZnbe14H">https://x.com/JeremyRubin/status/189567691240=
1252588</a>
<br>&gt; &gt; &gt; &gt; <a href=3D"https://x.com/lopp/status/18958372902091=
61358" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://w=
ww.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/lopp/status/189583729020916=
1358&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw3ZpjK0_y=
7oVco7R536kpky">https://x.com/lopp/status/1895837290209161358</a>
<br>&gt; &gt; &gt; &gt; <a href=3D"https://x.com/stevenroose3/status/189588=
1757288996914" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"h=
ttps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/stevenroose3/status=
/1895881757288996914&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=
=3DAOvVaw1TYNVwQ6nJMAtAiEwRpW6V">https://x.com/stevenroose3/status/18958817=
57288996914</a>
<br>&gt; &gt; &gt; &gt; <a href=3D"https://x.com/reardencode/status/1871343=
039123452340" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/reardencode/status/1=
871343039123452340&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3D=
AOvVaw0JDykUIzl5Y7wIUZBPy-SS">https://x.com/reardencode/status/187134303912=
3452340</a>
<br>&gt; &gt; &gt; &gt; <a href=3D"https://x.com/sethforprivacy/status/1895=
814836535378055" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/sethforprivacy/st=
atus/1895814836535378055&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;=
usg=3DAOvVaw3N8LYiZAYUmgYvcRs-fBID">https://x.com/sethforprivacy/status/189=
5814836535378055</a>
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Since BIP 119&#39;s motivation is entirely concerne=
d with its concept of
<br>&gt; &gt; &gt; &gt; covenants and avoiding what it calls recursive cove=
nants, I think it
<br>&gt; &gt; &gt; &gt; is interesting to note that the combination of CSFS=
 and CTV trivially
<br>&gt; &gt; &gt; &gt; enables the construction of a &quot;recursive coven=
ant&quot; as BIP 119 uses those
<br>&gt; &gt; &gt; &gt; terms. One approach is as follows:
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; * Make a throwaway BIP340 private key X with 32-bit=
 public key P.
<br>&gt; &gt; &gt; &gt; * Calculate the tapscript &quot;OP_OVER &lt;P&gt; O=
P_CSFS OP_VERIFY OP_CTV&quot;, and
<br>&gt; &gt; &gt; &gt; its corresponding scriptPubKey K when combined with=
 P as the internal public
<br>&gt; &gt; &gt; &gt; key.
<br>&gt; &gt; &gt; &gt; * Calculate the CTV hash corresponding to a payment=
 of some specific value V
<br>&gt; &gt; &gt; &gt; to K; call this hash H
<br>&gt; &gt; &gt; &gt; * Calculate the BIP 340 signature for message H wit=
h private key X, call it S.
<br>&gt; &gt; &gt; &gt; * Discard the private key X
<br>&gt; &gt; &gt; &gt; * Funds sent to K can only be spent by the witness =
data &quot;&lt;H&gt; &lt;S&gt;&quot; that forwards
<br>&gt; &gt; &gt; &gt; an amount V straight back to K.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Here&#39;s a demonstration on mutinynet:
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; <a href=3D"https://mutinynet.com/address/tb1p0p5027=
shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58" target=3D"_blank" rel=
=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&am=
p;q=3Dhttps://mutinynet.com/address/tb1p0p5027shf4gm79c4qx8pmafcsg2lf5jd33t=
znmyjejrmqqx525gsk5nr58&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;u=
sg=3DAOvVaw2BwbNfcY1g91CtCjbZlF9q">https://mutinynet.com/address/tb1p0p5027=
shf4gm79c4qx8pmafcsg2lf5jd33tznmyjejrmqqx525gsk5nr58</a>
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; I&#39;d encourage people to try implementing that t=
hemselves with their
<br>&gt; &gt; &gt; &gt; preferred tooling; personally, I found it pretty in=
convenient, which I
<br>&gt; &gt; &gt; &gt; don&#39;t think is a good indication of ecosystem r=
eadiness wrt deployment.
<br>&gt; &gt; &gt; &gt; (For me, the two components that are annoying is do=
ing complicated
<br>&gt; &gt; &gt; &gt; taproot script path spends, and calculating CTV has=
hes)
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; I don&#39;t believe the existence of a construction=
 like this poses any
<br>&gt; &gt; &gt; &gt; problems in practice, however if there is going to =
be a push to activate
<br>&gt; &gt; &gt; &gt; BIP 119 in parallel with features that directly und=
ermine its claimed
<br>&gt; &gt; &gt; &gt; motivation, then it would presumably be sensible to=
 at least update
<br>&gt; &gt; &gt; &gt; the BIP text to describe a motivation that would ac=
tually be achieved by
<br>&gt; &gt; &gt; &gt; deployment.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Personally, I think BIP 119&#39;s motivation remain=
s very misguided:
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; - the things it describes are, in general, not &quo=
t;covenants&quot; [0]
<br>&gt; &gt; &gt; &gt; - the thing it avoids is not &quot;recursion&quot; =
but unbounded recursion
<br>&gt; &gt; &gt; &gt; - avoiding unbounded recursion is not very interest=
ing when arbitrarily
<br>&gt; &gt; &gt; &gt; large recursion is still possible [1]
<br>&gt; &gt; &gt; &gt; - despite claiming that &quot;covenants have histor=
ically been widely
<br>&gt; &gt; &gt; &gt; considering to be unfit for Bitcoin&quot;, no evide=
nce for this claim has
<br>&gt; &gt; &gt; &gt; been able to be provided [2,3]
<br>&gt; &gt; &gt; &gt; - the opposition to unbounded recursion seems to me=
 to either mostly
<br>&gt; &gt; &gt; &gt; or entirely be misplaced fear of things that are al=
ready possible in
<br>&gt; &gt; &gt; &gt; bitcoin and easily avoided by people who want to av=
oid it, eg [4]
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; so, at least personally, I think almost any update =
to BIP 119&#39;s motivation
<br>&gt; &gt; &gt; &gt; section would be an improvement...
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; [0] <a href=3D"https://gnusha.org/pi/bitcoindev/202=
20719044...@erisian.com.au/" target=3D"_blank" rel=3D"nofollow" data-safere=
directurl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha.org/=
pi/bitcoindev/20220719044...@erisian.com.au/&amp;source=3Dgmail&amp;ust=3D1=
741382686484000&amp;usg=3DAOvVaw0uRAPJyWJkkHLORYucWoWw">https://gnusha.org/=
pi/bitcoindev/20220719044...@erisian.com.au/</a>
<br>&gt; &gt; &gt; &gt; [1] <a href=3D"https://gnusha.org/pi/bitcoindev/87k=
0dwr...@rustcorp.com.au/" target=3D"_blank" rel=3D"nofollow" data-saferedir=
ecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha.org/pi/=
bitcoindev/87k0dwr...@rustcorp.com.au/&amp;source=3Dgmail&amp;ust=3D1741382=
686484000&amp;usg=3DAOvVaw0f4yhJJctetEftAamIvUkt">https://gnusha.org/pi/bit=
coindev/87k0dwr...@rustcorp.com.au/</a>
<br>&gt; &gt; &gt; &gt; [2] <a href=3D"https://gnusha.org/pi/bitcoindev/010=
0017ee6472e02-037d355d-4c16...@email.amazonses.com/" target=3D"_blank" rel=
=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&am=
p;q=3Dhttps://gnusha.org/pi/bitcoindev/0100017ee6472e02-037d355d-4c16...@em=
ail.amazonses.com/&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3D=
AOvVaw1oIK2QrUzDRr5_vapfIDP5">https://gnusha.org/pi/bitcoindev/0100017ee647=
2e02-037d355d-4c16...@email.amazonses.com/</a>
<br>&gt; &gt; &gt; &gt; [3] <a href=3D"https://x.com/Ethan_Heilman/status/1=
194624166093369345" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=
=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://x.com/Ethan_Heilman/=
status/1194624166093369345&amp;source=3Dgmail&amp;ust=3D1741382686484000&am=
p;usg=3DAOvVaw1rneVpW-THW1fobJxHZ-5r">https://x.com/Ethan_Heilman/status/11=
94624166093369345</a>
<br>&gt; &gt; &gt; &gt; [4] <a href=3D"https://gnusha.org/pi/bitcoindev/202=
2021715...@erisian.com.au/" target=3D"_blank" rel=3D"nofollow" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gnusha.org/p=
i/bitcoindev/2022021715...@erisian.com.au/&amp;source=3Dgmail&amp;ust=3D174=
1382686484000&amp;usg=3DAOvVaw0Lv_lwp72L1rw3YasCMprA">https://gnusha.org/pi=
/bitcoindev/2022021715...@erisian.com.au/</a>
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Beyond being a toy example of a conflict with BIP 1=
19&#39;s motivation
<br>&gt; &gt; &gt; &gt; section, I think the above script could be useful i=
n the context of the
<br>&gt; &gt; &gt; &gt; &quot;blind-merged-mining&quot; component of spacec=
hains [5]. For example, if
<br>&gt; &gt; &gt; &gt; the commitment was to two outputs, one the recursiv=
e step and the other
<br>&gt; &gt; &gt; &gt; being a 0sat ephemeral anchor, then the spend of th=
e ephemeral anchor
<br>&gt; &gt; &gt; &gt; would allow for both providing fees conveniently an=
d for encoding the
<br>&gt; &gt; &gt; &gt; spacechain block&#39;s commitment; competing spacec=
hain miners would then
<br>&gt; &gt; &gt; &gt; just be rbf&#39;ing that spend with the parent spac=
echain update remaining
<br>&gt; &gt; &gt; &gt; unchanged. The &quot;nLockTime&quot; and &quot;sequ=
ences_hash&quot; commitment in CTV would
<br>&gt; &gt; &gt; &gt; need to be used to ensure the &quot;one spacechain =
update per bitcoin block&quot;
<br>&gt; &gt; &gt; &gt; rule. (I believe mutinynet doesn&#39;t support ephe=
meral anchors however, so
<br>&gt; &gt; &gt; &gt; I don&#39;t think there&#39;s anywhere this can be =
tested)
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; [5] <a href=3D"https://gist.github.com/RubenSomsen/=
5e4be6d18e5fa526b17d8b34906b16a5#file-bmm-svg" target=3D"_blank" rel=3D"nof=
ollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dh=
ttps://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d8b34906b16a5%23file-=
bmm-svg&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw3KeY9=
9Mt5NGvxfQdff-1o6">https://gist.github.com/RubenSomsen/5e4be6d18e5fa526b17d=
8b34906b16a5#file-bmm-svg</a>
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; (For a spacechain, miners would want to be confiden=
t that the private key
<br>&gt; &gt; &gt; &gt; has been discarded. This confidence could be enhanc=
ed by creating X as a
<br>&gt; &gt; &gt; &gt; musig2 key by a federation, in which case provided =
any of the private keys
<br>&gt; &gt; &gt; &gt; used in generating X were correctly discarded, then=
 everything is fine,
<br>&gt; &gt; &gt; &gt; but that&#39;s still a trust assumption. Simple int=
rospection opcodes would
<br>&gt; &gt; &gt; &gt; work far better for this use case, both removing th=
e trust assumption
<br>&gt; &gt; &gt; &gt; and reducing the onchain data required)
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; If you&#39;re providing CTV and CSFS anyway, I don&=
#39;t see why you wouldn&#39;t
<br>&gt; &gt; &gt; &gt; provide the same or similar functionality via a SIG=
HASH flag so that you
<br>&gt; &gt; &gt; &gt; can avoid specifying the hash directly when you&#39=
;re signing it anyway,
<br>&gt; &gt; &gt; &gt; giving an ANYPREVOUT/NOINPUT-like feature directly.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; (Likewise, I don&#39;t see why you&#39;d want to ac=
tivate CAT on mainnet without
<br>&gt; &gt; &gt; &gt; also at least re-enabling SUBSTR, and potentially a=
lso the redundant
<br>&gt; &gt; &gt; &gt; LEFT and RIGHT operations)
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; For comparison, bllsh [6,7] takes the approach of p=
roviding
<br>&gt; &gt; &gt; &gt; &quot;bip340_verify&quot; (directly equivalent to C=
SFS), &quot;ecdsa_verify&quot; (same but
<br>&gt; &gt; &gt; &gt; for ECDSA rather than schnorr), &quot;bip342_txmsg&=
quot; and &quot;tx&quot; opcodes. A CTV
<br>&gt; &gt; &gt; &gt; equivalent would then either involve simplying writ=
ing:
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; (=3D (bip342_txmsg 3) 0x.....)
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; meaining &quot;calculate the message hash of the cu=
rrent tx for SIGHASH_SINGLE,
<br>&gt; &gt; &gt; &gt; then evaluate whether the result is exactly equal t=
o this constant&quot;
<br>&gt; &gt; &gt; &gt; providing one of the standard sighashes worked for =
your use case, or
<br>&gt; &gt; &gt; &gt; replacing the bip342_txmsg opcode with a custom cal=
culation of the tx
<br>&gt; &gt; &gt; &gt; hash, along the lines of the example reimplementati=
on of bip342_txmsg
<br>&gt; &gt; &gt; &gt; for SIGHASH_ALL [8] in the probably more likely cas=
e that it didn&#39;t. If
<br>&gt; &gt; &gt; &gt; someone wants to write up the BIP 119 hashing formu=
la in bllsh, I&#39;d
<br>&gt; &gt; &gt; &gt; be happy to include that as an example; I think it =
should be a pretty
<br>&gt; &gt; &gt; &gt; straightforward conversion from the test-tx example=
.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; If bllsh were live today (eg on either signet or ma=
innet), and it were
<br>&gt; &gt; &gt; &gt; desired to softfork in a more optimised implementat=
ion of either CTV or
<br>&gt; &gt; &gt; &gt; ANYPREVOUT to replace people coding their own imple=
mentation in bllsh
<br>&gt; &gt; &gt; &gt; directly, both would simply involve replacing calls=
 to &quot;bip342_txmsg&quot;
<br>&gt; &gt; &gt; &gt; with calls to a new hash calculation opcode. For CT=
V behaviour, usage
<br>&gt; &gt; &gt; &gt; would look like &quot;(=3D (bipXXX_txmsg) 0x...)&qu=
ot; as above; for APO behaviour,
<br>&gt; &gt; &gt; &gt; usage would look like &quot;(bip340_verify KEY (bip=
XXX_txmsg) SIG)&quot;. That
<br>&gt; &gt; &gt; &gt; is, the underlying &quot;I want to hash a message i=
n such-and-such a way&quot;
<br>&gt; &gt; &gt; &gt; looks the same, and how it&#39;s used is the wallet=
 author&#39;s decision,
<br>&gt; &gt; &gt; &gt; not a matter of how the consensus code is written.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; I believe simplicity/simfony can be thought of in m=
uch the same way;
<br>&gt; &gt; &gt; &gt; with &quot;jet::bip_0340_verify&quot; taking a tx h=
ash for SIGHASH-like behaviour
<br>&gt; &gt; &gt; &gt; [9], or &quot;jet::eq_256&quot; comparing a tx hash=
 and a constant for CTV-like
<br>&gt; &gt; &gt; &gt; behaviour [10].
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; [6] <a href=3D"https://github.com/ajtowns/bllsh/" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/ajtowns/bllsh/&amp;source=3Dgm=
ail&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw1b7uaLay00YvvOV9-f5elH">http=
s://github.com/ajtowns/bllsh/</a>
<br>&gt; &gt; &gt; &gt; [7] <a href=3D"https://delvingbitcoin.org/t/debugga=
ble-lisp-scripts/1224" target=3D"_blank" rel=3D"nofollow" data-saferedirect=
url=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvingbitcoin.or=
g/t/debuggable-lisp-scripts/1224&amp;source=3Dgmail&amp;ust=3D1741382686484=
000&amp;usg=3DAOvVaw0QL4o91ZwxwyALmbL5v1H0">https://delvingbitcoin.org/t/de=
buggable-lisp-scripts/1224</a>
<br>&gt; &gt; &gt; &gt; [8] <a href=3D"https://github.com/ajtowns/bllsh/blo=
b/master/examples/test-tx" target=3D"_blank" rel=3D"nofollow" data-saferedi=
recturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/aj=
towns/bllsh/blob/master/examples/test-tx&amp;source=3Dgmail&amp;ust=3D17413=
82686484000&amp;usg=3DAOvVaw2JDfwW1mt6MHnLeO8Kk6wh">https://github.com/ajto=
wns/bllsh/blob/master/examples/test-tx</a>
<br>&gt; &gt; &gt; &gt; [9] <a href=3D"https://github.com/BlockstreamResear=
ch/simfony/blob/master/examples/p2pk.simf" target=3D"_blank" rel=3D"nofollo=
w" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps=
://github.com/BlockstreamResearch/simfony/blob/master/examples/p2pk.simf&am=
p;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw30ogPrl222paGJR=
dNBeUGB">https://github.com/BlockstreamResearch/simfony/blob/master/example=
s/p2pk.simf</a>
<br>&gt; &gt; &gt; &gt; [10] <a href=3D"https://github.com/BlockstreamResea=
rch/simfony/blob/master/examples/ctv.simf" target=3D"_blank" rel=3D"nofollo=
w" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps=
://github.com/BlockstreamResearch/simfony/blob/master/examples/ctv.simf&amp=
;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw3UL-REjZnmpKNynw=
3Qocu1">https://github.com/BlockstreamResearch/simfony/blob/master/examples=
/ctv.simf</a>
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; For me, the bllsh/simplicity approach makes more se=
nse as a design
<br>&gt; &gt; &gt; &gt; approach for the long term, and the ongoing lack of=
 examples of killer
<br>&gt; &gt; &gt; &gt; apps demonstrating big wins from limited slices of =
new functionality
<br>&gt; &gt; &gt; &gt; leaves me completely unexcited about rushing someth=
ing in the short term.
<br>&gt; &gt; &gt; &gt; Having a flood of use cases that don&#39;t work out=
 when looked into isn&#39;t
<br>&gt; &gt; &gt; &gt; a good replacement for a single compelling use case=
 that does.
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; Cheers,
<br>&gt; &gt; &gt; &gt; aj
<br>&gt; &gt; &gt; &gt;=20
<br>&gt; &gt; &gt; &gt; --
<br>&gt; &gt; &gt; &gt; You received this message because you are subscribe=
d to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; &gt; &gt; &gt; To unsubscribe from this group and stop receiving e=
mails from it, send an email to <a href data-email-masked rel=3D"nofollow">=
bitcoindev+...@googlegroups.com</a>.
<br>&gt; &gt; &gt; &gt; To view this discussion visit <a href=3D"https://gr=
oups.google.com/d/msgid/bitcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au" targe=
t=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.co=
m/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/Z8eUQCfC=
WjdivIzn%2540erisian.com.au&amp;source=3Dgmail&amp;ust=3D1741382686484000&a=
mp;usg=3DAOvVaw1EAvbEO9pnA2VeDvbznhOo">https://groups.google.com/d/msgid/bi=
tcoindev/Z8eUQCfCWjdivIzn%40erisian.com.au</a>.
<br>&gt; &gt; &gt;=20
<br>&gt; &gt; &gt; --
<br>&gt; &gt; &gt; You received this message because you are subscribed to =
the Google Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; &gt; &gt; To unsubscribe from this group and stop receiving emails=
 from it, send an email to <a href data-email-masked rel=3D"nofollow">bitco=
indev+...@googlegroups.com</a>.
<br>&gt; &gt;=20
<br>&gt; &gt; &gt; To view this discussion visit <a href=3D"https://groups.=
google.com/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCH=
WxNV_Q%40mail.gmail.com" target=3D"_blank" rel=3D"nofollow" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%2=
540mail.gmail.com&amp;source=3Dgmail&amp;ust=3D1741382686484000&amp;usg=3DA=
OvVaw3WYmMjfeDBTEsAEVfBLcdx">https://groups.google.com/d/msgid/bitcoindev/C=
AO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q%40mail.gmail.com</a>.
<br>&gt;=20
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@=
googlegroups.com</a>.
<br>&gt; To view this discussion visit <a href=3D"https://groups.google.com=
/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a6649e610ce5n%40googlegroups.co=
m" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/=
17e7eb49-77b7-4f2f-be40-a6649e610ce5n%2540googlegroups.com&amp;source=3Dgma=
il&amp;ust=3D1741382686484000&amp;usg=3DAOvVaw1__JAmBzXXox3rToj5Luwz">https=
://groups.google.com/d/msgid/bitcoindev/17e7eb49-77b7-4f2f-be40-a6649e610ce=
5n%40googlegroups.com</a>.
<br></blockquote></div>

<p></p>

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

------=_Part_40073_468764918.1741296383124--

------=_Part_40072_1428590326.1741296383124--