Since I just discovered this forum and some interesting conversations are going on here. I definitely saw James’ proposal here, not trying to undermine that, just trying to give an alternative perspective.
I’ve been thinking about this idea, which I dub “covenant all the things”, which I guess could go a few ways. The idea is to not focus on specific use-cases (APO, VAULT), but provide more general tools that
A very minimal version would be a combination of
OP_TXHASH
and OP_CHECKTXHASHVERIFY for templating
OP_CHECKSIGFROMSTACK
together with TXHASH this is very powerful
easily emulates APO to build eltoo-style protocols
These two are already very powerful together. It basically introduces a “sighash on steroids” that allows signing off on anything you want. Plus a very flexible templating mechanism that supports bring-your-own-fee constructions.
So, on top of that, to allow real introspection, there are some possibilities:
the full version would be
OP_CAT
who doesn’t like CATs?
OP_TX
for full introspection, this works quite well with OP_TXHASH’s TxFieldSelector
64-bit arithmetic
for anything with amounts
OP_TWEAKADD
for doing taproot stuff
a lesser version
OP_HASHMULTI (aka OP_CATSHA256) or something
OP_TWEAKADD (this seems kinda needed in any case)
One of the nice properties of all of this is that almost all of these opcodes already have production implementations in Elements (Liquid), except for the OP_TXHASH and OP_TX which are closely related. I formalized a potential OP_TXHASH BIP here (discussion here on Delving here), and OP_TX could be implemented by re-using the TxFieldSelector specified in that BIP.
You’re certainly welcome to cross-port OP_CAT and OP_CHECKSIGFROMSTACK to inquisition; I’m skeptical that it’ll be reasonably feasible to do anything useful with them in script (as opposed to handwaving on a blog / mailing list), but I’d love to be proved wrong. Could specify the behaviour on the wiki (eg Relay Policies · bitcoin-inquisition/bitcoin Wiki · GitHub) if you didn’t want to write up a proper BIP yet.
CHECKSIGFROMSTACK only really makes sense with something like TXHASH so that you have something to sign, I guess. Building a covenant with just CAT+CSFS is indeed not reasonably feasible, I agree with that. Though look at what the BitMatrix guys have built, it’s pretty impressive, though obv it requires arithmetic too.
CHECKSIGFROMSTACK only really makes sense with something like TXHASH so that you have something to sign, I guess. Building a covenant with just CAT+CSFS is indeed not reasonably feasible, I agree with that. Though look at what the BitMatrix guys have built , it’s pretty impressive, though obv it requires arithmetic too.
I mentioned this over on Telegram, but think it’s worth saying here as well: I think it makes more sense to take something like TXHASH or Template Key and make an APO-ish new Tapscript key version with a variant that works well with signatures rather than adding CSFS. If we get to the point that we’re adding full introspection then that changes, but until then there are differences in how we should hash things between equality/script usage and signature usage.
I see the benefits of introducing a key version (simple keyspends mostly), but I don’t see the drawbacks of CSFS as an alternative. A few more bytes in the witness?
What I personally like about TXHASH is that it gives both templating and a sighash with just CSFS extra. Defining a key version seems more work than adding the opcode.
There might actually be semantic differences. With TXHASH+CSFS you can specify exactly what message each key has to sign. With sighashtypes (AFAIU), the sighashtype is added to the signature, so it can’t be enforced by the script but is provided at sign-time by the signer.
I have to confess I didn’t do much thinking about these differences and which semantics are more desirable.
I see the benefits of introducing a key version (simple keyspends mostly)
Sadly, APO (and other such ideas for new Tapscript key versions) don’t enable key path spends because that would split the anonymity set of Taproot outputs
There might actually be semantic differences. With TXHASH+CSFS you can specify exactly what message each key has to sign. With sighashtypes (AFAIU), the sighashtype is added to the signature, so it can’t be enforced by the script but is provided at sign-time by the signer.
Exactly, it is semantically different. Which is more likely when a hash is going to be used with a signature: The signer may specify at signing time what parts of the transaction they want to hash and is the party best suited to make the decision on what hashing modes to use; or the creator of the output script knows exactly the single hashing mode appropriate for the signer to use at script creation time. Until we are enabling ~full introspection, I would argue that the former is much more useful and matches the expected semantics of bitcoin script better.
But with TXHASH and CSFS, both options are possible, while with a sighashtype only the at-sign-time option… To emulate a sighashtype, the user would pass a TxFieldSelector (or whatever you call the input to TXHASH) and a signature and then the script would generate the hash value using the user’s input and then validate the signature.
One could actually argue that this is a more pure implementation of OP_CHECKSIG in Bitcoin Script…
Sure, you can get the same result with TXHASH + CSFS, but now you have hash modes (tagging with the selected mode, annex hashing) that are only used with CSFS where those could be omitted if the same general hash structure was available separately in the separate contexts. (If you haven’t already, reading Template Key might make this more clear)
Hmm, yeah so I think I read the part where you specify the template hashtypes for CTV. So this document adds them as sighash types basically.
In theory we could do the exact same thing with TXHASH: specify a key type and use the TxFieldSelector construction as a “sighash flags on steroids” where you can use that to select parts of the tx to hash.
Your proposal a huge difference in flexibility with TXHASH, though. For example the special treatment of only the first input is very limiting in many ways.
I think I’m at the point where all resource usage concerns can be elevated from TXHASH so I don’t see why we would need a system that pre-sets different modes of operation instead of allowing users to set their own. Of course the result is very likely that only a handful of TxFieldSelector values will take up 99% of usage, but it does allow protocol developers to construct more complicated systems.
Actually this makes me think twice about the default for TXHASH. Currently the default is “all that’s non-recursive”, so CTV-style. But in fact for a sighash, the regular “ALL” makes more sense.
We do have one special case value we can assign: the 0x00 byte, because “not including anything” is currently not allowed. So we could play with two different “shortcut values”: 0x and 0x00.
I think the common bottleneck on both of your proposals is fleshing out use-cases.
In principle, I’m for maximum sighash flexibility: anyone should be able to elect to include any component in their sigmsg. But the reality is that there will be some limitation on that interface - bitmask/template parameters can only be so long, and different approaches merit different caching strategies.
To resolve this, we need to have a clear idea of what the proposed uses are - that is, what are the use-cases are not met by the standard 119 template hash? Ideally, you’d both be able to present some kind of code sketch of how these use-cases are satisfied by your proposals.
The details that you’re discussing above are worth discussing, but I think they are dwarfed in comparison to the thing that’s blocking the evaluation of both of your proposals, which is: what exactly do we need different sighash/template modes for?
This is a tricky proposition in both cases, and is a bar not met by APO. APO introduces 6 new sighash modes, of which exactly 1 appears to have a detailed use case with code. 1 other has a potential use case once certain policy/relay changes are made, and 1 more has a vague description of how it can be used with PTLCs. More importantly, APO excludes certain modes which have potential uses (added by my PR#1472).
For Template Key, I did show which modes match with the known useful APO modes, and agree that a description of how several other modes can be used would be helpful.
Both Template Key and TXHASH are intended to open up a new design space for hash equality and signature verification, so I think the right bar should be to have an example of a concrete protocol which uses each feature of the new hash specifier, not “what exactly do we need [each mode for]?”
which exactly 1 appears to have a detailed use case with code. 1 other has a potential use case once certain policy/relay changes are made, and 1 more has a vague description of how it can be used with PTLCs
Can you be more specific which uses-cases you’re referring to? I have guesses, but making references without citations makes it hard to judge your judgment of the maturity of the ideas. Thanks!
