From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Jun 2025 13:23:16 -0700 Received: from mail-yw1-f185.google.com ([209.85.128.185]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uUWeJ-0005vx-JW for bitcoindev@gnusha.org; Wed, 25 Jun 2025 13:23:16 -0700 Received: by mail-yw1-f185.google.com with SMTP id 00721157ae682-7111d608131sf4745187b3.1 for ; Wed, 25 Jun 2025 13:23:15 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750882989; cv=pass; d=google.com; s=arc-20240605; b=ZALx4HJ37NGhzr54EgKdEL3q7D36xlanOvgYdJdJ3STEp/V8deaXxkHRra7oNRXtRd J9rqtQkAIOzXgO50+Ij7Por6IEcVXycnGaJT6C2D615QzWGfHEBWleB5bmQsFnlrgJpo GmmTuzyGK40cuPkOhU7etUUXNlCAB5f9vj9ka5wb008lEb111sXmKLr7NSh30maDeTC4 OfmVNvhhwPsRWnwGTmzJw3ruhFb3rFgjtCm4DWuIe1BQ/XqbRB7cJbJ1Kh9mRd1eVpFU awA0tdv7g7P0tksCcleNHIwxritfpDjPKT2RmbPzKfjr4qSPGokJDywXVczwVkWpvSA8 s/kQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=yJFPSzqDnGtc1llW5Ip0D+wQafpt/Gn+1BfrYXUYQfA=; fh=5hWMtTq09C6OkCss6EjejdqFY25pL3TznmiJJqVjNVE=; b=MGj0TTLSfnY9/UqGpoJm90lTfnLZYdTgQzKd+5PyNl/IyCn4BZUwQEiTj4AAfviGr6 WQF90b8g0iu/bAOz+MsYlG4yRa6+5sEfZBjekcyK0obGN2Wcs+bHcc71RBPv6ojxxFyQ 5QLGxpvoUQnpTiHKdQFeCFZhoZyW6jZ7ynyMkeCgwxONnhzpGyzIpRxE+wMHDIvIHjXz 6c3HYq96yeghYGKASuPd+7t2I/fesTl7NZlOfXDSm1NgkxBHNlgjfhB6TyJwmUfzbdNf 1FhIqgGTEPHoi299yOJzmohYrxue4kKGTPMhwuKWR4OKgJxsJ3vj/zKw/OLd5THST2Nw XV8g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IMqggSiP; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750882989; x=1751487789; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=yJFPSzqDnGtc1llW5Ip0D+wQafpt/Gn+1BfrYXUYQfA=; b=BkdKR/Ngr86mdjEvQmf631jbVpY+pnvFBp4vPNLmhukmq18zaTMoKbIzvaxrmPEFWd cKetZif6VCjS/hLyJUbOuBJBAHcGafhEu323A+Ui4y3eZK3rrfye/wake7Q4rgSz4/LY NiWQQHEHoNR9TBzWg4En699gDi0x8nZk0mxsGx7bLHo/p4Qj0TX4K3Oo90VM+As2Em1a g7z43lWPxHEiV5ZXSlpbIDh4nQ09mKDAOdU3GtfY0SbaQ0csijsHlDWEWLi7RJrlZZ7u +tNRDhMkirz8AhLM5bIPNnu5Mp9AxS8fIYTM/pldGy/HIDkgBmJ3q1pqa6tIlnB2JtOA tQyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750882989; x=1751487789; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yJFPSzqDnGtc1llW5Ip0D+wQafpt/Gn+1BfrYXUYQfA=; b=DyF94GuTBH00tWBjnMiWerrnAsjkQTG3FWN41wI46iLxzRiLtMVd51YKmtbSSDJdxO j/2NzL4T6vynyOVykRZnVfrAyUNFNQ1hbrC9nuLOjbUp6vxI20dMTl10FVhZYnI5Ohxv FEyc590pXBJTcEvEG2R08LaulW6JMEWlULUalLfGibqw8SoJRrmmo3nch6AMSiJLdyuq mBH+Vx4rx4HbEKS+h9XCOWRTTGe2hHkcHpl2W76HdYkh4TdN0MAa89hn1a2dxNLA/x/D bObD5LlIPxzBrOIdfuRsNQ4a/mbUjcxftitZKsqAQWcpQ7FHif9wOCOQEnwBig3cha00 WxSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750882989; x=1751487789; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=yJFPSzqDnGtc1llW5Ip0D+wQafpt/Gn+1BfrYXUYQfA=; b=AlbqzmopDXzrbuGn8uKj3k9Mrrp1CpBNdQX9GnUB/MVS6nlVAU1lHlrsH+8uikxSgS ViLk6KD36bI7qM/RXE1HLUcUNdlpG1Buffu7B7Bx+OZa5NmOO4V4NcdBy2MqbE6Z7idf 51fD/j36I6+8iy0+TqgyctposljjFpH14kCcgsFG/lJAx7y9E/DECVbBMVIBa8Br1euv +7gVEBGk5aBZDwd3t0ZFuDCt1EpLvhOnxoMK7rYue4uUlOWHoWlQEPdQgMWcEnRckHwV 2QOEouHg7/nf4zlicRsM+U9LXzkqqnrVWIQITuPdML/eumKVf3U/Pj/1j4gp2RolP2lR COCw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWqIQAEvnK96U4DuGdMbC36iESD0gUM0AW4CheyZ1zJUG+LtaL83zGXyAx0FO67C00zZE06qOi4fZ5A@gnusha.org X-Gm-Message-State: AOJu0Yxs0I71Td+pK+FV1FlcpAIiQTTFi4Bo+z1a8qENjKKoPhxzVS+h tUpRM4VVpPtyLsoMRJvnbemCxiILoZBKX3GB95AhT34AAmk/99aJp0wX X-Google-Smtp-Source: AGHT+IEin5WVdOrkSROzyLtUcmdPN6Pll0nN0pRhRN38ODLGhxfJS7T7XyWWzViLyb70eRTzrayWiQ== X-Received: by 2002:a05:6902:1616:b0:e84:1e0f:f018 with SMTP id 3f1490d57ef6-e86017c4c21mr5294650276.30.1750882988947; Wed, 25 Jun 2025 13:23:08 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdwZflgtSnzQXBqyFNg1LliQC/Sb2nCA/GXm47GiWNrCQ== Received: by 2002:a05:6902:4182:b0:e82:7237:fdc9 with SMTP id 3f1490d57ef6-e879c4171bels267488276.2.-pod-prod-07-us; Wed, 25 Jun 2025 13:23:05 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCW/Z8M+KlmQPuXVuMaN7X1GK0edDR8xpwnGntYdWI2py6bkZQYtlj/VBKWf4yPDgxMnW+8XmWhfEcMJ@googlegroups.com X-Received: by 2002:a05:690c:6ac4:b0:70e:7663:8bb4 with SMTP id 00721157ae682-71406e064cbmr65274757b3.25.1750882985456; Wed, 25 Jun 2025 13:23:05 -0700 (PDT) Received: by 2002:a05:690c:2c01:b0:710:fccf:6901 with SMTP id 00721157ae682-7140614b88bms7b3; Wed, 25 Jun 2025 12:22:42 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCVq2jX31/jHMyZB7ml6IyTawdyy8rAHH9xcpFEutOArMvYSXWGEmm68idG21Gg+gotAnXJQOxOHCZAi@googlegroups.com X-Received: by 2002:a05:6902:2401:b0:e7d:a7c7:3f34 with SMTP id 3f1490d57ef6-e86018bb96dmr4867919276.32.1750879360840; Wed, 25 Jun 2025 12:22:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750879360; cv=none; d=google.com; s=arc-20240605; b=LPkW4fBKedbAMDkgL+xus1+Y1dUJY8ZQo0E9k4kjPyq3rqxZlCQfG8hsp6CQzSLinC UvZXft3xoPQzxjkSjTetsb8eCDCFD0tFdLXumVAfqs/J9a3+sOJ2Btm9TzBtvnX3x/Km XB99eZnXRekgj5I71HJvg4FZvyZx2ZRxqKdliQHFIYuH5RapqB8X9lnQVm8OXVUklHxm YwLqAZXNiaezDlvtiI+H65Tl2b4RE2OGKWDJFOZmY7kRZ5cZj9UNUIJSxoRG/EU/ngpD 4C2LBa0+IIYUGsypEI0Ckr/gPOn3o115WVXICzrPTQ8eBU6jgb4UrxtE4d37xLHAaWeg xQNQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=pXitljOTkwFG+gCSCk9g/d/Jva6J83MbBIKg8YLDIdU=; fh=d1nZQ6gayGY8OwmCk98HkjPHaMF6mV8SASZlq8oGI4o=; b=CmhoeyLn0772YXDK3WDiH4WRXlUy4e21uC+KdEjC/8QyUj18D2ikEMIACbPfyD5Leu 7ebH/iWTYXvCjGBgCbVHv6qnpoto+Pk1a9yEw26YPA/o9StrhNoLqgI6X+i3B6qCeIUW +jbQGqiF8QigtEpzj9I2XoTXsZy7ZwToHFyL2kOBndP5DsLhNB/Rq7ziAe2mbg+UVk+K sypRU/I4ZTMPEqXkKNw9N7qb7H04qAristj88HHof/OhUh5+hy3/62aASSRPpl+Jac5l RWBD0FXeRFSH2vYf/e1Te9RhoBmOnOx0j/Qq+cJ9D6sPqH6OILnJtDLixH5jTLp9kMci It0A==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IMqggSiP; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-yw1-x112a.google.com (mail-yw1-x112a.google.com. [2607:f8b0:4864:20::112a]) by gmr-mx.google.com with ESMTPS id 3f1490d57ef6-e842abdc75asi765673276.2.2025.06.25.12.22.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 25 Jun 2025 12:22:40 -0700 (PDT) Received-SPF: pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) client-ip=2607:f8b0:4864:20::112a; Received: by mail-yw1-x112a.google.com with SMTP id 00721157ae682-70e40e3f316so2495317b3.0 for ; Wed, 25 Jun 2025 12:22:40 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCXQpFEaTK6QJdme+q0V176S3CQ3VbGKnVUjqjTjVfX1p0BWIpEYG8WhLdusu0KGnEdqes+Nd7PgR97j@googlegroups.com X-Gm-Gg: ASbGncvCmkv1LCKe4usGSob6zs3LBDPYPDrGDrsDrjvFnLXVYmPwJWQJSofyttUInoS Cl0SdX8pAwJbV3IWt74V4jSPKzTG93YtR5KnZREo6e0Jcnl1f7h9AZX0QMQ2ExaJjbvAbefetp1 oT2AlTPIu0mxVYIC0nJ641JM4W5Z3BsqWHR4UFhhiEayuLMM6qwgPxuw== X-Received: by 2002:a05:690c:498e:b0:711:4fbe:e475 with SMTP id 00721157ae682-71406cc8abbmr67866467b3.12.1750879360367; Wed, 25 Jun 2025 12:22:40 -0700 (PDT) MIME-Version: 1.0 References: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> In-Reply-To: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com> From: Chris Stewart Date: Wed, 25 Jun 2025 14:22:29 -0500 X-Gm-Features: Ac12FXzJGCpPwTAO7qAnwNhECAzcqWTFUQaiL2jyGJfLv_eEMO_7IQEneRQxVTI Message-ID: Subject: Re: [bitcoindev] What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS To: Matt Corallo Cc: Antoine Poinsot , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="00000000000051c10b06386a5e84" X-Original-Sender: stewart.chris1234@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=IMqggSiP; spf=pass (google.com: domain of stewart.chris1234@gmail.com designates 2607:f8b0:4864:20::112a as permitted sender) smtp.mailfrom=stewart.chris1234@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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 (/) --00000000000051c10b06386a5e84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >For example, a trivial construction would be something which requires that transactions spending an output have an output which claims at least Amount - Rate, which requires both more full-featured introspection as well as a bit of math. I agree this could be a useful primitive in the Script language, which has been a motivating factor in my work on 64-bit arithmetic [0] and OP_{IN,OUT}_AMOUNT [1]. I've prototyped two vault-related opcodes=E2=80=94O= P_VAULT and OP_CHECKCONTRACTVERIFY=E2=80=94using OP_{IN,OUT}_AMOUNT [2][3]. While t= he current proposal has some clear limitations (namely, what I refer to as =E2=80=9Camount replay attacks=E2=80=9D), I believe these can be mitigated = via Taproot annex usage, as proposed by Antoine Poinsot [4]. That approach has not yet been prototyped, though. That said, I don't see amount lock opcodes as being mutually exclusive with hash-based covenant or introspection opcodes. In fact, I suspect experimenting with the hash-based primitives will help reveal their limitations and inform better design decisions for the next generation of introspection opcodes to be considered for Bitcoin. [0] =E2=80=93 https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE [1] =E2=80=93 https://delvingbitcoin.org/t/op-inout-amount/549/3?u=3Dchris_= stewart_5 [2] =E2=80=93 https://delvingbitcoin.org/t/op-inout-amount/549/4?u=3Dchris_= stewart_5 [3] =E2=80=93 https://delvingbitcoin.org/t/op-inout-amount/549/5?u=3Dchris_= stewart_5 [4] =E2=80=93 https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic= /1527/6?u=3Dchris_stewart_5 On Tue, Jun 24, 2025 at 11:00=E2=80=AFAM Matt Corallo wrote: > Thanks, responding to one specific point: > > On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Mailing Lis= t > wrote: > > Yet another alternative is a set of more powerful capabilities, enablin= g > the use cases that "commit to next transaction" > > and "verify a BIP340 signature for an arbitrary message" enable and > more. For instance replacing "commit to the exact > > transaction which must spend this output" with "programmable > introspection on the spending transaction's fields" has > > been considered. However this approach increases implementation > complexity and broadens the risk surface[^8] > > Responded to below [1] > > > which > > warrants a compelling demonstration that arbitrary transaction > 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 > admit I've spent less time > thinking about these concepts. ISTM even something as simple as a > rate-limit requires more > full-featured introspection than only "commit to the exact next > transaction" can provide. For > example, a trivial construction would be something which requires that > transactions spending an > output have an output which claims at least Amount - Rate, which requires > both more full-featured > introspection as well as a bit of math. Given one of the loudest groups > advocating for the > additional features of CTV+CSFS are enterprise or large-value personal > custody providers, it seems > somewhat of a loss to not work our way towards really basic features for > this use-case. > > More generally, more full-featured introspection like TXHASH provides a > lot of flexibility in the > constructs people can build. For example, allowing BYO fees in the form o= f > an additional input + > output in a transaction, rather than fixing an anchor output in the fixed > "next transaction" > commitment to allow for fees (and then requiring the same additional inpu= t > + output later). There's > also open questions as to the incentive-compatibility of anchors in a > world with expensive block > space, as OOB fees become much cheaper. > > Indeed, ISTM many use-cases for a construction like TXHASH become a lot > more substantial with Math > (though, again, I spend less time thinking about the use-cases of these > things than most, so I'm > sure others have more examples), I'm quite skeptical that *just* looking > at an individual fork on > its own is the right benchmark. Sure, functionality in proposed changes t= o > Bitcoin's consensus need > to be well-justified, but they don't need to be well-justified *purely on > their own*. We add things > like OP_SUCCESS opcodes in soft forks specifically to expand the set of > things we can do later, not > specifically in this fork. > > If we assume that we end up wanting things like velocity limits (which I > imagine we would?) then it > seems to me we should do a logical fork that adds features today, but > which will allow us to make > minimal extensions in the future to further expand its use-cases later. > Taking a more myopic view of > the present and ignoring the future results in us doing one thing today, > then effectively replacing > it later by adding more flexibility in a new opcode later, subsuming the > features of what we do > today. I don't see how this results in a net reduction in risk to 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 go > first :). > > Indeed, more flexible introspection provides for a difference in risk to > the system (though its > worth noting we cannot both argue that there is no "demonstrated utility" > *and* that the utility of > a change is so substantially higher that it adds material risk to the > system in the form of MEVil > from its use-cases). However, given the uses of the Bitcoin chain today, > it seems entirely possible > (assuming sufficient adoption) that we end up with a substantial MEVil > risk with or without any > functionality expansion. This mandates a response from the Bitcoin > development community in either > case, and I'm confident that response can happen faster than any > reasonable soft fork timeline. > > While its possible that existing CSV-based MEVil risk never grows beyond > its current anemic state > (due to preferences for stronger trust models from their users), and that > there's a particularly > clever design using expanded introspection that improves the trust model > such that suddenly > CSV-based protocol use explodes, ISTM given the risk and the need to > mitigate it on its own, taking > decisions that are sub-optimal for Bitcoin's consensus on this basis isn'= t > accomplishing much and > has real costs. > > Matt > > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/8a9a2299-ab4b-45a4-8b9d-9579= 8e6bb62a%40mattcorallo.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/= CAGL6%2BmHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr%3DQVvXUg%40mail.gmail.com. --00000000000051c10b06386a5e84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>For example, a trivial construction would be something= which requires that transactions spending an
output have an output which claims at least Amount - Rate, which requires b= oth more full-featured
introspection as well as a bit of math.

