From: Chris Stewart <stewart.chris1234@gmail•com>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Antoine Poinsot <darosior@protonmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS
Date: Wed, 25 Jun 2025 14:22:29 -0500 [thread overview]
Message-ID: <CAGL6+mHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr=QVvXUg@mail.gmail.com> (raw)
In-Reply-To: <8a9a2299-ab4b-45a4-8b9d-95798e6bb62a@mattcorallo.com>
[-- Attachment #1: Type: text/plain, Size: 7381 bytes --]
>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—OP_VAULT
and OP_CHECKCONTRACTVERIFY—using OP_{IN,OUT}_AMOUNT [2][3]. While the
current proposal has some clear limitations (namely, what I refer to as
“amount replay attacks”), 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] – https://groups.google.com/g/bitcoindev/c/j1zEky-3QEE
[1] – https://delvingbitcoin.org/t/op-inout-amount/549/3?u=chris_stewart_5
[2] – https://delvingbitcoin.org/t/op-inout-amount/549/4?u=chris_stewart_5
[3] – https://delvingbitcoin.org/t/op-inout-amount/549/5?u=chris_stewart_5
[4] –
https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527/6?u=chris_stewart_5
On Tue, Jun 24, 2025 at 11:00 AM 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 List
> wrote:
> > Yet another alternative is a set of more powerful capabilities, enabling
> 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 of
> 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 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
> 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 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
> 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-95798e6bb62a%40mattcorallo.com
> .
>
--
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/CAGL6%2BmHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr%3DQVvXUg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9151 bytes --]
prev parent reply other threads:[~2025-06-25 20:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 13:14 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-24 14:29 ` [bitcoindev] " Harsha Goli
2025-06-24 15:54 ` [bitcoindev] " Matt Corallo
2025-06-25 16:50 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-06-25 20:34 ` Ethan Heilman
2025-06-25 19:22 ` Chris Stewart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGL6+mHRv352YdG-mRsrjYEFUr-AUBizzY3wore6zWr=QVvXUg@mail.gmail.com' \
--to=stewart.chris1234@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=darosior@protonmail$(echo .)com \
--cc=lf-lists@mattcorallo$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox