path: root/e8/3bff155791b607c8f5a7d0abcc5472e31ea052

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 <bitcoindev+bncBDML5DFJWQEBBKNV6HBAMGQEXOPSYNA@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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: <F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI=@protonmail.com>
 <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
In-Reply-To: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
From: Chris Stewart <stewart.chris1234@gmail.com>
Date: Wed, 25 Jun 2025 14:22:29 -0500
X-Gm-Features: Ac12FXzJGCpPwTAO7qAnwNhECAzcqWTFUQaiL2jyGJfLv_eEMO_7IQEneRQxVTI
Message-ID: <CAGL6+mHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr=QVvXUg@mail.gmail.com>
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for
 the capabilities enabled by CTV+CSFS
To: Matt Corallo <lf-lists@mattcorallo.com>
Cc: Antoine Poinsot <darosior@protonmail.com>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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 (/)

--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 <lf-lists@mattcorallo=
.com>
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

<div dir=3D"ltr">&gt;For example, a trivial construction would be something=
 which requires that transactions spending an <br>
output have an output which claims at least Amount - Rate, which requires b=
oth more full-featured <br><div>
introspection as well as a bit of math.</div><div><br></div><p></p>
<p>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 <code>O=
P_{IN,OUT}_AMOUNT</code> [1]. I&#39;ve prototyped two vault-related opcodes=
=E2=80=94<code>OP_VAULT</code> and <code>OP_CHECKCONTRACTVERIFY</code>=E2=
=80=94using <code>OP_{IN,OUT}_AMOUNT</code> [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.</p>
<p>That said, I don&#39;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.</p>
<p>[0] =E2=80=93 <a rel=3D"noopener" class=3D"gmail-" href=3D"https://group=
s.google.com/g/bitcoindev/c/j1zEky-3QEE">https://groups.google.com/g/bitcoi=
ndev/c/j1zEky-3QEE</a><br>
[1] =E2=80=93 <a rel=3D"noopener" class=3D"gmail-" href=3D"https://delvingb=
itcoin.org/t/op-inout-amount/549/3?u=3Dchris_stewart_5">https://delvingbitc=
oin.org/t/op-inout-amount/549/3?u=3Dchris_stewart_5</a><br>
[2] =E2=80=93 <a rel=3D"noopener" class=3D"gmail-" href=3D"https://delvingb=
itcoin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5">https://delvingbitc=
oin.org/t/op-inout-amount/549/4?u=3Dchris_stewart_5</a><br>
[3] =E2=80=93 <a rel=3D"noopener" class=3D"gmail-" href=3D"https://delvingb=
itcoin.org/t/op-inout-amount/549/5?u=3Dchris_stewart_5">https://delvingbitc=
oin.org/t/op-inout-amount/549/5?u=3Dchris_stewart_5</a><br>
[4] =E2=80=93 <a rel=3D"noopener" class=3D"gmail-" href=3D"https://delvingb=
itcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527/6?u=3Dchri=
s_stewart_5">https://delvingbitcoin.org/t/op-checkcontractverify-and-its-am=
ount-semantic/1527/6?u=3Dchris_stewart_5</a></p><div><br></div><div><br></d=
iv><div>=C2=A0<br></div><div><br></div></div><br><div class=3D"gmail_quote =
gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 24=
, 2025 at 11:00=E2=80=AFAM Matt Corallo &lt;<a href=3D"mailto:lf-lists@matt=
corallo.com">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">Thanks, responding to one specific poi=
nt:<br>
<br>
On 6/23/25 9:14 AM, &#39;Antoine Poinsot&#39; via Bitcoin Development Maili=
ng List wrote:<br>
&gt; Yet another alternative is a set of more powerful capabilities, enabli=
ng the use cases that &quot;commit to next transaction&quot;<br>
&gt; and &quot;verify a BIP340 signature for an arbitrary message&quot; ena=
ble and more. For instance replacing &quot;commit to the exact<br>
&gt; transaction which must spend this output&quot; with &quot;programmable=
 introspection on the spending transaction&#39;s fields&quot; has<br>
&gt; been considered. However this approach increases implementation comple=
xity and broadens the risk surface[^8]<br>
<br>
Responded to below [1]<br>
<br>
&gt; which<br>
&gt; warrants a compelling demonstration that arbitrary transaction introsp=
ection does enable important use cases not<br>
&gt; achievable with more minimal capabilities.<br>
<br>
I&#39;m somewhat skeptical that showing this isn&#39;t rather simple, thoug=
h I admit I&#39;ve spent less time <br>
thinking about these concepts. ISTM even something as simple as a rate-limi=
t requires more <br>
full-featured introspection than only &quot;commit to the exact next transa=
ction&quot; can provide. For <br>
example, a trivial construction would be something which requires that tran=
sactions spending an <br>
output have an output which claims at least Amount - Rate, which requires b=
oth more full-featured <br>
introspection as well as a bit of math. Given one of the loudest groups adv=
ocating for the <br>
additional features of CTV+CSFS are enterprise or large-value personal cust=
ody providers, it seems <br>
somewhat of a loss to not work our way towards really basic features for th=
is use-case.<br>
<br>
More generally, more full-featured introspection like TXHASH provides a lot=
 of flexibility in the <br>
constructs people can build. For example, allowing BYO fees in the form of =
an additional input + <br>
output in a transaction, rather than fixing an anchor output in the fixed &=
quot;next transaction&quot; <br>
commitment to allow for fees (and then requiring the same additional input =
+ output later). There&#39;s <br>
also open questions as to the incentive-compatibility of anchors in a world=
 with expensive block <br>
space, as OOB fees become much cheaper.<br>
<br>
Indeed, ISTM many use-cases for a construction like TXHASH become a lot mor=
e substantial with Math <br>
(though, again, I spend less time thinking about the use-cases of these thi=
ngs than most, so I&#39;m <br>
sure others have more examples), I&#39;m quite skeptical that *just* lookin=
g at an individual fork on <br>
its own is the right benchmark. Sure, functionality in proposed changes to =
Bitcoin&#39;s consensus need <br>
to be well-justified, but they don&#39;t need to be well-justified *purely =
on their own*. We add things <br>
like OP_SUCCESS opcodes in soft forks specifically to expand the set of thi=
ngs we can do later, not <br>
specifically in this fork.<br>
<br>
If we assume that we end up wanting things like velocity limits (which I im=
agine we would?) then it <br>
seems to me we should do a logical fork that adds features today, but which=
 will allow us to make <br>
minimal extensions in the future to further expand its use-cases later. Tak=
ing a more myopic view of <br>
the present and ignoring the future results in us doing one thing today, th=
en effectively replacing <br>
it later by adding more flexibility in a new opcode later, subsuming the fe=
atures of what we do <br>
today. I don&#39;t see how this results in a net reduction in risk to Bitco=
in, rather just means more <br>
total work and more cruft in Bitcoin&#39;s consensus.<br>
<br>
[1]<br>
<br>
Responding to the MEVil question OOO because I think the above should go fi=
rst :).<br>
<br>
Indeed, more flexible introspection provides for a difference in risk to th=
e system (though its <br>
worth noting we cannot both argue that there is no &quot;demonstrated utili=
ty&quot; *and* that the utility of <br>
a change is so substantially higher that it adds material risk to the syste=
m in the form of MEVil <br>
from its use-cases). However, given the uses of the Bitcoin chain today, it=
 seems entirely possible <br>
(assuming sufficient adoption) that we end up with a substantial MEVil risk=
 with or without any <br>
functionality expansion. This mandates a response from the Bitcoin developm=
ent community in either <br>
case, and I&#39;m confident that response can happen faster than any reason=
able soft fork timeline.<br>
<br>
While its possible that existing CSV-based MEVil risk never grows beyond it=
s current anemic state <br>
(due to preferences for stronger trust models from their users), and that t=
here&#39;s a particularly <br>
clever design using expanded introspection that improves the trust model su=
ch that suddenly <br>
CSV-based protocol use explodes, ISTM given the risk and the need to mitiga=
te it on its own, taking <br>
decisions that are sub-optimal for Bitcoin&#39;s consensus on this basis is=
n&#39;t accomplishing much and <br>
has real costs.<br>
<br>
Matt<br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.com" rel=3D"n=
oreferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/8=
a9a2299-ab4b-45a4-8b9d-95798e6bb62a%40mattcorallo.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/CAGL6%2BmHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr%3DQVvXUg%40mail.g=
mail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/=
d/msgid/bitcoindev/CAGL6%2BmHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr%3DQVvXUg%=
40mail.gmail.com</a>.<br />

--00000000000051c10b06386a5e84--