I agree this could be a useful primitive in the Script language, which h= as been a motivating factor in my work on 64-bit arithmetic [0] and O= P_{IN,OUT}_AMOUNT [1]. I've prototyped two vault-related opcodes= =E2=80=94OP_VAULT and OP_CHECKCONTRACTVERIFY=E2= =80=94using OP_{IN,OUT}_AMOUNT [2][3]. While the current propo= sal has some clear limitations (namely, what I refer to as =E2=80=9Camount = replay attacks=E2=80=9D), I believe these can be mitigated via Taproot anne= x usage, as proposed by Antoine Poinsot [4]. That approach has not yet been= prototyped, though.

That said, I don't see amount lock opcodes as being mutually exclusi= ve with hash-based covenant or introspection opcodes. In fact, I suspect ex= perimenting with the hash-based primitives will help reveal their limitatio= ns and inform better design decisions for the next generation of introspect= ion opcodes to be considered for Bitcoin.

[0] =E2=80=93 https://groups.google.com/g/bitcoi= ndev/c/j1zEky-3QEE
[1] =E2=80=93 https://delvingbitc= oin.org/t/op-inout-amount/549/3?u=3Dchris_stewart_5
[2] =E2=80=93 https://delvingbitc= oin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5
[3] =E2=80=93 https://delvingbitc= oin.org/t/op-inout-amount/549/5?u=3Dchris_stewart_5
[4] =E2=80=93 https://delvingbitcoin.org/t/op-checkcontractverify-and-its-am= ount-semantic/1527/6?u=3Dchris_stewart_5



