CTV+CSFS: Can we reach consensus on a first step towards covenants?

stevenroose · July 14, 2025, 1:08pm

Since I originally started this thread, I suppose it’d make sense to post an update.

Over the course of the months since this conversation started, I feel like quite some progress has been made. Both in convincing people of the benefits of a consensus upgrade like this (cfr the number of signers of the recent open letter^[1]), and in convincing developers to start doing the work required to get there.

While the discussion on a right stopping point for the next softfork is not entirely settled^[2]^[3], I feel that more people are coming to agreement that we can leave other interesting proposals like TXHASH, CHECKCONTRACTVERIFY or GSR for consideration of future upgrades.

The two core capabilities we are enabling with this softfork are “next tx commitment” and “re-bindable signatures”. The combination of CTV and CSFS supports both, but it is way more efficient for the “next tx commitment” use-case, while being quite inefficient for the “re-bindable signature” use-case.

Therefore, during the OP_NEXT conference recently, the idea came up for a slightly tweaked iteration of this bundle that is significantly more optimized for the “re-bindable signature” use-case while only adding a single byte for the “next tx commitment” one: replacing OP_CTV with a new opcode OP_TEMPLATEHASH to directly push the template hash onto the stack, and adding existing proposed opcode OP_INTERNALKEY^[4] to give access to the internal pubkey from the control block.

There have been some opposition to activating new features in legacy script contexts, so I see it as beneficial that these opcodes are only possible to be added to the tapscript context (as they need to use OP_SUCCESS upgrade hooks to push to the stack). Additionally, since the new opcode TEMPLATEHASH will only work under taproot, we took the opportunity to revisit a few of the implementation choices that were made for CTV, primarily regarding the commitment to scriptSigs and the taproot annex.

The result has been posted to the mailing list^[5] and the BIP text for the newly proposed opcode^[6] and bundle^[7] are available for review. Ultimately, this bundle is a technical iteration of the capabilities that are intended with the start of this discussion, based on the feedback it received.

Hoping for further feedback.