Re: [bitcoindev] What's a good stopping point? Making the case for the capabilities enabled by CTV+CSFS

[Matt Corallo <lf-lists@mattcorallo.com>]

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.