=C2=A0


On Tue, Jun 24= , 2025 at 11:00=E2=80=AFAM Matt Corallo <lf-lists@mattcorallo.com> wrote:
Thanks, responding to one specific poi= nt:

On 6/23/25 9:14 AM, 'Antoine Poinsot' via Bitcoin Development Maili= ng List wrote:
> Yet another alternative is a set of more powerful capabilities, enabli= ng the use cases that "commit to next transaction"
> and "verify a BIP340 signature for an arbitrary message" ena= ble and more. For instance replacing "commit to the exact
> transaction which must spend this output" with "programmable= introspection on the spending transaction's fields" has
> been considered. However this approach increases implementation comple= xity and broadens the risk surface[^8]

Responded to below [1]

> which
> warrants a compelling demonstration that arbitrary transaction introsp= ection does enable important use cases not
> achievable with more minimal capabilities.

I'm somewhat skeptical that showing this isn't rather simple, thoug= h I admit I've spent less time
thinking about these concepts. ISTM even something as simple as a rate-limi= t requires more
full-featured introspection than only "commit to the exact next transa= ction" can provide. For
example, a trivial construction would be something which requires that tran= sactions spending an
output have an output which claims at least Amount - Rate, which requires b= oth more full-featured
introspection as well as a bit of math. Given one of the loudest groups adv= ocating for the
additional features of CTV+CSFS are enterprise or large-value personal cust= ody providers, it seems
somewhat of a loss to not work our way towards really basic features for th= is use-case.

