Proposal to use metadata with cryptoconditions

[dimxy]

This is an idea how improve cryptoconditions usage in blockchain (a copy that I posted in our group chat).
Cryptoconditions is a technology allowing to verify that some cryptographic operation (like signature or hash) is true or not.
The reason for this improvement is that the original cryptoconditions technology is blockchain agnostic and we need to extend it for use in blockchains. The proposal is about adding some metadata to conditions with the info about condition's content (because the condition itself is a hash)

As a reminder, a cryptocondition is a pair of a condition and fulfilment.
The condition itself is a fingerprint (hash) stored in the scriptPubKey. There is a paired fulfilment in the spending scriptSig where the cryptocondition data are open to allow to evaluate it. This is similar to P2PKH, where a pubkey hash is stored in the scriptPubkey and the pubkey is stored in the spending scriptSig.
The cryptoconditions standard (https://tools.ietf.org/html/draft-thomas-crypto-conditions-04) stands that the fulfilment should not be derived from the condition (and this is the reason the condition is hashed and also this makes it compact)
But Alright's concept of generic validators and our past cc development experience showed that often we needed to know about the condition content. Most important thing was to know which evalcode was inside the condition to ensure that tx outputs received cc value for this evalcode.
For this we made the cryptocondition library version 2, which changes the condition serialisation to make evalcodes visible in conditions.

But now I think this was a limited solution:
first, we broke the standard (this is always not good to break standards: we might lose security and potential interoperability with others who use cryptoconditions, for example, Verus or else).
second, our past experience shows not only evalcodes are needed to see in conditions. Sometimes it is good to know the destination pubkey(s).

I propose a more generalised approach: instead of changing condition serialisation to non-standard and exposing only evalcodes, we could attach metadata to conditions that would tell about conditions' content. (And go back to the original standard condition structure supposed by the standard, that is, before cc v2)
This metadata will be optional and cc module dependant. First thing, we could put evalcodes into the metadata, but we could also place various other info, needed by a cc module, like target pubkeys (to verify that the tx output is sent to the appropriate address)

scriptPubKey: <condition><metadata: evalcode(s), pubkey(s), other info about condition>
scriptSig: <fulfilment>

Special case for the creation tx:
currently initial transactions with cryptoconditions v1 are not sent to the cc validation code because those txns do not have cc vins (with fulfilments with decoded data) and the consensus code has no idea which evalcodes are inside conditions.
To provide creation cc txns are validated we will require that creation txns will always have metadata with evalcodes.

The cc validation code must validate that the metadata matches to the condition (this validation will be possible on spending, when the fulfilment is available). I think we might call metadata as 'manifest' as the tx creator declares the condition content.

For metadata encoding we might use the same ASN.1 encoding used to encode cryptoconditions (it is basically a property-value schema).

This is similar to Alright's proposal (he suggests not fingerprint the condition at all) but I propose to preserve the original condition fingerprinting and use metadata instead.

TLDR: it seems cc v2 does not fully cover devs needs as it only opens evalcodes but we need more info plus cc v2 breaks the original cc standard. Instead, let's add metadata to conditions with info about conditions, needed by cc devs, including evalcodes, and implement standard ASN.1 encoding for this metadata.

[dimxy]

In addition to above: using P2SH outputs with cryptoconditions
Yet another problem with cc v2 serialisation is that with it we disallow usage of pay-2-script-hash (P2SH) outputs based on cryptoconditions. The idea of P2SH outputs is that a hashed script is put into a P2SH vout and the original script is mobed into the transaction inputs spending this P2SH outputs.
With ordinary v1 cryptoconditions we could do this as a cryptocondition is a fingerprinted content which does not expose any internal cc data. So as it could be hashed again as a P2SH script. But in cc v2 we expose evalcodes in the output so if we create a P2SH output instead if a cc v2 output, applications that rely on evalcodes exposed in the cc output would not see them and will break.
This is yet another argument to store additional metadata about cryptoconditions internals (for applications like the tokens cc module) in a separate OP_DROP field and not change the original cryptoconditions fingerprinted content

[jmjatlanta]

I am unfamiliar with the differences with v1/v2 serialization, I'll try to learn about that soon. But something I thought of as I was working on another issue is to do what current bitcoin script operations do and manipulate the stack. The script puts things on the stack and different operations add/remove from there. I would guess this would alleviate the OP_DROP necessity. And if each cc was documented as to what it does to the stack, conditions could be chained together.

Just typing out loud

[dimxy]

thank you,
I summarised what we once internally discussed about P2SH and cryptoconditions (because Tokel team is also asking questions about addresses usage) https://github.com/dimxy/komodo/wiki/Use-of-P2SH-with-cryptoconditions.
In this I express an idea that we maybe need to return to cc v1 and consider cc v2 as a limited solution.

The OP_DROP is not mandatory and it could be something else, we just borrowed this from Verus once