path: root/d7/bfe26c4f9939934774eefa03ca92cc3640d390

Delivery-date: Mon, 17 Mar 2025 06:35:36 -0700
Received: from mail-yw1-f192.google.com ([209.85.128.192])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBHWK4C7AMGQEBCMSXOY@googlegroups.com>)
	id 1tuAcw-0003oh-Vx
	for bitcoindev@gnusha.org; Mon, 17 Mar 2025 06:35:36 -0700
Received: by mail-yw1-f192.google.com with SMTP id 00721157ae682-6fedcc61536sf72673277b3.0
        for <bitcoindev@gnusha.org>; Mon, 17 Mar 2025 06:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1742218529; x=1742823329; 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=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=;
        b=sEHqM/Ba5S2saiKeWjwdmlaIzUeOxw8D3S1hfmPYVcLq6IRcJNyWr4KudcQq0kerFM
         qmvYsMYbbTLxfU3Dae3WKZPACprefT1KypspVLvbHtzKaRbN6DsIJpr1iqmKvzupozl+
         otKrGpl/uRFwItnqlgHKZd3dDeO4LaT2jFZPH7CCcLUyYEBt4Jhrt9mnpTr1hh3Csy4l
         BSMGo6Kl5wwM8iOkfd24m11Sg2Z78mtQ5XqX9Z5Y8+luUvGVXXCek1F5/o8SLS5WYrw4
         +5Nz7IeMOt/5imslCpdr2xsexd72VzVbEw/gaN2uPY1Usb0xBHcyMPDYHEvNrqxWuz9I
         LfWg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1742218529; x=1742823329; 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=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=;
        b=nVucYPCimu0lwiTQok+rvqkcPC802mxorpVp14F/LzrdHkAxYRHWkqscF8CRHJ6QOq
         sbbAWWd0/sk+dAUl0R7QudAHltLzbGJSMf5Pca/tqyROaR+sUBvq32Y+dZrAlUAcGB1j
         QVdpPNwYa06c14BJxiUSOhf4rzur1YPfbgzsZK/q1RQrkNegKQE4nrd+hHTW1S/heci+
         cAjEmIdE3nraU4wg8yYj0cyCrdf2QYrLx2QVxeexiEaiekEdgsQFOJXoqCiG0x0vBn+n
         h8WSrTBSxNuLNdSi9r/6tQ+GviEKCVSGnk2ctdduPVuZ3GGaFMBa9gLCREBlDkdrA+kk
         bWuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1742218529; x=1742823329;
        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=HuUxeFY2TYIMCMb8HQIUf2EEh3PjN1Fnrr3CH/CuE0E=;
        b=tK1FcZI7LFd6ZN1hlTKhlhRm7Hb6eq9C9el9hPjknBdjgphZGu431ZBLJcq5/L1QHj
         CKHpNIor5kD+UtGdQFFRA0Sn9bBZejBHF3rkhw+KW0igszwXI6qUxubOHlw8GAUdI1l3
         /R3OzIwgXHp3y+Uh5WRTDJ/Zg8b+He82Av4J5VZUKRXN6kLoh73Ookx1OfipZ+uMYvpr
         ysouy9rzVMA9XPs7Y88m1DP8R40leN+Wo+Bn7bDbeKQNUYxisGZbOlgekWMHD9bT7mGz
         Ap2g4iaXLSqX0B2xCIncDQbMHZIFWDPpfWbHjKYVmYxv/5Cx7Oq65Ts8FM3ONIvoov7v
         vBlA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUKSpj5GrfrFkKrIxNApcp8BX65Ezo+s6oxy0go+1P9sxPTJKh79z30mMtaQ2t792kJYVE7czadbSaG@gnusha.org
X-Gm-Message-State: AOJu0YyY2a4d67IzVBFMXFf65IKid012Nvmo6UKWBiLbQs9JsGWaTm84
	IHBfpYz7rilXp1OFImiiLQsMg9pQV7jDJIASGwX7WaMUycDWT2m3
