Also the core-devs has put a “regtest” label on the PR, can I see thr opcodes running on something like mempool.space?
regtest means you can only use it on your own computer on a private blockchain.
lol, atleast let me run on some test net that we all can view through mempool space UI.
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.
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.
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.
It seems like this could be worked around since OP_CTV does commit to the scriptSig according to instagibbs
However this seems rather unpleasant.
I think Jeremy Rubin is conceding the point that at least for p2sh OP_CTV is broken?
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?
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.
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).
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.
This is a cool patch, thanks for doing it.
I still prefer the existing CTV impl. for a few reasons:
- 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.
- 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.
- 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.
@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.
No other output lengths would be defined for the “P2CTV” case, there’s no difference in this respect.
33WU, or <9vB. I don’t find byte pinching over hypotheticals very persuasive but other’s mileage may vary.
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.
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.
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.
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
?