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

[securitybrahh]

Also the core-devs has put a “regtest” label on the PR, can I see thr opcodes running on something like mempool.space?

[moonsettler]

regtest means you can only use it on your own computer on a private blockchain.

[securitybrahh]

lol, atleast let me run on some test net that we all can view through mempool space UI.

[Chris_Stewart_5]

Has anyone actually published a branch that has both CTV+CSFS? From skimming through this topic I don’t see one. It would be nice to have one on top of the major latest release of bitcoin core for integration testing the 2 opcodes together.

[AntoineP]

Good point. Greg has a PR to introduce CSFS to inquisition. This is in effect a branch with both CTV+CSFS. It’s worth noting nobody bothered reviewing it in the past 3 months.

[Chris_Stewart_5]

I think the @RobinLinus and @ajtowns interactions on the BitVM & CTV+CSFS thread illustrates the subtle foot guns that come with OP_CTV as an OP_NOP and OP_SUCCESS. I don’t think I would have caught this subtle vulnerability that comes with supporting legacy Script.

This interaction occurred after the posts on this thread arguing about OP_NOP support, so I feel like its worthwhile to highlight it here.

@ajtowns

where <H> locks in where the output goes to, and input 2’s scriptSig. But because H is only committing to the second input’s scriptSig, then it’s easy to construct another utxo that can be used instead, eg one with the (non-standard) scriptPubKey OP_2DROP OP_TRUE:

utxo C:  500 sats, scriptPubKey: OP_2DROP OP_TRUE

input 1: utxo A, no witness/scriptSig
input 2: utxo C, scriptSig = "<S;NONE|ANYONECANPAY>" "<P> CHECKSIG"
output: whatever

That allows utxo A to be spent via the CTV path independently of whether utxo B has already been spent/burnt, which, as far as I can see, breaks the protocol you’re trying to enforce.

(I’m assuming in a real example utxo B’s spend condition is more complicated than <P> CHECKSIG, as otherwise the availability of a NONE|ANYONECANPAY signature means it can be spent immediately, so a griefer could fairly easily prevent the happy path from ever being taken)

It seems like this could be worked around since OP_CTV does commit to the scriptSig according to instagibbs

@instagibbs

The scriptSig could include the CHECKSIG opcode directly, contra standardness rules.

In the original idea, a p2sh redeemscript is just pushes, so the spk could just be blank and it would pass, since cleanstack isn’t consensus anyways.

However this seems rather unpleasant.

I think Jeremy Rubin is conceding the point that at least for p2sh OP_CTV is broken?

@JeremyRubin

This is an interesting point; without some sort of “stack sentinel” that guarantees a specific script type, using CTV as a gadget for any P2SH type seems broken, as you can replace it with a legacy script that does something else. This is “confusing” because you cannot replace it with a p2sh script that does something else. I can make an effort to better document this issue…

Which leaves us with only spending “raw”/“bare” outputs to be able to commit to meaningful data in the scriptSig with CTV.

Is the juice really worth the squeeze for committing to scriptSig data?

[instagibbs]

I’ve come to see this capability of CTV (committing to other prevouts in very round-about way) as an anti-feature, an unexpected capability that is so sharp-edged that if it’s something we want we should explicitly design for it instead to discourage such bizarre usage.

Alternatively we could remove the capability by making non-empty scriptSigs fail the script execution. This of course only makes sense in a post-segwit world only which I’ve already advocated above as a taproot-only push opcode.

[josh]

This of course only makes sense in a post-segwit world only which I’ve already advocated above as a taproot-only push opcode.

@instagibbs If a taproot-only push opcode is the way to go, would it make sense to introduce a new witness version for bare tapscript?

That way, you can still make bare CTV commitments (leaving other types of bare scripts non-standard).

[instagibbs]

@josh

If a taproot-only push opcode is the way to go, would it make sense to introduce a new witness version for bare tapscript?

I did here CTV+CSFS: Can we reach consensus on a first step towards covenants? - #58 by instagibbs

I find it nice to consider both separately, even if they both end up being adopted.

[jamesob]

@instagibbs

FYI: after discussion a while back, I hacked together very small loc changes that:

1. Makes bare CTV a first class citizen
2. Converts CTV into a push-onto-stack taproot-only opcode

This is a cool patch, thanks for doing it.

I still prefer the existing CTV impl. for a few reasons:

1. Bare legacy CTV is upgradeable (i.e. >32byte CTV hashes). Though you could make your patch upgradeable by returning true for any witV2 with a program size of over 32 bytes.
2. In wit v0 CTV, you can have scripts that are more complicated than just a single CTV invocation, but avoid the Taproot control block overhead of 33vB (e.g. in simple-ctv-vault). 33vB may well be worth fretting over in the future.
3. This is probably fringe, but one “nice” thing about bare CTV legacy scripts is that because they don’t have an associated address, accidental address reuse by a human is impossible (i.e. erroneous send to an already-setup vault). Of course your witV2 scheme doesn’t define an address format, but it would be easy to. Edit: witV2 by default uses bech32m addresses.

[jamesob]

@instagibbs Maybe it goes without saying, but I think it’d be totally reasonable to layer on a tapscript-only OP_CHECKTEMPLATE to the existing proposal. If it saves 32 vbytes 8WU for the Lightning case and likely others, I think that’s great.

[instagibbs]

@jamesob

Bare legacy CTV is upgradeable

No other output lengths would be defined for the “P2CTV” case, there’s no difference in this respect.

@jamesob

33vB may well be worth fretting over in the future.

33WU, or <9vB. I don’t find byte pinching over hypotheticals very persuasive but other’s mileage may vary.

@jamesob

This is probably fringe, but one “nice” thing about bare CTV legacy scripts is that because they don’t have an associated address

I know we differ on this but I expect very little bare CTV usage vs some form of script. We can’t protect people in script hash land; I think that ship sailed a long time ago.

---

The proposal is materially different than before with CSFS added. Let’s avoid sunk cost thinking.

[jamesob]

Another more practical point in favor of making CTV available in witness v0 is that many (or most?) HSMs do not yet natively support Schnorr signatures - and for existing installations, may never. There is likely overlap between companies who currently use such HSMs (making witness v0 the default) and companies who would like to make use of CTV vaults.

[instagibbs]

That’s a reasonable point, under the restricted set of functionality that encompasses a hash-assertion and a disjoint signature over the transaction itself.

So you could have a “next tx” transition or override with some (non-aggregated) key or require both.

[jamesob]

Brief overview of my current thoughts, for whatever they’re worth:

I’d be happy to modify BIP-119 to omit legacy script support for CTV if there’s a 34-byte “witness v2” along the lines of what @instagibbs sketched out.

My hold out here had been that I thought the BitVM “sibling input requirement” trick relies upon legacy use, but it does not. Note that I still think CTV availability in witness v0 is worth preserving for reasons mentioned above.

If there’s demand to introduce a push-style OP_TEMPLATEHASH that puts the CTV digest on the stack, that sounds like a totally reasonable and low-effort/risk enhancement to me.

---

Do the stakeholders opining here think there could be consensus around this? Namely:

• BIP-119 modified to remove legacy script support (but retaining wit v0 support),
• definition of a witness v2 per instagibb’s patch, and
• inclusion of a tapscript-only OP_TEMPLATEHASH?