path: root/63/f5662815fc748cc48351a25d1b1f805dfed98c

Delivery-date: Thu, 26 Jun 2025 09:04:05 -0700
Received: from mail-yw1-f186.google.com ([209.85.128.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDDJX3VKZACRB2O66XBAMGQEP4HYZOY@googlegroups.com>)
	id 1uUp51-0000e5-U3
	for bitcoindev@gnusha.org; Thu, 26 Jun 2025 09:04:05 -0700
Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-713e879bd7csf16227487b3.0
        for <bitcoindev@gnusha.org>; Thu, 26 Jun 2025 09:04:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1750953838; x=1751558638; 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=oikCfunEkSW+vOTBUSshPrPvFR0DCd2rMMVySBWVOa4=;
        b=kjH3aNcjQzaxxHUfcs+k5n6qlTCnWaVAG3QnN8LR2k+qEz3nw/t7Gwv1cvbuzXYCg5
         qd4mPPmLtDr+QQ2TkOyZQmAAMGr/3eEEz8GY+5TgvW5VN6IYSuvLDY1X0xL6eKofpJ05
         Z5H8ee1uRk5wN42hY8QZGLKmpsQvp7B4uiXzSNlsBUtpaMx0PE6pvKH/+k3oO2+PC1Zd
         zzJjXtnL/AWfkqBq/OfaupLbkErs46wkyWRk2NFCvtsBi3bhwoh+OAIXephbfukNv3vG
         4PsMA46LasewX6zun+sQE6001umUvKigwOAI01x+TnAg0nIWkyQ8x+MNJ0mZVtbNOA91
         chYQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1750953838; x=1751558638; 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=oikCfunEkSW+vOTBUSshPrPvFR0DCd2rMMVySBWVOa4=;
        b=hkee/wsN18hk2NcT065JsIMhCj2kr/cOoU8jnHxSedaQl+gsM2FFo71k5uRRV1t6r1
         0XBB4AiejoPoxqAtN41xzWEFqllYTJuSpIAU1hWzq70RMegydmFW6+n2Wn0hR+J3Hjnu
         4bhP7oKTTN0+5iUZI9HZVjTEU4adTYgeL+EcB6eCXpuGZONVNOzSRtygy/h2TpqV27by
         c2vaY6xW7YDPPjjDQinFEDAs1cqlRxtGnb1k0RtoCqfWp1Z1z+RvjVw8eKSJzcA5+L4U
         Lx5QAF0B+PG5BDghXz2mXtd0kRDV1Z4SR6/xFi1Z7hz9cRCrG/xdIc9F/eop7rN5bc1g
         IVsg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1750953838; x=1751558638;
        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=oikCfunEkSW+vOTBUSshPrPvFR0DCd2rMMVySBWVOa4=;
        b=PeXNhmW9dor7xCjkmBi45dRCXs5JUvddpNaUDEFXEdf5hw2Py1WvwxRkFkxk1efQ7U
         5Z/jCSNnuEjbN6yFKWAjbSvY4f4yULuAQTGZJs4XAvVVDp8F0xmqYr1H8lrW7vrNXwOH
         sUb+YkA0VaGcSEpuEv5wYYRRxbH/tSG5GrTaKlgLcS+f0cOP07uRT5sTakEWB/RfGdc7
         1/AxPCitCNQGbyVC2pGGVDVnu4mAJbnobmSNK0cv3h2JY1/86A8lL0jERUjjDqZWMeTl
         iBXrG68cbJFIlIQinArB0I1RHDXBM8spXc5i06R9gID+OyaVgI9ZQHkUVG/VyEnibjNj
         4MYg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXD5oMOWumfpzyGEcb8NXR8VCbZXmcwJ1j5CudGdhgMquIHnOiJIWDLeLWPQEtwVp0TpV0ewIQ1/Jzj@gnusha.org
X-Gm-Message-State: AOJu0YxICwW9vvRLgLOxfGGeg75+2ObmyLPGa+VD3mjmwnDpSgvnHPIY
	nAsZmCzy7eLoOzT/32IjfUASv8q+s9BUtRR6uY1jignOHIEJbbOn9Mxw
X-Google-Smtp-Source: AGHT+IGZLGA/IFLh7dbARGF98NKeBBzRwFOVhJb/ywt1xLVi0ctmFHJhPj/04oBtl7CdrKQX4PxzIA==
X-Received: by 2002:a05:6902:18c2:b0:e84:1f25:35 with SMTP id 3f1490d57ef6-e86017a715emr9110122276.31.1750953837494;
        Thu, 26 Jun 2025 09:03:57 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZcr1G+8J6vqxqwmmN9Jm2KshLIyFy+npcUb/8uUhlnesw==
Received: by 2002:a05:6902:4182:b0:e82:4f38:fb29 with SMTP id
 3f1490d57ef6-e879c41a85cls1260805276.2.-pod-prod-03-us; Thu, 26 Jun 2025
 09:03:53 -0700 (PDT)
X-Received: by 2002:a05:690c:7303:b0:712:d70b:45eb with SMTP id 00721157ae682-7151610c79emr4549037b3.31.1750953833645;
        Thu, 26 Jun 2025 09:03:53 -0700 (PDT)
Received: by 2002:a0d:dc46:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-7151656118cms7b3;
        Thu, 26 Jun 2025 09:02:42 -0700 (PDT)
X-Received: by 2002:a05:690c:4d8a:b0:714:13:3544 with SMTP id 00721157ae682-71515fb31bemr4832407b3.16.1750953760941;
        Thu, 26 Jun 2025 09:02:40 -0700 (PDT)
Date: Thu, 26 Jun 2025 09:02:40 -0700 (PDT)
From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <88d14bbe-484c-4d12-a3e5-f894b17f5c64n@googlegroups.com>
In-Reply-To: <CAEM=y+VGE1SbuApOx0Y0jnAYrd-eu_kWFbQf+EHEHyv7seeGGw@mail.gmail.com>
References: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
 <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
 <73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG2_e0=@protonmail.com>
 <CAEM=y+VGE1SbuApOx0Y0jnAYrd-eu_kWFbQf+EHEHyv7seeGGw@mail.gmail.com>
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for
 the capabilities enabled by CTV+CSFS
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_3298_303281863.1750953760462"
X-Original-Sender: joshsdoman@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_3298_303281863.1750953760462
Content-Type: multipart/alternative; 
	boundary="----=_Part_3299_2005966468.1750953760462"

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

> The ability to commit to the exact transaction spending an output is=20
useful to reduce interactivity in second-layer
protocols.

Where do you stand on explicit commitments to neighbor prevouts? My=20
understanding is that this capability would be extremely useful, for BitVM=
=20
and for making offers to buy UTXOs. If the goal is to commit to the "exact=
=20
transaction spending an output," CTV alone wouldn't quite get you there.
On Wednesday, June 25, 2025 at 5:28:02=E2=80=AFPM UTC-4 Ethan Heilman wrote=
:

> > Why not even CAT, which is a neat tool in many situations and would let=
=20
> ZK people experiment with validation rollups? And at this point, it would=
=20
> seem wiser to just work on a sane Bitcoin Script replacement rather than=
=20
> throwing buckets of opcodes at it and hoping it holds off.
>
> A Bitcoin Script replacement is likely to be a lot of work and many of
> the features will be informed by what people are building at the time
> it is designed. Merging a low implementation complexity opcode like
> OP_CAT (BIP-347) would provide useful data to inform a Bitcoin Script
> replacement.
>
> In addition to allowing ZK people to experiment, OP_CAT also has many
> simple use cases that improve everyday boring tapscripts.
>
> > Sure, but I=E2=80=99d argue that the presence of risk now is a reason t=
o be more=20
> cautious about adding to it, rather than accepting it as inevitable.
>
> Addressing MEVil, if addressing MEVil is considered an important goal,
> requires being proactive and enabling the ability to build better
> protocols on Bitcoin. This is because, all things being equal,
> building a protocol that doesn't care about MEVil resistance is easier
> and requires less scripting functionality than one that does.
>
> On Wed, Jun 25, 2025 at 12:54=E2=80=AFPM 'Antoine Poinsot' via Bitcoin
> Development Mailing List <bitco...@googlegroups.com> wrote:
> >
> > Thanks for sharing some objections. Here is my attempt at addressing=20
> them.
> >
> > > ISTM even something as simple as a rate-limit requires more=20
> full-featured introspection than only
> > > "commit to the exact next transaction" can provide. For example, a=20
> trivial construction would be
> > > something which requires that transactions spending an output have an=
=20
> output which claims at least
> > > Amount - Rate, which requires both more full-featured introspection a=
s=20
> well as a bit of math.
> >
> > Yes. These capabilities are really only useful for reducing=20
> interactivity in second-layer protocols.
> > They do not (reasonably) help for vaults and we do not claim it as a us=
e=20
> case.
> >
> > Previous efforts to promote opcodes implementing those capabilities hav=
e=20
> unfortunately fallen into
> > the trap of overpromising and claiming use cases they do not really=20
> enable. But this should not make
> > us overlook what they are really good at: interactivity reduction.
> >
> > Do you think that the use cases presented in OP, if demonstrated, are=
=20
> not enough to warrant soft
> > forking in a primitive enabling them?
> >
> > > Given one of the loudest groups advocating for the additional feature=
s=20
> of CTV+CSFS are enterprise
> > > or large-value personal custody providers
> >
> > Yes. We intentionally do not mention vaults as a use case in our=20
> steelman. We should not change
> > Bitcoin on the basis of misleading use cases. If people are interested=
=20
> in vaults, they should
> > sponsor efforts on a different set of capabilities. Probably=20
> "programmable forwarding of value from
> > inputs to outputs", "programmable forwarding of spending conditions fro=
m=20
> inputs to outputs" and maybe
> > "commit to the exact transaction spending an output" (or more powerful=
=20
> introspection).
> >
> > The lack of a similar enthusiasm for proposals enabling most or all of=
=20
> these functionalities (like
> > Salvatore Ingala's BIP334 or previously James O'Beirne's and Greg=20
> Sanders' BIP345) suggests such
> > loud support are in fact in favour of "just doing something" and=20
> rationalize nice-sounding use cases
> > backward from this proposal (but vaults!) because it appears to them to=
=20
> be "further down the road".
> > I think this view is very dangerous and is part of our motivation for=
=20
> redirecting discussions toward
> > what these capabilities actually enable.
> >
> > > it seems somewhat of a loss to not work our way towards really basic=
=20
> features for this use-case.
> >
> > I personally grew more skeptical of the reactive security model of=20
> vaults after working on it. Your
> > mileage may vary and that's fine if people want to work on capabilities=
=20
> that actually enable vaults,
> > but i don't think they should be a required use cases and block=20
> introducing primitives that
> > substantially improve existing layer 2s and make new ones possible.
> >
> > > Indeed, ISTM many use-cases for a construction like TXHASH become a=
=20
> lot more substantial with Math
> > > [...], I'm quite skeptical that *just* looking at an individual fork=
=20
> on its own is the right
> > > benchmark.
> >
> > I agree that modularity and forward composability with potential future=
=20
> upgrades are arguments in
> > favour of a more flexible approach. But those need to be balanced with=
=20
> the additional risk and
> > implementation complexity such an approach entails. I'm happy to be=20
> convinced if supporters of this
> > approach demonstrate the added flexibility does enable important use=20
> cases and the risks associated
> > are manageable. But if nobody is interested in doing so, i don't think=
=20
> it's reasonable to hold off a
> > safer upgrade as long as it is demonstrated to provide substantial=20
> benefits.
> >
> > It's also unclear that we should stop at "programmable introspection" i=
n=20
> this case. Why not also
> > include "programmable amount / spending condition forwarding" too, whic=
h=20
> would give you vaults? Why
> > not even CAT, which is a neat tool in many situations and would let ZK=
=20
> people experiment with
> > validation rollups? And at this point, it would seem wiser to just work=
=20
> on a sane Bitcoin Script
> > replacement rather than throwing buckets of opcodes at it and hoping it=
=20
> holds off. Which as we say
> > in OP i don't think is realistic.
> >
> > > I don't see how this results in a net reduction in risk to Bitcoin,=
=20
> rather just means more total
> > > work and more cruft in Bitcoin's consensus.
> >
> > In theory, i agree. But by this token the same goes for every future=20
> extension that introduces more
> > expressivity to Bitcoin Script. This ties back to the stopping point:=
=20
> why add more cruft to the
> > existing interpreter when we could all focus on BTCLisp instead?
> >
> > It's also the case that even if future extensions introduce a superset=
=20
> of the capabilities being
> > discussed, it's unlikely that such simple ones like "just commit to the=
=20
> next transaction" and
> > "verify a signature for an arbitrary message" would ever be made fully=
=20
> redundant.
> >
> > Finally, when considering technical debt we should also weigh the actua=
l=20
> cost of the implementation
> > of these simple capabilities. Signature verification on arbitrary=20
> message reuses existing signature
> > checking logic. Similarly, committing to the next transaction can=20
> heavily lean on existing Taproot
> > signature messages, only minimally departing when necessary, and be=20
> implemented in a strictly
> > simpler manner than the existing CTV proposal. A minimal implementation=
=20
> of these capabilities would
> > not introduce significant technical debt.
> >
> > Interestingly, this argument applies more to introducing more involved=
=20
> capabilities like arbitrary
> > transaction introspection, because of the substantially larger technica=
l=20
> debt it would impose to
> > first support in Bitcoin Script instead of focusing on a replacement=20
> with transaction introspection
> > from the get go.
> >
> > > Indeed, more flexible introspection provides for a difference in risk=
=20
> to the system (though its
> > > worth noting we cannot both argue that there is no "demonstrated=20
> utility" *and* that the utility
> > > of a change is so substantially higher that it adds material risk to=
=20
> the system in the form of
> > > MEVil from its use-cases).
> >
> > Yes we can? It's reasonable to see how arbitrary introspection could be=
=20
> useful in various handwavy
> > ways, and therefore how they can be used for undesirable applications,=
=20
> while also not having an
> > important use case it enables clearly defined, much less demonstrated.
> >
> > > However, given the uses of the Bitcoin chain today, it seems entirely=
=20
> possible (assuming
> > > sufficient adoption) that we end up with a substantial MEVil risk wit=
h=20
> or without any
> > > functionality expansion.
> >
> > Sure, but I=E2=80=99d argue that the presence of risk now is a reason t=
o be more=20
> cautious about adding to
> > it, rather than accepting it as inevitable.
> >
> > Best,
> > Antoine
> >
> >
> > On Tuesday, June 24th, 2025 at 12:00 PM, Matt Corallo <
> lf-l...@mattcorallo.com> wrote:
> >
> > >
> > >
> > > Thanks, responding to one specific point:
> > >
> > > On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing=
=20
> List wrote:
> > >
> > > > Yet another alternative is a set of more powerful capabilities,=20
> enabling the use cases that "commit to next transaction"
> > > > and "verify a BIP340 signature for an arbitrary message" enable and=
=20
> more. For instance replacing "commit to the exact
> > > > transaction which must spend this output" with "programmable=20
> introspection on the spending transaction's fields" has
> > > > been considered. However this approach increases implementation=20
> complexity and broadens the risk surface[^8]
> > >
> > >
> > > Responded to below [1]
> > >
> > > > which
> > > > warrants a compelling demonstration that arbitrary transaction=20
> introspection does enable important use cases not
> > > > achievable with more minimal capabilities.
> > >
> > >
> > > I'm somewhat skeptical that showing this isn't rather simple, though =
I=20
> admit I've spent less time
> > > thinking about these concepts. ISTM even something as simple as a=20
> rate-limit requires more
> > > full-featured introspection than only "commit to the exact next=20
> transaction" can provide. For
> > > example, a trivial construction would be something which requires tha=
t=20
> transactions spending an
> > > output have an output which claims at least Amount - Rate, which=20
> requires both more full-featured
> > > introspection as well as a bit of math. Given one of the loudest=20
> groups advocating for the
> > > additional features of CTV+CSFS are enterprise or large-value persona=
l=20
> custody providers, it seems
> > > somewhat of a loss to not work our way towards really basic features=
=20
> for this use-case.
> > >
> > > More generally, more full-featured introspection like TXHASH provides=
=20
> a lot of flexibility in the
> > > constructs people can build. For example, allowing BYO fees in the=20
> form of an additional input +
> > > output in a transaction, rather than fixing an anchor output in the=
=20
> fixed "next transaction"
> > > commitment to allow for fees (and then requiring the same additional=
=20
> input + output later). There's
> > > also open questions as to the incentive-compatibility of anchors in a=
=20
> world with expensive block
> > > space, as OOB fees become much cheaper.
> > >
> > > Indeed, ISTM many use-cases for a construction like TXHASH become a=
=20
> lot more substantial with Math
> > > (though, again, I spend less time thinking about the use-cases of=20
> these things than most, so I'm
> > > sure others have more examples), I'm quite skeptical that just lookin=
g=20
> at an individual fork on
> > > its own is the right benchmark. Sure, functionality in proposed=20
> changes to Bitcoin's consensus need
> > > to be well-justified, but they don't need to be well-justified purely=
=20
> on their own. We add things
> > > like OP_SUCCESS opcodes in soft forks specifically to expand the set=
=20
> of things we can do later, not
> > > specifically in this fork.
> > >
> > > If we assume that we end up wanting things like velocity limits (whic=
h=20
> I imagine we would?) then it
> > > seems to me we should do a logical fork that adds features today, but=
=20
> which will allow us to make
> > > minimal extensions in the future to further expand its use-cases=20
> later. Taking a more myopic view of
> > > the present and ignoring the future results in us doing one thing=20
> today, then effectively replacing
> > > it later by adding more flexibility in a new opcode later, subsuming=
=20
> the features of what we do
> > > today. I don't see how this results in a net reduction in risk to=20
> Bitcoin, rather just means more
> > > total work and more cruft in Bitcoin's consensus.
> > >
> > > [1]
> > >
> > > Responding to the MEVil question OOO because I think the above should=
=20
> go first :).
> > >
> > > Indeed, more flexible introspection provides for a difference in risk=
=20
> to the system (though its
> > > worth noting we cannot both argue that there is no "demonstrated=20
> utility" and that the utility of
> > > a change is so substantially higher that it adds material risk to the=
=20
> system in the form of MEVil
> > > from its use-cases). However, given the uses of the Bitcoin chain=20
> today, it seems entirely possible
> > > (assuming sufficient adoption) that we end up with a substantial MEVi=
l=20
> risk with or without any
> > > functionality expansion. This mandates a response from the Bitcoin=20
> development community in either
> > > case, and I'm confident that response can happen faster than any=20
> reasonable soft fork timeline.
> > >
> > > While its possible that existing CSV-based MEVil risk never grows=20
> beyond its current anemic state
> > > (due to preferences for stronger trust models from their users), and=
=20
> that there's a particularly
> > > clever design using expanded introspection that improves the trust=20
> model such that suddenly
> > > CSV-based protocol use explodes, ISTM given the risk and the need to=
=20
> mitigate it on its own, taking
> > > decisions that are sub-optimal for Bitcoin's consensus on this basis=
=20
> isn't accomplishing much and
> > > has real costs.
> > >
> > > Matt
> > >
> > > --
> > > 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, sen=
d=20
> an email to bitcoindev+...@googlegroups.com.
> > > To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/8a9a2299-ab4b-45a4-8b9d-9579=
8e6bb62a%40mattcorallo.com
> .
> >
> > --
> > 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/73PXNVcmgiN2Kba63P2SRZfs42lv=
gME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG=
2_e0%3D%40protonmail.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/=
88d14bbe-484c-4d12-a3e5-f894b17f5c64n%40googlegroups.com.

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

&gt; The ability to commit to the exact transaction spending an output is u=
seful to reduce interactivity in second-layer<br />protocols.<div><br /></d=
iv><div>Where do you stand on explicit commitments to neighbor prevouts? My=
 understanding is that this capability would be extremely useful, for BitVM=
 and for making offers to buy UTXOs. If the goal is to commit to the "exact=
 transaction spending an output," CTV alone wouldn't quite get you there.</=
div><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On We=
dnesday, June 25, 2025 at 5:28:02=E2=80=AFPM UTC-4 Ethan Heilman wrote:<br/=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">&gt;  Why not ev=
en CAT, which is a neat tool in many situations and would let ZK people exp=
eriment with validation rollups? And at this point, it would seem wiser to =
just work on a sane Bitcoin Script replacement rather than throwing buckets=
 of opcodes at it and hoping it holds off.
<br>
<br>A Bitcoin Script replacement is likely to be a lot of work and many of
<br>the features will be informed by what people are building at the time
<br>it is designed. Merging a low implementation complexity opcode like
<br>OP_CAT (BIP-347) would provide useful data to inform a Bitcoin Script
<br>replacement.
<br>
<br>In addition to allowing ZK people to experiment, OP_CAT also has many
<br>simple use cases that improve everyday boring tapscripts.
<br>
<br>&gt; Sure, but I=E2=80=99d argue that the presence of risk now is a rea=
son to be more cautious about adding to it, rather than accepting it as ine=
vitable.
<br>
<br>Addressing MEVil, if addressing MEVil is considered an important goal,
<br>requires being proactive and enabling the ability to build better
<br>protocols on Bitcoin. This is because, all things being equal,
<br>building a protocol that doesn&#39;t care about MEVil resistance is eas=
ier
<br>and requires less scripting functionality than one that does.
<br>
<br>On Wed, Jun 25, 2025 at 12:54=E2=80=AFPM &#39;Antoine Poinsot&#39; via =
Bitcoin
<br>Development Mailing List &lt;<a href data-email-masked rel=3D"nofollow"=
>bitco...@googlegroups.com</a>&gt; wrote:
<br>&gt;
<br>&gt; Thanks for sharing some objections. Here is my attempt at addressi=
ng them.
<br>&gt;
<br>&gt; &gt; ISTM even something as simple as a rate-limit requires more f=
ull-featured introspection than only
<br>&gt; &gt; &quot;commit to the exact next transaction&quot; can provide.=
 For example, a trivial construction would be
<br>&gt; &gt; something which requires that transactions spending an output=
 have an output which claims at least
<br>&gt; &gt; Amount - Rate, which requires both more full-featured introsp=
ection as well as a bit of math.
<br>&gt;
<br>&gt; Yes. These capabilities are really only useful for reducing intera=
ctivity in second-layer protocols.
<br>&gt; They do not (reasonably) help for vaults and we do not claim it as=
 a use case.
<br>&gt;
<br>&gt; Previous efforts to promote opcodes implementing those capabilitie=
s have unfortunately fallen into
<br>&gt; the trap of overpromising and claiming use cases they do not reall=
y enable. But this should not make
<br>&gt; us overlook what they are really good at: interactivity reduction.
<br>&gt;
<br>&gt; Do you think that the use cases presented in OP, if demonstrated, =
are not enough to warrant soft
<br>&gt; forking in a primitive enabling them?
<br>&gt;
<br>&gt; &gt; Given one of the loudest groups advocating for the additional=
 features of CTV+CSFS are enterprise
<br>&gt; &gt; or large-value personal custody providers
<br>&gt;
<br>&gt; Yes. We intentionally do not mention vaults as a use case in our s=
teelman. We should not change
<br>&gt; Bitcoin on the basis of misleading use cases. If people are intere=
sted in vaults, they should
<br>&gt; sponsor efforts on a different set of capabilities. Probably &quot=
;programmable forwarding of value from
<br>&gt; inputs to outputs&quot;, &quot;programmable forwarding of spending=
 conditions from inputs to outputs&quot; and maybe
<br>&gt; &quot;commit to the exact transaction spending an output&quot; (or=
 more powerful introspection).
<br>&gt;
<br>&gt; The lack of a similar enthusiasm for proposals enabling most or al=
l of these functionalities (like
<br>&gt; Salvatore Ingala&#39;s BIP334 or previously James O&#39;Beirne&#39=
;s and Greg Sanders&#39; BIP345) suggests such
<br>&gt; loud support are in fact in favour of &quot;just doing something&q=
uot; and rationalize nice-sounding use cases
<br>&gt; backward from this proposal (but vaults!) because it appears to th=
em to be &quot;further down the road&quot;.
<br>&gt; I think this view is very dangerous and is part of our motivation =
for redirecting discussions toward
<br>&gt; what these capabilities actually enable.
<br>&gt;
<br>&gt; &gt; it seems somewhat of a loss to not work our way towards reall=
y basic features for this use-case.
<br>&gt;
<br>&gt; I personally grew more skeptical of the reactive security model of=
 vaults after working on it.  Your
<br>&gt; mileage may vary and that&#39;s fine if people want to work on cap=
abilities that actually enable vaults,
<br>&gt; but i don&#39;t think they should be a required use cases and bloc=
k introducing primitives that
<br>&gt; substantially improve existing layer 2s and make new ones possible=
.
<br>&gt;
<br>&gt; &gt; Indeed, ISTM many use-cases for a construction like TXHASH be=
come a lot more substantial with Math
<br>&gt; &gt; [...], I&#39;m quite skeptical that *just* looking at an indi=
vidual fork on its own is the right
<br>&gt; &gt; benchmark.
<br>&gt;
<br>&gt; I agree that modularity and forward composability with potential f=
uture upgrades are arguments in
<br>&gt; favour of a more flexible approach. But those need to be balanced =
with the additional risk and
<br>&gt; implementation complexity such an approach entails. I&#39;m happy =
to be convinced if supporters of this
<br>&gt; approach demonstrate the added flexibility does enable important u=
se cases and the risks associated
<br>&gt; are manageable. But if nobody is interested in doing so, i don&#39=
;t think it&#39;s reasonable to hold off a
<br>&gt; safer upgrade as long as it is demonstrated to provide substantial=
 benefits.
<br>&gt;
<br>&gt; It&#39;s also unclear that we should stop at &quot;programmable in=
trospection&quot; in this case. Why not also
<br>&gt; include &quot;programmable amount / spending condition forwarding&=
quot; too, which would give you vaults? Why
<br>&gt; not even CAT, which is a neat tool in many situations and would le=
t ZK people experiment with
<br>&gt; validation rollups? And at this point, it would seem wiser to just=
 work on a sane Bitcoin Script
<br>&gt; replacement rather than throwing buckets of opcodes at it and hopi=
ng it holds off. Which as we say
<br>&gt; in OP i don&#39;t think is realistic.
<br>&gt;
<br>&gt; &gt; I don&#39;t see how this results in a net reduction in risk t=
o Bitcoin, rather just means more total
<br>&gt; &gt; work and more cruft in Bitcoin&#39;s consensus.
<br>&gt;
<br>&gt; In theory, i agree. But by this token the same goes for every futu=
re extension that introduces more
<br>&gt; expressivity to Bitcoin Script. This ties back to the stopping poi=
nt: why add more cruft to the
<br>&gt; existing interpreter when we could all focus on BTCLisp instead?
<br>&gt;
<br>&gt; It&#39;s also the case that even if future extensions introduce a =
superset of the capabilities being
<br>&gt; discussed, it&#39;s unlikely that such simple ones like &quot;just=
 commit to the next transaction&quot; and
<br>&gt; &quot;verify a signature for an arbitrary message&quot; would ever=
 be made fully redundant.
<br>&gt;
<br>&gt; Finally, when considering technical debt we should also weigh the =
actual cost of the implementation
<br>&gt; of these simple capabilities. Signature verification on arbitrary =
message reuses existing signature
<br>&gt; checking logic. Similarly, committing to the next transaction can =
heavily lean on existing Taproot
<br>&gt; signature messages, only minimally departing when necessary, and b=
e implemented in a strictly
<br>&gt; simpler manner than the existing CTV proposal. A minimal implement=
ation of these capabilities would
<br>&gt; not introduce significant technical debt.
<br>&gt;
<br>&gt; Interestingly, this argument applies more to introducing more invo=
lved capabilities like arbitrary
<br>&gt; transaction introspection, because of the substantially larger tec=
hnical debt it would impose to
<br>&gt; first support in Bitcoin Script instead of focusing on a replaceme=
nt with transaction introspection
<br>&gt; from the get go.
<br>&gt;
<br>&gt; &gt; Indeed, more flexible introspection provides for a difference=
 in risk to the system (though its
<br>&gt; &gt; worth noting we cannot both argue that there is no &quot;demo=
nstrated utility&quot; *and* that the utility
<br>&gt; &gt; of a change is so substantially higher that it adds material =
risk to the system in the form of
<br>&gt; &gt; MEVil from its use-cases).
<br>&gt;
<br>&gt; Yes we can? It&#39;s reasonable to see how arbitrary introspection=
 could be useful in various handwavy
<br>&gt; ways, and therefore how they can be used for undesirable applicati=
ons, while also not having an
<br>&gt; important use case it enables clearly defined, much less demonstra=
ted.
<br>&gt;
<br>&gt; &gt; However, given the uses of the Bitcoin chain today, it seems =
entirely possible (assuming
<br>&gt; &gt; sufficient adoption) that we end up with a substantial MEVil =
risk with or without any
<br>&gt; &gt; functionality expansion.
<br>&gt;
<br>&gt; Sure, but I=E2=80=99d argue that the presence of risk now is a rea=
son to be more cautious about adding to
<br>&gt; it, rather than accepting it as inevitable.
<br>&gt;
<br>&gt; Best,
<br>&gt; Antoine
<br>&gt;
<br>&gt;
<br>&gt; On Tuesday, June 24th, 2025 at 12:00 PM, Matt Corallo &lt;<a href =
data-email-masked rel=3D"nofollow">lf-l...@mattcorallo.com</a>&gt; wrote:
<br>&gt;
<br>&gt; &gt;
<br>&gt; &gt;
<br>&gt; &gt; Thanks, responding to one specific point:
<br>&gt; &gt;
<br>&gt; &gt; On 6/23/25 9:14 AM, &#39;Antoine Poinsot&#39; via Bitcoin Dev=
elopment Mailing List wrote:
<br>&gt; &gt;
<br>&gt; &gt; &gt; Yet another alternative is a set of more powerful capabi=
lities, enabling the use cases that &quot;commit to next transaction&quot;
<br>&gt; &gt; &gt; and &quot;verify a BIP340 signature for an arbitrary mes=
sage&quot; enable and more. For instance replacing &quot;commit to the exac=
t
<br>&gt; &gt; &gt; transaction which must spend this output&quot; with &quo=
t;programmable introspection on the spending transaction&#39;s fields&quot;=
 has
<br>&gt; &gt; &gt; been considered. However this approach increases impleme=
ntation complexity and broadens the risk surface[^8]
<br>&gt; &gt;
<br>&gt; &gt;
<br>&gt; &gt; Responded to below [1]
<br>&gt; &gt;
<br>&gt; &gt; &gt; which
<br>&gt; &gt; &gt; warrants a compelling demonstration that arbitrary trans=
action introspection does enable important use cases not
<br>&gt; &gt; &gt; achievable with more minimal capabilities.
<br>&gt; &gt;
<br>&gt; &gt;
<br>&gt; &gt; I&#39;m somewhat skeptical that showing this isn&#39;t rather=
 simple, though I admit I&#39;ve spent less time
<br>&gt; &gt; thinking about these concepts. ISTM even something as simple =
as a rate-limit requires more
<br>&gt; &gt; full-featured introspection than only &quot;commit to the exa=
ct next transaction&quot; can provide. For
<br>&gt; &gt; example, a trivial construction would be something which requ=
ires that transactions spending an
<br>&gt; &gt; output have an output which claims at least Amount - Rate, wh=
ich requires both more full-featured
<br>&gt; &gt; introspection as well as a bit of math. Given one of the loud=
est groups advocating for the
<br>&gt; &gt; additional features of CTV+CSFS are enterprise or large-value=
 personal custody providers, it seems
<br>&gt; &gt; somewhat of a loss to not work our way towards really basic f=
eatures for this use-case.
<br>&gt; &gt;
<br>&gt; &gt; More generally, more full-featured introspection like TXHASH =
provides a lot of flexibility in the
<br>&gt; &gt; constructs people can build. For example, allowing BYO fees i=
n the form of an additional input +
<br>&gt; &gt; output in a transaction, rather than fixing an anchor output =
in the fixed &quot;next transaction&quot;
<br>&gt; &gt; commitment to allow for fees (and then requiring the same add=
itional input + output later). There&#39;s
<br>&gt; &gt; also open questions as to the incentive-compatibility of anch=
ors in a world with expensive block
<br>&gt; &gt; space, as OOB fees become much cheaper.
<br>&gt; &gt;
<br>&gt; &gt; Indeed, ISTM many use-cases for a construction like TXHASH be=
come a lot more substantial with Math
<br>&gt; &gt; (though, again, I spend less time thinking about the use-case=
s of these things than most, so I&#39;m
<br>&gt; &gt; sure others have more examples), I&#39;m quite skeptical that=
 just looking at an individual fork on
<br>&gt; &gt; its own is the right benchmark. Sure, functionality in propos=
ed changes to Bitcoin&#39;s consensus need
<br>&gt; &gt; to be well-justified, but they don&#39;t need to be well-just=
ified purely on their own. We add things
<br>&gt; &gt; like OP_SUCCESS opcodes in soft forks specifically to expand =
the set of things we can do later, not
<br>&gt; &gt; specifically in this fork.
<br>&gt; &gt;
<br>&gt; &gt; If we assume that we end up wanting things like velocity limi=
ts (which I imagine we would?) then it
<br>&gt; &gt; seems to me we should do a logical fork that adds features to=
day, but which will allow us to make
<br>&gt; &gt; minimal extensions in the future to further expand its use-ca=
ses later. Taking a more myopic view of
<br>&gt; &gt; the present and ignoring the future results in us doing one t=
hing today, then effectively replacing
<br>&gt; &gt; it later by adding more flexibility in a new opcode later, su=
bsuming the features of what we do
<br>&gt; &gt; today. I don&#39;t see how this results in a net reduction in=
 risk to Bitcoin, rather just means more
<br>&gt; &gt; total work and more cruft in Bitcoin&#39;s consensus.
<br>&gt; &gt;
<br>&gt; &gt; [1]
<br>&gt; &gt;
<br>&gt; &gt; Responding to the MEVil question OOO because I think the abov=
e should go first :).
<br>&gt; &gt;
<br>&gt; &gt; Indeed, more flexible introspection provides for a difference=
 in risk to the system (though its
<br>&gt; &gt; worth noting we cannot both argue that there is no &quot;demo=
nstrated utility&quot; and that the utility of
<br>&gt; &gt; a change is so substantially higher that it adds material ris=
k to the system in the form of MEVil
<br>&gt; &gt; from its use-cases). However, given the uses of the Bitcoin c=
hain today, it seems entirely possible
<br>&gt; &gt; (assuming sufficient adoption) that we end up with a substant=
ial MEVil risk with or without any
<br>&gt; &gt; functionality expansion. This mandates a response from the Bi=
tcoin development community in either
<br>&gt; &gt; case, and I&#39;m confident that response can happen faster t=
han any reasonable soft fork timeline.
<br>&gt; &gt;
<br>&gt; &gt; While its possible that existing CSV-based MEVil risk never g=
rows beyond its current anemic state
<br>&gt; &gt; (due to preferences for stronger trust models from their user=
s), and that there&#39;s a particularly
<br>&gt; &gt; clever design using expanded introspection that improves the =
trust model such that suddenly
<br>&gt; &gt; CSV-based protocol use explodes, ISTM given the risk and the =
need to mitigate it on its own, taking
<br>&gt; &gt; decisions that are sub-optimal for Bitcoin&#39;s consensus on=
 this basis isn&#39;t accomplishing much and
<br>&gt; &gt; has real costs.
<br>&gt; &gt;
<br>&gt; &gt; Matt
<br>&gt; &gt;
<br>&gt; &gt; --
<br>&gt; &gt; You received this message because you are subscribed to the G=
oogle Groups &quot;Bitcoin Development Mailing List&quot; group.
<br>&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">bitcoindev=
+...@googlegroups.com</a>.
<br>&gt; &gt; To view this discussion visit <a href=3D"https://groups.googl=
e.com/d/msgid/bitcoindev/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo=
.com" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://ww=
w.google.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoind=
ev/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%2540mattcorallo.com&amp;source=3Dgm=
ail&amp;ust=3D1751039208393000&amp;usg=3DAOvVaw3KxgYywPOxZxYn5QvpCOmM">http=
s://groups.google.com/d/msgid/bitcoindev/8a9a2299-ab4b-45a4-8b9d-95798e6bb6=
2a%40mattcorallo.com</a>.
<br>&gt;
<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/73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5=
JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG2_e0%3D%40protonmail.com" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/d/msgid/bitcoindev/73PX=
NVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtkOSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKr=
haa1F53OgIJOcam-kbOUP3aG2_e0%253D%2540protonmail.com&amp;source=3Dgmail&amp=
;ust=3D1751039208393000&amp;usg=3DAOvVaw0J7r28RCLl9_0MOB2R6vyb">https://gro=
ups.google.com/d/msgid/bitcoindev/73PXNVcmgiN2Kba63P2SRZfs42lvgME_8EF-DlYtk=
OSY8mLRxEXPEw5JAi5wtPU2MEMw1C6_EDFHKKrhaa1F53OgIJOcam-kbOUP3aG2_e0%3D%40pro=
tonmail.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/88d14bbe-484c-4d12-a3e5-f894b17f5c64n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/88d14bbe-484c-4d12-a3e5-f894b17f5c64n%40googlegroups.com</a>.<br />

------=_Part_3299_2005966468.1750953760462--

------=_Part_3298_303281863.1750953760462--