Delivery-date: Sat, 08 Mar 2025 08:39:41 -0800
Sender: bitcoindev@googlegroups.com
Date: Sat, 8 Mar 2025 07:55:38 -0800 (PST)
From: James O'Beirne <james.obeirne@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com>
In-Reply-To: <Z8tes4tXo53_DRpU@erisian.com.au>
References: <Z8eUQCfCWjdivIzn@erisian.com.au>
 <CAO3Pvs-1H2s5Dso0z5CjKcHcPvQjG6PMMXvgkzLwXgCHWxNV_Q@mail.gmail.com>
 <Z8tes4tXo53_DRpU@erisian.com.au>
Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_174224_972904451.1741449338363"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_174224_972904451.1741449338363
Content-Type: multipart/alternative; 
	boundary="----=_Part_174225_1809372639.1741449338363"

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

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 indefinitely=
=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=20
(https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opco=
des.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, the=
=20
more time is needed by the technical ecosystem to digest it, both in terms=
=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/=
45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com.

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

<div><div dir=3D"auto">On Friday, March 7, 2025 at 4:26:36=E2=80=AFPM UTC-5=
 Anthony Towns wrote:</div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; =
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">If you inste=
ad did not delete the CSFS private key would allow 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>I'm not sure =
what your point here is - that we can do stupid things with CTV + CSFS? Tha=
t's universally true in bitcoin; I can have an "unbounded state machine" by=
 sending myself the same UTXO back and forth indefinitely with CHECKSIG.</d=
iv><div><br /></div><div>As with everything in bitcoin, the chain is insula=
ted from stupidity like that by fees, the UTXO model, and block cadence, so=
 what's the problem?</div><div>=C2=A0</div><blockquote style=3D"margin: 0px=
 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;"><a href=3D"https://github.com/ElementsProject/elements/pull/1427" targe=
t=3D"_blank" rel=3D"nofollow">https://github.com/ElementsProject/elements/p=
ull/1427</a> suggests
<br />Simplicity's potentially going live on Liquid any day now.<br /></blo=
ckquote><div><br /></div><div>Probably worth noting that CSFS and many adva=
nced introspection opcodes (which allow synthesizing CTV) have been live fo=
r almost *four years now* on Liquid (https://github.com/ElementsProject/ele=
ments/blob/master/doc/tapscript_opcodes.md#new-opcodes-for-additional-funct=
ionality).</div><div>=C2=A0</div><blockquote style=3D"margin: 0px 0px 0px 0=
.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">The co=
ncept of an "Overton window" 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'=
s
<br />not a good idea if you want to maintain high quality, and it's probab=
ly
<br />not compatible at all with a project that aims to be decentralised in
<br />any meaningful way.</blockquote><div><br /></div><div>Sorry to tell y=
ou, but given that changing consensus requires soliciting buy-in from a wid=
e variety of people across the Bitcoin ecosystem with varying levels of tec=
hnical ability, it is inherently a political process.</div><div><br /></div=
><div>Beyond that, "Overton window" is an appropriate device in the sense t=
hat roasbeef is using it because the more substantial a proposed change is,=
 the more time is needed by the technical ecosystem to digest it, both in t=
erms of tooling and safety analysis. Introducing an entirely new=C2=A0scrip=
t interpreter on the basis of a Lisp (or combinator calculus, or whatever S=
implicity's claim is) is indeed far outside of that "Overton" window - much=
 farther than tacking on what is essentially just a new SIGHASH mode to the=
 existing interpreter.</div><div>=C2=A0</div><blockquote style=3D"margin: 0=
px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: =
1ex;">Certainly a small change (though LoC is a bad measure of that -- how
<br />many LoC does it take to drop the 21M limit, or to drop the subsidy f=
rom
<br />3.125 BTC to 0 BTC?) is better than a large change all else being equ=
al;
<br />but all else isn't equal: different changes enable different feature
<br />sets. The question you should be asking is whether we're getting usef=
ul
<br />feature sets from the small changes being proposed.</blockquote><div>=
<br /></div><div>Let's not be petty here - it's clear he's talking about Lo=
C within the script interpreter, which is a different context than the code=
base as a whole. Within the context of the interpreter, LoC is indeed a dec=
ent heuristic for marginal risk. Of course, nobody's saying it's perfect.</=
div><div><br /></div><div>James</div></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/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com</a>.<br />

------=_Part_174225_1809372639.1741449338363--

------=_Part_174224_972904451.1741449338363--