From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Mar 2025 08:39:41 -0800 Received: from mail-yb1-f184.google.com ([209.85.219.184]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tqxDA-0002PD-ED for bitcoindev@gnusha.org; Sat, 08 Mar 2025 08:39:41 -0800 Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e549de22484sf4529026276.2 for ; Sat, 08 Mar 2025 08:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1741451974; x=1742056774; 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=wS6Ko75HRMSTbJVSV3oBhikp8OfBDQpKCnLFAiVtumk=; b=nbowDoss+ghPzZVIGDhf+NRMoeKV/n++7kwiKuFYv7JzNVI0tcXFIBa5iWuehqlfxk eWKntTEDxkNNpAdmnqsylOEe5f9XZvLwuT43cVGqwOz4D22+uBshbpqTHtKCaAuTcFBO +FToT38uy/gkdZS55AZjllRE3bvgS2zG7CmO280Z/vQS5wv9XlYTYlUJj2V/tbvbrMv1 uU3yRUtfy+ujPZh10Hk1tWfX7u9pp2q9V1Hvj/u9NNVIkjDvvlROaJ74P/7qR9KXAgcF qg/u3lPqzcbtmcchKF4MhJ3HNnoGcQJ6oJOGHD6MM5xHZZvQNja9+yAJmZGPMatVDIw3 EXyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741451974; x=1742056774; 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=wS6Ko75HRMSTbJVSV3oBhikp8OfBDQpKCnLFAiVtumk=; b=KdFQoJoXiA4BonScOLlY7mWx+YyP2d4EySCymoI9tP2BF62BRUiuuU1iCRZy8GCqHn jpWFcXPcg/hZliy7TpoxFZBBNMasCineu2P1QVOwuF6jYZqliVlh1FNY1bPR4c8Zc90w SIf0RlgcZEhQRSz4WNztlfe78sh80W8QjkNxGG3tQa/erqAzbWk4vwXfjnquPvOXcYC5 e+ihV8BSJMrq6C3uto6x04mMv7msXTz4PSVTeGtsiCJqB5KhWdi0F7mMVY5gPwLrvY6T 3IDloU89zz1jO4DVZOGafOLYAFvllPz79syu9pQIPm58xOv1Dcbe4GEywZnVrFwSHiMQ mN6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741451974; x=1742056774; 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=wS6Ko75HRMSTbJVSV3oBhikp8OfBDQpKCnLFAiVtumk=; b=wkqlM7+ZBTAVcDs8NEZfaDBWsqOD3ZXeMYZPy5FVe2s7qZa7K3gaLq3GOhXHpNjupv LQJhkQ2ogYhXpo6K1eO/SO4xHhe9zXEeN0D1JBzv54muyO30ohE7LNpNKKaCTeu5z8Mb KtQ67Wo0a2yZaueqf145GM4MKi+v0KKkrPWAgSf+TkWCPDYBip0M9RrDTByXivg2BohZ ojP/iTE+WjZrg2tJQO9sCoLfGz351KymD7cvHEGVWaaL32xSbHetdMXjotewcb0kxw+b 7huw1ZkuRavCAG/+cIZd0h6nzY0gtvBA9xI+6uzRYth+P6PwlP4DbVy1QBL6nAQN8teE 3kMg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXi/yBlZjxZvI4Z+WeR3Y+5AkZd9mAHBEUd5GdH8UDEKnWSaCzkLR+E/lX0YKTQCZ7K5eowWEtj2ABl@gnusha.org X-Gm-Message-State: AOJu0YyKk3KGbu8P1Z6oh5ONZlKc9eLrEiFGA+yQ+N9jwzI/54TMd1WV RLfmiAWhG8K29Sr/vHqBI0eX6B/xXYe+ppKTuMsOr45VLKJiYSdQ X-Google-Smtp-Source: AGHT+IGNQMB30HTiEZBr4ofWatCYsHlxri+HuRwzUy9IpySg0cATZ74iotxg4MRfEWa01ZsFkRNZQg== X-Received: by 2002:a05:6902:310b:b0:e5b:4482:a4f7 with SMTP id 3f1490d57ef6-e635c1382fdmr9601094276.12.1741451974634; Sat, 08 Mar 2025 08:39:34 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h=Adn5yVG41I5FrF0hdLLSD7lavRvyLRXTSisuk7droKpFnFg5rQ== Received: by 2002:a25:d30b:0:b0:e5b:423e:3be6 with SMTP id 3f1490d57ef6-e63485554dels526272276.1.-pod-prod-08-us; Sat, 08 Mar 2025 08:39:30 -0800 (PST) X-Received: by 2002:a05:690c:45c1:b0:6f9:45de:408f with SMTP id 00721157ae682-6febf3e4a7amr104901207b3.35.1741451969889; Sat, 08 Mar 2025 08:39:29 -0800 (PST) Received: by 2002:a05:690c:4787:b0:6fd:27d2:c7f1 with SMTP id 00721157ae682-6fda2a21eedms7b3; Sat, 8 Mar 2025 07:55:39 -0800 (PST) X-Received: by 2002:a05:690c:368c:b0:6f9:7920:e813 with SMTP id 00721157ae682-6febf2b439fmr98151697b3.4.1741449338814; Sat, 08 Mar 2025 07:55:38 -0800 (PST) Date: Sat, 8 Mar 2025 07:55:38 -0800 (PST) From: James O'Beirne To: Bitcoin Development Mailing List Message-Id: <45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] "Recursive covenant" with CTV and CSFS MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_174224_972904451.1741449338363" X-Original-Sender: james.obeirne@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_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
On Friday, March 7, 2025 at 4:26:36=E2=80=AFPM UTC-5= Anthony Towns wrote:
If you inste= ad did not delete the CSFS private key would allow you to
swap in another hash H or signature S in future. That would perhaps
allow designing an unbounded state machine where a master key can add
new states in future.

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.

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?
=C2=A0
https://github.com/ElementsProject/elements/p= ull/1427 suggests
Simplicity's potentially going live on Liquid any day now.

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).
=C2=A0
The co= ncept of an "Overton window" is a political one, used for when
there has been successful political pressure to exclude some subjects
from discussion for reasons other than their underlying merits. That'= s
not a good idea if you want to maintain high quality, and it's probab= ly
not compatible at all with a project that aims to be decentralised in
any meaningful way.

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.

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.
=C2=A0
Certainly a small change (though LoC is a bad measure of that -- how
many LoC does it take to drop the 21M limit, or to drop the subsidy f= rom
3.125 BTC to 0 BTC?) is better than a large change all else being equ= al;
but all else isn't equal: different changes enable different feature
sets. The question you should be asking is whether we're getting usef= ul
feature sets from the small changes being proposed.
=
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.

James

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/45ce340a-e5c9-4ce2-8ddc-5abfda3b1904n%40googlegroups.com.
------=_Part_174225_1809372639.1741449338363-- ------=_Part_174224_972904451.1741449338363--