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

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

['Antoine Poinsot' via Bitcoin Development Mailing List]

There is excitement in the technical community about a CTV+CSFS soft fork as specified in BIP119 and BIP348. We think
this combination of opcodes offers desirable capabilities to scale Bitcoin payments and is worth considering to soft
fork into Bitcoin. There has been several objections to this proposal, which we can group into three categories:
exploration of alternatives, demonstration of usage, and design of the operations to achieve these capabilities.

In an attempt to help the proposal move forward we would like to kick-off a discussion about the first category:
alternatives. We will start by making the case that the capabilities "commit to the transaction spending this output"
and "verify a BIP340 signature for an arbitrary message" are a good stopping point for a Bitcoin soft fork. We invite
anyone to share objections in reply to this thread so they can be addressed or inform a better course of action.

Let's keep the discussion focused on the capabilities, not the specific way of designing operations to achieve them. For
the sake of this discussion `OP_CTV` would be equivalent to `OP_TEMPLATEHASH` (push the template hash on the stack) as
the capability "commit to the transaction to spend an output". `OP_TXHASH` would be separate, as a "programmable
transaction introspection" capability.

The ability to commit to the exact transaction spending an output is useful to reduce interactivity in second-layer
protocols. For instance it can reduce roundtrips[^0] in the implementation of LN-Symmetry, or make receiving an Ark
"vtxo" non-interactive[^1]. Additionally, it enables significant optimizations[^2] in the implementation of Discreet Log
Contracts.

The ability to verify a signature for an arbitrary message in Tapscript enables oracle attestations and a form of
delegation. Oracle attestation for instance significantly reduce[^3] the onchain footprint of BitVM. Reducing an
application's onchain footprint benefits all Bitcoin users by easing block space competition, and it's especially
important for applications that generate very large transactions, which could otherwise increase pressure toward mining
centralization[^4].

Together, these two features enable a third capability: rebindable transaction signatures. Rebindable signatures make
possible a new type of payment channels, LN-Symmetry ("Eltoo"), whose simplicity makes practical advanced constructs
such as multiparty channels. They also enable further interactivity reduction in second layer protocols, as illustrated
by the Ark variant "Erk"[^5] or the dramatic simplification[^6] they bring to upgrading today's Lightning (i.e. without
switching to LN-Symmetry) from HTLCs to PTLCs.

These capabilities are simple and modular. They are well understood and present a low risk of enabling unwanted
behaviour. They do not increase the cost of validation, have low implementation complexity and are unlikely to become
redundant, even if more powerful capabilities are added in the future. These capabilities improve existing
tried-and-proven protocols used daily by Bitcoin users, like the Lightning Network. They also make new ones possible
either at all or through realistic interactivity requirements. The new enabled protocols take a similar approach to
existing Bitcoin scaling solutions, only with different tradeoffs not previously available. We can therefore reasonably
expect they won't introduce new systemic incentives, while broadening the range of supported use cases.

The first alternative approach to address is doing nothing. Doing nothing is *the* valid schelling point in a system
where consensus changes must be agreed on by a supermajority of the economic activity, and ideally by all stakeholders
in the system. Unless there is a critical vulnerability being fixed, the onus is on the proposer to overcome the various
valid objections. Further, a number of smart contracts have been deployed on Bitcoin and more are incoming, with or
without consensus changes. No softforks on the horizon are known to generate asymptotic scaling, and what's more,
on-chain demand has not been high except on infrequent intervals.

As said prior, we believe the capabilities of CTV+CSFS reach an appropriate bar for consideration for activation. While
it will not achieve asymptotic scaling, it will enable significant reduction in complexity in already-deployed systems,
and is worth deploying for their specific benefits. Regardless, it's important to emphasize it again: the onus is on the
proposer to overcome objections.

Other alternative approaches to scaling Bitcoin payments have been proposed such as with validation rollups[^7], enabled
by the ability to verify a zero-knowledge proof directly in Bitcoin Script. These rollups are trustless and could
effectuate a modest factor throughput increase under realistic assumptions and transaction load.  This approach, used on
altcoins but new to Bitcoin, has yet to reach consensus among the technical community and Bitcoin users more broadly.
Relative immaturity of many of the employed crypto-systems make designing a ZKP-specific primitive a difficult task.
Further, trustless composibility with interactive protocols like LN to achieve further scaling are speculative at the
time. Nonetheless, the capabilities that enable this alternative approach to scaling are neither exclusionary nor
redundant with those proposed here.

It makes sense to focus first on capabilities improving the tried-and-proven approach, as the newer approach
(and the capabilities enabling it) may come with different tradeoffs.

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], which
warrants a compelling demonstration that arbitrary transaction introspection does enable important use cases not
achievable with more minimal capabilities.