X-Google-Smtp-Source: AGHT+IGfVhRcTiOcagNnqNgD6nGlXI8Nn8k+BSpq4ihpgegycC6vXB+qx0ls8mVxhqJ+s6HM6W72LQ==
X-Received: by 2002:a05:6902:e12:b0:e5d:c1b9:4a7 with SMTP id 3f1490d57ef6-e63e3d27592mr21996753276.23.1742218529120;
        Mon, 17 Mar 2025 06:35:29 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJRS4v3Y6qZFoiYwcujROfCIzLg8wzfYcwWfGxamDAv0A==
Received: by 2002:a25:3d84:0:b0:e60:8883:5aa4 with SMTP id 3f1490d57ef6-e63dc2be29bls409260276.2.-pod-prod-03-us;
 Mon, 17 Mar 2025 06:35:25 -0700 (PDT)
X-Received: by 2002:a05:690c:700d:b0:6fe:bff2:3a6d with SMTP id 00721157ae682-6ff45f1564dmr162998417b3.1.1742218525531;
        Mon, 17 Mar 2025 06:35:25 -0700 (PDT)
Received: by 2002:a05:690c:3388:b0:6ef:590d:3213 with SMTP id 00721157ae682-6fda287d366ms7b3;
        Mon, 10 Mar 2025 18:06:42 -0700 (PDT)
X-Received: by 2002:a05:690c:3806:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-6ff0925ecb0mr27588317b3.23.1741655200953;
        Mon, 10 Mar 2025 18:06:40 -0700 (PDT)
Date: Mon, 10 Mar 2025 18:06:40 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5610731e-b4a3-448d-bf4b-508739d51198n@googlegroups.com>
In-Reply-To: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
 <Z8tes4tXo53_DRpU@erisian.com.au>
 <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_11544_460570634.1741655200612"
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_11544_460570634.1741655200612
Content-Type: multipart/alternative; 
	boundary="----=_Part_11545_1992028623.1741655200612"

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

Hi James,

> As with everything in bitcoin, the chain is insulated from stupidity like=
=20
that
> by fees, the UTXO model, and block cadence, so what's the problem?

See my novel answer to AJ that by extending bitcoin script, I think you=20
might *actually*
diluting the UTXO model as you can now on cross-inspect the status of an=20
outpoint.
This might amplify tx-withhold style risk for bitcoin contracting=20
protocols, e.g vaults.

> Probably worth noting that CSFS and many advanced introspection opcodes=
=20
(which allow synthesizing
> CTV) have been live for almost *four years now* on Liquid=20
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opco=
des.md#new-opcodes-for-additional-functionality).

Live !=3D Deployed use-cases built on top of those advanced introspection=
=20
opcodes.

I've not verified this by myself, though from what is available from public=
=20
data
L-BTC is <=3D to LN today in terms of locked coins. In terms of=20
decentralization,
a federated side-chain is not even like a network of payment channels, wher=
e
everyone can join by confirming a 2-of-2 in the chain. So have skilled dev=
=20
really
try do "wrong things" with L-BTC and all those shiny introspection opcodes=
=20
? I'm
not sure, and please accept my skepticism here.

> Sorry to tell you, but given that changing consensus requires soliciting=
=20
buy-in from a
> wide variety of people across the Bitcoin ecosystem with varying levels=
=20
of technical
> ability, it is inherently a political process.

No -- Apologies to tell you that science / engineering !=3D politics.

Somehow, if one has taste and familiarity with all postmodernism sociology,
there is well one domain where it completely failed to demonstrate that=20
things
are following a "political process", this is indeed the domain of science.=
=20
In
science, mathematical or physical truth always prevails, no matter what.

Don't get me wrong -- This doesn't mean I cannot share the opinion that=20
current
consensus changes process is a complete conoundrum. Sadly it might have=20
devolved
in the view of numerous segments of the Bitcoin ecosystem that what matters=
=20
w.r.t
consensus build-up is who is sitting on a bunch of surreanous github=20
repository
permissions, and not necessarily if the consensus change is benefitful in a=
n
objective fashion for bitcoin, not even if such _consensus change_ might be
required for the long-term flourishing of bitcoin (at least fixing the=20
technical
debt).

There is difference in saying what makes you socially popular to be vetted=
=20
with
empty github permissions and let you vegetate on them by a weak social=20
consensus
and there is a difference in saying unpopular truth to nurture real changes=
=20
on
the long-term. I won't open the conversation more on that subject.