More generally, more full-featured introspection like TXHASH provides a lot= of flexibility in the
constructs people can build. For example, allowing BYO fees in the form of = an additional input +
output in a transaction, rather than fixing an anchor output in the fixed &= quot;next transaction"
commitment to allow for fees (and then requiring the same additional input = + output later). There's
also open questions as to the incentive-compatibility of anchors in a world= with expensive block
space, as OOB fees become much cheaper.

Indeed, ISTM many use-cases for a construction like TXHASH become a lot mor= e substantial with Math
(though, again, I spend less time thinking about the use-cases of these thi= ngs than most, so I'm
sure others have more examples), I'm quite skeptical that *just* lookin= g at an individual fork on
its own is the right benchmark. Sure, functionality in proposed changes to = Bitcoin's consensus need
to be well-justified, but they don't need to be well-justified *purely = on their own*. We add things
like OP_SUCCESS opcodes in soft forks specifically to expand the set of thi= ngs we can do later, not
specifically in this fork.

If we assume that we end up wanting things like velocity limits (which I im= agine we would?) then it
seems to me we should do a logical fork that adds features today, but which= will allow us to make
minimal extensions in the future to further expand its use-cases later. Tak= ing a more myopic view of
the present and ignoring the future results in us doing one thing today, th= en effectively replacing
it later by adding more flexibility in a new opcode later, subsuming the fe= atures of what we do
today. I don't see how this results in a net reduction in risk to Bitco= in, 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 go fi= rst :).

Indeed, more flexible introspection provides for a difference in risk to th= e system (though its
worth noting we cannot both argue that there is no "demonstrated utili= ty" *and* that the utility of
a change is so substantially higher that it adds material risk to the syste= m in the form of MEVil
from its use-cases). However, given the uses of the Bitcoin chain today, it= seems entirely possible
(assuming sufficient adoption) that we end up with a substantial MEVil risk= with or without any
functionality expansion. This mandates a response from the Bitcoin developm= ent community in either
case, and I'm confident that response can happen faster than any reason= able soft fork timeline.

While its possible that existing CSV-based MEVil risk never grows beyond it= s current anemic state
(due to preferences for stronger trust models from their users), and that t= here's a particularly
clever design using expanded introspection that improves the trust model su= ch that suddenly
CSV-based protocol use explodes, ISTM given the risk and the need to mitiga= te it on its own, taking
decisions that are sub-optimal for Bitcoin's consensus on this basis is= n't accomplishing much and
has real costs.

Matt

--
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 bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/8= a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.com.

--
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/bitcoindev/CAGL6%2BmHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr%3DQVvXUg%= 40mail.gmail.com.
--00000000000051c10b06386a5e84--