Finally, a more radical alternative is to focus efforts to make Bitcoin smart contracts more capable with a sane
re-design of its scripting language. Similarly to the alternative of more powerful Bitcoin Script capabilities, it
remains to be shown that more expressivity is both safe and desirable. Furthermore, it is unclear that such an
undertaking would be achievable with the (very) limited engineering resources currently allocated to extending Bitcoin
scripting capabilities.

In conclusion, we believe the bundle of capabilities "commitment to the transaction spending an output" and "BIP340
signature verification of arbitrary message" to be the best direction for Bitcoin to take. These are well-understood,
simple capabilities, substantially improving an existing well-understood approach to scaling Bitcoin payments. This
direction does not preclude research into more advanced capabilities, though questions remain about their overall
desirability.

Antoine Poinsot & Greg Sanders

[^0]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
[^1]: https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528
[^2]: https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com
[^3]: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
[^4]: https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8
[^5]: https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
[^6]: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/18
[^7]: https://github.com/john-light/validity-rollups
[^8]: https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev

-- 
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/F5vsDVNGXP_hmCvp4kFnptFLBCXOoRxWk9d05kSInq_kXj0ePqVAJGADkBFJxYIGkjk8Pw1gzBonTivH6WUUb4f6mwNCmJIwdXBMrjjQ0lI%3D%40protonmail.com.

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

[Harsha Goli]