Now, back to the more technical analysis of covenant, personally my positio=
n
is still the same than it was discussed on Bitcoin Core #28550. The=20
communication
tone was rude, for sure, though I still share the same belief we shouldn't=
=20
be
careful in designing contracting primitives and be completely $YOLO if said
primitives works well for a second-layer.

On concerning CheckTemplateVerify itself, which is itself simpler than any
other proposed soft-forks due to the non-malleable templating, as I said 18
months ago I'm still open in my free time to review/test a CTV-based vault
(https://github.com/jamesob/simple-ctv-vault), the same way I did for=20
Eltoo-based
LN channels in the past. This is one thing to come with a proof-of-concept
working on a single workstation, this is another thing to have tested it
under real operational guidelines, where dynamic fees and keys ceremonies
have to be deal with.

I don't think CTV is altering the UTXO model significantly, though pleasure
to be proven wrong here. On the other hand CTV is bringing this idea of
immutability in a chain of transactions, that we cannot do currently with
sigs-based covenant. That immutability in theory has consequential value
for anyone building cold wallet or vault, that is clear as once the funding
utxo is confirmed, the UTXO signing keys leaks are void.

Now, I might be the last guy in the ecosystem to think that CTV is not
the promised silver-bullet by its author all over the world to design
and deploy vaults. Fine.

> Beyond that, "Overton window" is an appropriate device in the sense that=
=20
roasbeef
> is using it because the more substantial a proposed change is, the more=
=20
time is
> needed by the technical ecosystem to digest it, both in terms of tooling=
=20
and safety
> analysis. Introducing an entirely new script interpreter on the basis of=
=20
a Lisp (or
> combinator calculus, or whatever Simplicity's claim is) is indeed far=20
outside of
> that "Overton" window - much farther than tacking on what is essentially=
=20
just a
> new SIGHASH mode to the existing interpreter.

I do not wish to be overly pessimitic, though I think whatever=20
"just-drop-a-new
script-interpreter" approach is just the wrong design approach, if we do=20
not go
to fix first all the dynamic fees issues grieving all the contracting=20
protocols
and bitcoin second-layers.

Side-note: if you're used with playing with your compiler to target exotic
ISAs, one could build the equivalent for any Lisp interpreter where there i=
s
an IR and in function of the target you compile to current supported bitcoi=
n
opcodes, disabling interpreter syntax that are not (currently) supported or
that cannot be translated. I think this would be already a formal=20
verification
gain for any smart-contract toolchain using it, even if it's a subset.

> Let's not be petty here - it's clear he's talking about LoC within the=20
script
>interpreter, which is a different context than the codebase as a whole.=20
Within
> the context of the interpreter, LoC is indeed a decent heuristic for=20
marginal risk. Of course, nobody's saying it's perfect.

I agree that LoC is a decent heuristic for marginal risk.

Best,
Antoine
OTS hash: 7f00760799b4defd9fe551673a7926c01704274e522d44f3dc8e701b320243de
Le samedi 8 mars 2025 =C3=A0 16:39:34 UTC, James O'Beirne a =C3=A9crit :

> On Friday, March 7, 2025 at 4:26:36=E2=80=AFPM UTC-5 Anthony Towns wrote:
>
> If you instead did not delete the CSFS private key would allow you to=20
> swap in another hash H or signature S in future. That would perhaps=20
> allow designing an unbounded state machine where a master key can add=20
> new states in future.
>
>
> I'm not sure what your point here is - that we can do stupid things with=
=20
> CTV + CSFS? That's universally true in bitcoin; I can have an "unbounded=
=20
> state machine" by sending myself the same UTXO back and forth indefinitel=
y=20
> with CHECKSIG.
>
> As with everything in bitcoin, the chain is insulated from stupidity like=
=20
> that by fees, the UTXO model, and block cadence, so what's the problem?
> =20
>
> https://github.com/ElementsProject/elements/pull/1427 suggests=20
> Simplicity's potentially going live on Liquid any day now.
>
>
> Probably worth noting that CSFS and many advanced introspection opcodes=
=20
> (which allow synthesizing CTV) have been live for almost *four years now*=
=20
> on Liquid (
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opc=
odes.md#new-opcodes-for-additional-functionality
> ).
> =20
>
> The concept of an "Overton window" is a political one, used for when=20
> there has been successful political pressure to exclude some subjects=20
> from discussion for reasons other than their underlying merits. That's=20
> not a good idea if you want to maintain high quality, and it's probably=
=20
> not compatible at all with a project that aims to be decentralised in=20
> any meaningful way.
>
>
> Sorry to tell you, but given that changing consensus requires soliciting=
=20
> buy-in from a wide variety of people across the Bitcoin ecosystem with=20
> varying levels of technical ability, it is inherently a political process=
.
>
> Beyond that, "Overton window" is an appropriate device in the sense that=
=20
> roasbeef is using it because the more substantial a proposed change is, t=
he=20
> more time is needed by the technical ecosystem to digest it, both in term=
s=20
> of tooling and safety analysis. Introducing an entirely new script=20
> interpreter on the basis of a Lisp (or combinator calculus, or whatever=
=20
> Simplicity's claim is) is indeed far outside of that "Overton" window -=
=20
> much farther than tacking on what is essentially just a new SIGHASH mode =
to=20
> the existing interpreter.
> =20
>
> Certainly a small change (though LoC is a bad measure of that -- how=20
> many LoC does it take to drop the 21M limit, or to drop the subsidy from=
=20
> 3.125 BTC to 0 BTC?) is better than a large change all else being equal;=
=20
> but all else isn't equal: different changes enable different feature=20
> sets. The question you should be asking is whether we're getting useful=
=20
> feature sets from the small changes being proposed.
>
>
> Let's not be petty here - it's clear he's talking about LoC within the=20
> script interpreter, which is a different context than the codebase as a=
=20
> whole. Within the context of the interpreter, LoC is indeed a decent=20
> heuristic for marginal risk. Of course, nobody's saying it's perfect.
>
> James
>

--=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/=
5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com.

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

Hi James,<br /><br />&gt; As with everything in bitcoin, the chain is insul=
ated from stupidity like that<br />&gt; by fees, the UTXO model, and block =
cadence, so what's the problem?<br /><br />See my novel answer to AJ that b=
y extending bitcoin script, I think you might *actually*<br />diluting the =
UTXO model as you can now on cross-inspect the status of an outpoint.<br />=
This might amplify tx-withhold style risk for bitcoin contracting protocols=
, e.g vaults.<br /><br />&gt; Probably worth noting that CSFS and many adva=
nced introspection opcodes (which allow synthesizing<br />&gt; CTV) have be=
en live for almost *four years now* on Liquid (https://github.com/ElementsP=
roject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additi=
onal-functionality).<br /><br />Live !=3D Deployed use-cases built on top o=
f those advanced introspection opcodes.<br /><br />I've not verified this b=
y myself, though from what is available from public data<br />L-BTC is &lt;=
=3D to LN today in terms of locked coins. In terms of decentralization,<br =
/>a federated side-chain is not even like a network of payment channels, wh=
ere<br />everyone can join by confirming a 2-of-2 in the chain. So have ski=
lled dev really<br />try do "wrong things" with L-BTC and all those shiny i=
ntrospection opcodes ? I'm<br />not sure, and please accept my skepticism h=
ere.<br /><br />&gt; Sorry to tell you, but given that changing consensus r=
equires soliciting buy-in from a<br />&gt; wide variety of people across th=
e Bitcoin ecosystem with varying levels of technical<br />&gt; ability, it =
is inherently a political process.<br /><br />No -- Apologies to tell you t=
hat science / engineering !=3D politics.<br /><br />Somehow, if one has tas=
te and familiarity with all postmodernism sociology,<br />there is well one=
 domain where it completely failed to demonstrate that things<br />are foll=
owing a "political process", this is indeed the domain of science. In<br />=
science, mathematical or physical truth always prevails, no matter what.<br=
 /><br />Don't get me wrong -- This doesn't mean I cannot share the opinion=
 that current<br />consensus changes process is a complete conoundrum. Sadl=
y it might have devolved<br />in the view of numerous segments of the Bitco=
in ecosystem that what matters w.r.t<br />consensus build-up is who is sitt=
ing on a bunch of surreanous github repository<br />permissions, and not ne=
cessarily if the consensus change is benefitful in an<br />objective fashio=
n for bitcoin, not even if such _consensus change_ might be<br />required f=
or the long-term flourishing of bitcoin (at least fixing the technical<br /=
>debt).<br /><br />There is difference in saying what makes you socially po=
pular to be vetted with<br />empty github permissions and let you vegetate =
on them by a weak social consensus<br />and there is a difference in saying=
 unpopular truth to nurture real changes on<br />the long-term. I won't ope=
n the conversation more on that subject.<br /><br />Now, back to the more t=
echnical analysis of covenant, personally my position<br />is still the sam=
e than it was discussed on Bitcoin Core #28550. The communication<br />tone=
 was rude, for sure, though I still share the same belief we shouldn't be<b=
r />careful in designing contracting primitives and be completely $YOLO if =
said<br />primitives works well for a second-layer.<br /><br />On concernin=
g CheckTemplateVerify itself, which is itself simpler than any<br />other p=
roposed soft-forks due to the non-malleable templating, as I said 18<br />m=
onths ago I'm still open in my free time to review/test a CTV-based vault<b=
r />(https://github.com/jamesob/simple-ctv-vault), the same way I did for E=
ltoo-based<br />LN channels in the past. This is one thing to come with a p=
roof-of-concept<br />working on a single workstation, this is another thing=
 to have tested it<br />under real operational guidelines, where dynamic fe=
es and keys ceremonies<br />have to be deal with.<br /><br />I don't think =
CTV is altering the UTXO model significantly, though pleasure<br />to be pr=
oven wrong here. On the other hand CTV is bringing this idea of<br />immuta=
bility in a chain of transactions, that we cannot do currently with<br />si=
gs-based covenant. That immutability in theory has consequential value<br /=
>for anyone building cold wallet or vault, that is clear as once the fundin=
g<br />utxo is confirmed, the UTXO signing keys leaks are void.<br /><br />=
Now, I might be the last guy in the ecosystem to think that CTV is not<br /=
>the promised silver-bullet by its author all over the world to design<br /=
>and deploy vaults. Fine.<br /><br />&gt; Beyond that, "Overton window" is =
an appropriate device in the sense that roasbeef<br />&gt; is using it beca=
use the more substantial a proposed change is, the more time is<br />&gt; n=
eeded by the technical ecosystem to digest it, both in terms of tooling and=
 safety<br />&gt; analysis. Introducing an entirely new script interpreter =
on the basis of a Lisp (or<br />&gt; combinator calculus, or whatever Simpl=
icity's claim is) is indeed far outside of<br />&gt; that "Overton" window =
- much farther than tacking on what is essentially just a<br />&gt; new SIG=
HASH mode to the existing interpreter.<br /><br />I do not wish to be overl=
y pessimitic, though I think whatever "just-drop-a-new<br />script-interpre=
ter" approach is just the wrong design approach, if we do not go<br />to fi=
x first all the dynamic fees issues grieving all the contracting protocols<=
br />and bitcoin second-layers.<br /><br />Side-note: if you're used with p=
laying with your compiler to target exotic<br />ISAs, one could build the e=
quivalent for any Lisp interpreter where there is<br />an IR and in functio=
n of the target you compile to current supported bitcoin<br />opcodes, disa=
bling interpreter syntax that are not (currently) supported or<br />that ca=
nnot be translated. I think this would be already a formal verification<br =
/>gain for any smart-contract toolchain using it, even if it's a subset.<br=
 /><br />&gt; Let's not be petty here - it's clear he's talking about LoC w=
ithin the script<br />&gt;interpreter, which is a different context than th=
e codebase as a whole. Within<br />&gt; the context of the interpreter, LoC=
 is indeed a decent heuristic for marginal risk. Of course, nobody's saying=
 it's perfect.<br /><br />I agree that LoC is a decent heuristic for margin=
al risk.<br /><br />Best,<br />Antoine<br />OTS hash: 7f00760799b4defd9fe55=
1673a7926c01704274e522d44f3dc8e701b320243de<br /><div class=3D"gmail_quote"=
><div dir=3D"auto" class=3D"gmail_attr">Le samedi 8 mars 2025 =C3=A0 16:39:=
34 UTC, James O&#39;Beirne a =C3=A9crit=C2=A0:<br/></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><div><div dir=3D"auto">On Friday, March =
7, 2025 at 4:26:36=E2=80=AFPM UTC-5 Anthony Towns wrote:</div><blockquote s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex">If you instead did not delete the CSFS private key would all=
ow you to
<br>swap in another hash H or signature S in future. That would perhaps
<br>allow designing an unbounded state machine where a master key can add
<br>new states in future.</blockquote><div><br></div></div><div><div>I&#39;=
m not sure what your point here is - that we can do stupid things with CTV =
+ CSFS? That&#39;s universally true in bitcoin; I can have an &quot;unbound=
ed state machine&quot; by sending myself the same UTXO back and forth indef=
initely with CHECKSIG.</div><div><br></div><div>As with everything in bitco=
in, the chain is insulated from stupidity like that by fees, the UTXO model=
, and block cadence, so what&#39;s the problem?</div></div><div><div>=C2=A0=
</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><a href=3D"https://github.com/ElementsPro=
ject/elements/pull/1427" rel=3D"nofollow" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/Elem=
entsProject/elements/pull/1427&amp;source=3Dgmail&amp;ust=3D174174149428900=
0&amp;usg=3DAOvVaw1jHoC8rkBPJD7XOew-maF5">https://github.com/ElementsProjec=
t/elements/pull/1427</a> suggests
<br>Simplicity&#39;s potentially going live on Liquid any day now.<br></blo=
ckquote><div><br></div></div><div><div>Probably worth noting that CSFS and =
many advanced introspection opcodes (which allow synthesizing CTV) have bee=
n live for almost *four years now* on Liquid (<a href=3D"https://github.com=
/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-=
for-additional-functionality" target=3D"_blank" rel=3D"nofollow" data-safer=
edirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com=
/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md%23new-opcode=
s-for-additional-functionality&amp;source=3Dgmail&amp;ust=3D174174149428900=
0&amp;usg=3DAOvVaw1a3mRfobRQE2xI2islu8ZG">https://github.com/ElementsProjec=
t/elements/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-=
functionality</a>).</div></div><div><div>=C2=A0</div><blockquote style=3D"m=
argin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">The concept of an &quot;Overton window&quot; is a political one, used=
 for when
<br>there has been successful political pressure to exclude some subjects
<br>from discussion for reasons other than their underlying merits. That&#3=
9;s
<br>not a good idea if you want to maintain high quality, and it&#39;s prob=
ably
<br>not compatible at all with a project that aims to be decentralised in
<br>any meaningful way.</blockquote><div><br></div></div><div><div>Sorry to=
 tell you, but given that changing consensus requires soliciting buy-in fro=
m a wide variety of people across the Bitcoin ecosystem with varying levels=
 of technical ability, it is inherently a political process.</div><div><br>=
</div><div>Beyond that, &quot;Overton window&quot; is an appropriate device=
 in the sense that roasbeef is using it because the more substantial a prop=
osed change is, the more time is needed by the technical ecosystem to diges=
t it, both in terms of tooling and safety analysis. Introducing an entirely=
 new=C2=A0script interpreter on the basis of a Lisp (or combinator calculus=
, or whatever Simplicity&#39;s claim is) is indeed far outside of that &quo=
t;Overton&quot; window - much farther than tacking on what is essentially j=
ust a new SIGHASH mode to the existing interpreter.</div></div><div><div>=
=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex">Certainly a small change (though Lo=
C is a bad measure of that -- how
<br>many LoC does it take to drop the 21M limit, or to drop the subsidy fro=
m
<br>3.125 BTC to 0 BTC?) is better than a large change all else being equal=
;
<br>but all else isn&#39;t equal: different changes enable different featur=
e
<br>sets. The question you should be asking is whether we&#39;re getting us=
eful
<br>feature sets from the small changes being proposed.</blockquote><div><b=
r></div></div><div><div>Let&#39;s not be petty here - it&#39;s clear he&#39=
;s talking about LoC within the script interpreter, which is a different co=
ntext than the codebase as a whole. Within the context of the interpreter, =
LoC is indeed a decent heuristic for marginal risk. Of course, nobody&#39;s=
 saying it&#39;s perfect.</div><div><br></div><div>James</div></div></block=
quote></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/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/5610731e-b4a3-448d-bf4b-508739d51198n%40googlegroups.com</a>.<br />

------=_Part_11545_1992028623.1741655200612--

------=_Part_11544_460570634.1741655200612--