ctvcsf.md

CTV + CSFS Letter

Sorry, this got very long at least for my standards.

I'd like to start off by saying I believe that Bitcoin is in good technical hands regardless of how this shakes out. Good things take time and we've learned a lot; let's continue doing so.

Before I dive into what I think needs to be answered for this proposal to move forward, I'd like to respond to language in the letter to make sure we're on a common understanding of the asks being given here.

We respectfully ask Bitcoin Core contributors to prioritize the review and integration of CTV (PR #31989 or similar) and CSFS (PR #32247 or similar) within the next six months. We believe this timeline allows for rigorous final review and activation planning.

This is the meat of the post. This seemingly dictates inclusion for activation as a fait accompli. Is this intended? The most generous interpretation is that it's an ask for rigorous review, with the explicit intention that if there is broad technical consensus to activate, that broader communication to non-technical world + activation discussions occur. I'd like to think this this is especially a call for those who have not spoken up, including those who have done the homework yet conceptually disagree?

What efforts will be done by proponents to gather that feedback and make it public?

Each co-signer should consider what feedback could be received that would demonstrate lack of technical consensus. I think it's plain that there isn't at least 100% excitement in the technical community for the proposal. How much of this lack of enthusiasm stems from inattention vs outright opposition?

six months

What happens if this time runs out? Is this just an ask to have people take a look within a "few months" and continue/cease work after depending on results?

Feedback on Effort

I grouped my specific feedback as larger conceptual concerns, specification concerns, and deployment concerns. They don't need to be answered inline here at this specific venue, but this is a synthesis of my hesitation about the current effort, hopefully with some concrete actions that can be taken.

For sake of discussion: "CTV" means "next tx" commitment capability, not BIP119 per se "TXHASH" means CTV with many knobs for app devs to choose what to commit to "CSFS" means what's on the tin (less wiggle room here for changes)

Larger conceptual concern:

Given all the things we've learned over the lifetime of BIP119 and the prior iterations, we need to consider "why here and not there". What's a good stopping point for adding functionality to Bitcoin Script, when we have essentially infinitely combinations possible and different strategies?

My mental model of where we should stop in terms of capabilities comes in the form of:

"Why here and not there"?

• Why not just CTV?
• Why CTV + CSFS?
• Why not TXHASH + CSFS?
• Why not bucket of opcodes? "swiss army knife" approach

"MEVil" is one type of objection to generalized Bitcoin script introspection. CTV+CSFS is not known to appreciably increase MEVil potential. For the sake of argument, let's assume this dimension doesn't matter, due to a mixture in technical/market realities, or ColliderVM is deployed, or the deployment of based rollups on Bitcoin without any softforks. In some of those cases we should deploy anti-MEV technology regardless, but let's set that aside.

Everyone should consider these on their own but stating my own view to start the conversation:

Why not just CTV? I think there is general agreement that CTV alone was insufficiently exciting to enough of the technical community to be deployed on its own. There are some cool usages without, but the complementary nature of a straight forward CSFS capability is too much to overlook, increasing the flagship use-cases substantially.

Why not TXHASH+CSFS? If the cost is a year of concentrated development to do something better, we should just do it. We could easily as a community decide that TXHASH (with CTV capabilities being baked in as a trivial default mode thereof) is the thing we actually want and easily get the design finalized within that timeframe. With TXHASH+CSFS we can let app developers decide what they find important, versus the opinionated CTV default, whatever that is.

Note that I'm not totally convinced by this argument in either direction. Once we have TXHASH, there's really no reason to not have CAT (that's very small too!), maybe big num math, perhaps direct introspection. Maybe bllish, simplicity, or GSR? The community would have to agree on a stopping point, and that seems like it could be difficult to do in a short-in-year-terms timeline.

Why not bucket of opcodes? Same arguments apply on slippery slope but moreso. There's no clear stopping point, turning it into a giant research and engineering project, even if it's a good idea to start working on it now.

Specification concerns:

1. Why not commit to annex? I had considered future annex relay as problematic for rolling out BIP119 due to its lack of commitment to the annex field. Committing or not are both reasonable depending on usage. With bitcoin/bitcoin#32453 it at least won't impede annex relay efforts unduly, so maybe this can be punted and CTV sticks closer to it's minimalistic txid-stable design goal. Bringing this up because few people seem to have considered this historically.

2. Legacy script support is not technically necessary for the capabilities we desire. It considerably increases review surface for no known capability gain and no known savings for protocols. Legacy scripting should not be modified lightly, and if there's no strong motivation, it should be abandoned in favor of solutions that don't touch it. See more discussion in that direction here: https://delvingbitcoin.org/t/ctv-csfs-can-we-reach-consensus-on-a-first-step-towards-covenants/1509/75

3. BIP119 committing to other prevouts very indirectly is a surprising anti-feature: https://delvingbitcoin.org/t/how-ctv-csfs-improves-bitvm-bridges/1591

This feature is proported to make specific BitVM constructions trustless in one respect, instead of the 1-of-n trust assumption held. This is extremely surprising, and as can be seen in the thread extremely brittle and ugly. BIP119 activated alone seemingly incentivizes very non-standard scriptSigs on legacy scripting, rather than directly offering the functionality desired. This is a bad sign which either means we should ban it outright by f.e. requiring scriptSigs to be blank, or take another long hard look at TXHASH to give app devs tools they actually want such as TXHASH.

What other surprising capabilities lurk in BIP119 that would incentivize deranged usage like this? Maybe nothing? Perhaps it's hubris to predict it and we should just do TXHASH? Maybe this hack is not a big deal and I shouldn't be physically repulsed by having to carve out a standardness rule for it?

Concrete Deployment concerns:

1. Summarize technical community objections and adequately address them in a single discoverable location. I do not believe this has been done adequately up until now.

2. Specification feedback fully addressed and discoverable in a single location.

3. Flagship PoCs: At a minimum I would hope for some level of LN-Symmetry PoC, and or perhaps proving out hArk(or Erk), and make sure they are re-validated on whatever the final spec would end up being. If we want to draw some lessons on taproot activation it should be that validation should be done throughout the lifetime of the proposal.

I'm hopeful on this front but 6 months to get things like this done in addition to everything else seems very short.

4. Second consensus implementation: It's important to validate the BIPs and gather more design feedback before finality of spec. Again, let's learn some lessons from past mistakes. Can btcd get a branch up and running that matches the specs and bitcoind?