[-- Attachment #1.1: Type: text/plain, Size: 9719 bytes --]



​We will start by making the case that the capabilities "commit to the 
transaction spending this output"
and "verify a BIP340 signature for an arbitrary message" are a good 
stopping point for a Bitcoin soft fork. We invite
anyone to share objections in reply to this thread so they can be addressed 
or inform a better course of action.


We can consider narrower commitment combinations once we establish that 
broad commitments are a success for bitcoin. I reject the assumption some 
have that narrower commitment combinations might have more market demand 
than broader combinations, and that such assumptions might be an adequate 
reason to move forward with alternative proposals.

Thanks,
Harsha, sometimes known as arshbot

On Monday, June 23, 2025 at 9:26:20 AM UTC-4 Antoine Poinsot wrote:

> There is excitement in the technical community about a CTV+CSFS soft fork 
> as specified in BIP119 and BIP348. We think
> this combination of opcodes offers desirable capabilities to scale Bitcoin 
> payments and is worth considering to soft
> fork into Bitcoin. There has been several objections to this proposal, 
> which we can group into three categories:
> exploration of alternatives, demonstration of usage, and design of the 
> operations to achieve these capabilities.
>
> In an attempt to help the proposal move forward we would like to kick-off 
> a discussion about the first category:
> alternatives. We will start by making the case that the capabilities 
> "commit to the transaction spending this output"
> and "verify a BIP340 signature for an arbitrary message" are a good 
> stopping point for a Bitcoin soft fork. We invite
> anyone to share objections in reply to this thread so they can be 
> addressed or inform a better course of action.
>
> Let's keep the discussion focused on the capabilities, not the specific 
> way of designing operations to achieve them. For
> the sake of this discussion `OP_CTV` would be equivalent to 
> `OP_TEMPLATEHASH` (push the template hash on the stack) as
> the capability "commit to the transaction to spend an output". `OP_TXHASH` 
> would be separate, as a "programmable
> transaction introspection" capability.
>
> The ability to commit to the exact transaction spending an output is 
> useful to reduce interactivity in second-layer
> protocols. For instance it can reduce roundtrips[^0] in the implementation 
> of LN-Symmetry, or make receiving an Ark
> "vtxo" non-interactive[^1]. Additionally, it enables significant 
> optimizations[^2] in the implementation of Discreet Log
> Contracts.
>
> The ability to verify a signature for an arbitrary message in Tapscript 
> enables oracle attestations and a form of
> delegation. Oracle attestation for instance significantly reduce[^3] the 
> onchain footprint of BitVM. Reducing an
> application's onchain footprint benefits all Bitcoin users by easing block 
> space competition, and it's especially
> important for applications that generate very large transactions, which 
> could otherwise increase pressure toward mining
> centralization[^4].
>
> Together, these two features enable a third capability: rebindable 
> transaction signatures. Rebindable signatures make
> possible a new type of payment channels, LN-Symmetry ("Eltoo"), whose 
> simplicity makes practical advanced constructs
> such as multiparty channels. They also enable further interactivity 
> reduction in second layer protocols, as illustrated
> by the Ark variant "Erk"[^5] or the dramatic simplification[^6] they bring 
> to upgrading today's Lightning (i.e. without
> switching to LN-Symmetry) from HTLCs to PTLCs.
>
> These capabilities are simple and modular. They are well understood and 
> present a low risk of enabling unwanted
> behaviour. They do not increase the cost of validation, have low 
> implementation complexity and are unlikely to become
> redundant, even if more powerful capabilities are added in the future. 
> These capabilities improve existing
> tried-and-proven protocols used daily by Bitcoin users, like the Lightning 
> Network. They also make new ones possible
> either at all or through realistic interactivity requirements. The new 
> enabled protocols take a similar approach to
> existing Bitcoin scaling solutions, only with different tradeoffs not 
> previously available. We can therefore reasonably
> expect they won't introduce new systemic incentives, while broadening the 
> range of supported use cases.
>
> The first alternative approach to address is doing nothing. Doing nothing 
> is *the* valid schelling point in a system
> where consensus changes must be agreed on by a supermajority of the 
> economic activity, and ideally by all stakeholders
> in the system. Unless there is a critical vulnerability being fixed, the 
> onus is on the proposer to overcome the various
> valid objections. Further, a number of smart contracts have been deployed 
> on Bitcoin and more are incoming, with or
> without consensus changes. No softforks on the horizon are known to 
> generate asymptotic scaling, and what's more,
> on-chain demand has not been high except on infrequent intervals.
>
> As said prior, we believe the capabilities of CTV+CSFS reach an 
> appropriate bar for consideration for activation. While
> it will not achieve asymptotic scaling, it will enable significant 
> reduction in complexity in already-deployed systems,
> and is worth deploying for their specific benefits. Regardless, it's 
> important to emphasize it again: the onus is on the
> proposer to overcome objections.
>
> Other alternative approaches to scaling Bitcoin payments have been 
> proposed such as with validation rollups[^7], enabled
> by the ability to verify a zero-knowledge proof directly in Bitcoin 
> Script. These rollups are trustless and could
> effectuate a modest factor throughput increase under realistic assumptions 
> and transaction load. This approach, used on
> altcoins but new to Bitcoin, has yet to reach consensus among the 
> technical community and Bitcoin users more broadly.
> Relative immaturity of many of the employed crypto-systems make designing 
> a ZKP-specific primitive a difficult task.
> Further, trustless composibility with interactive protocols like LN to 
> achieve further scaling are speculative at the
> time. Nonetheless, the capabilities that enable this alternative approach 
> to scaling are neither exclusionary nor
> redundant with those proposed here.
>
> It makes sense to focus first on capabilities improving the 
> tried-and-proven approach, as the newer approach
> (and the capabilities enabling it) may come with different tradeoffs.
>
> 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], which
> warrants a compelling demonstration that arbitrary transaction 
> introspection does enable important use cases not
> achievable with more minimal capabilities.
>
> Finally, a more radical alternative is to focus efforts to make Bitcoin 
> smart contracts more capable with a sane
> re-design of its scripting language. Similarly to the alternative of more 
> powerful Bitcoin Script capabilities, it
> remains to be shown that more expressivity is both safe and desirable. 
> Furthermore, it is unclear that such an
> undertaking would be achievable with the (very) limited engineering 
> resources currently allocated to extending Bitcoin
> scripting capabilities.
>
> In conclusion, we believe the bundle of capabilities "commitment to the 
> transaction spending an output" and "BIP340
> signature verification of arbitrary message" to be the best direction for 
> Bitcoin to take. These are well-understood,
> simple capabilities, substantially improving an existing well-understood 
> approach to scaling Bitcoin payments. This
> direction does not preclude research into more advanced capabilities, 
> though questions remain about their overall
> desirability.
>
> Antoine Poinsot & Greg Sanders
>
> [^0]: https://delvingbitcoin.org/t/ln-symmetry-project-recap/359
> [^1]: https://delvingbitcoin.org/t/the-ark-case-for-ctv/1528
> [^2]: 
> https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83...@mail.gmail.com 
> <https://gnusha.org/pi/bitcoindev/CAH5Bsr2vxL3FWXnJTszMQj83jTVdRvvuVpimEfY7JpFCyP1AZA@mail.gmail.com>
> [^3]: 
> https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591
> [^4]: 
> https://delvingbitcoin.org/t/non-confiscatory-transaction-weight-limit/1732/8
> [^5]: 
> https://delvingbitcoin.org/t/evolving-the-ark-protocol-using-ctv-and-csfs/1602
> [^6]: 
> https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/18
> [^7]: https://github.com/john-light/validity-rollups
> [^8]: https://bluematt.bitcoin.ninja/2024/04/16/stop-calling-it-mev
>

-- 
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/b98ba037-a76b-4fac-88c2-b9f9fbca87cbn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15511 bytes --]

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

[Matt Corallo]

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.