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.