Fwd: cryptconditions questions

Some Q&A/background regarding crypto-conditions that I thought might be
interesting to some of you.

---------- Forwarded message ----------
From: Stefan Thomas <stefan@ripple.com>
Date: Wed, Jul 13, 2016 at 11:00 AM
Subject: Re: cryptconditions questions
To: Nikolaos Bougalis <nikb@ripple.com>


For both questions I think this is highly relevant background:

https://gist.github.com/justmoon/e68a2fb39f6217ad43a05df63c766912

> Given a cryptocondition *c* and a fulfillment *f*, then what would it
mean to say *f.fulfills(c)*?

There should be a second parameter *m* (a message), which may default to
empty string. In rippled, the message would always be empty string, since
we are using crypto-conditions only as a "trigger", not to sign messages.

In the JavaScript version we offer two APIs for two different use cases.

1. If you already know the condition: validateFulfillment(fulfillment,
condition, message)

2. If you don't know the condition yet: fulfillmentToCondition(fulfillment)
and then validateFulfillment as above


> Is this meant only to check whether a deserialized (binary or character)
fulfillment was loaded correctly, or is there another point to this
function?

This is where signatures are verified. (Probably verify would be a better
name for this method.)

Preimages are independent of the message, so validate(m) doesn't need to do
anything.

Signatures (Ed25519 and RSA) are verified with respect to a message, so
validate(m) will do a ed25519.verify(signature, public_key, message)

Prefixes just prepend something to the message and then use that new
message to verify the subcondition. This allows us to make a condition that
is basically a specific message m1 signed by a specific key. (Take the
signature condition for the key and wrap it in a prefix condition with that
message m1. When you fulfill the resulting condition with an empty message
m0, then the signature must match that message m1 exactly.)

Threshold just passes the message through unchanged and verifies that there
are at least threshold number of valid subfulfillments.

> I get why checking a preimage-sha256 is, in a sense, meaningless: as long
as you have 32 bytes, you have a hash, but it seems that validate is called
with the message whose hash the fulfillment would contain, so why not check
it?

The validate message may have nothing to do with the preimage. Consider
this use case. You have a public key and I want to give you access to my
Ripple stash. But only after my death. So I take your key (signature
condition) and wrap it in a 2-of-2 with a hashlock condition. The preimage
for that hashlock will be automatically revealed by the US government when
I die. Then I wrap this resulting condition in a 1-of-2 with my own public
key and set it as the key for my account.

So now I can still use my account as normal. You can't access my account
for now. But if I die, you'll automatically gain access. For this sort of
use case to work hashlocks have to be independent of the message. You can
sign any transaction (message) with your key and the hashlock is always
open.

We could require that the preimage have some relationship to the message,
but this doesn't actually enable any new use cases and makes a whole bunch
of use cases like the one above non-viable.

On Wed, Jul 13, 2016 at 3:50 AM, Nikolaos Bougalis <nikb@ripple.com> wrote:

> Hey Stefan,
>
> Earlier today I wanted to ask you a couple of more questions but I was
> tackling three chats and forgot two things I wanted to ask.
>
>
>    - Given a cryptocondition *c* and a fulfillment *f*, then what would
>    it mean to say *f.fulfills(c)*? Currently, I define this to mean: *f->condition()
>    == c*, where *f->condition()* generates the fulfillment's condition.
>    Clearly this is sufficient, but is that the optimal implementation, from
>    your perspective?
>
>
>    - In the javascript implementation, you have a *validate* function
>    which returns whether a fulfillment is valid. Is this meant *only* to
>    check whether a deserialized (binary or character) fulfillment was loaded
>    correctly, or is there another point to this function? I'm asking because
>    the *validate* associated with preimage-sha256 simply returns true,
>    instead of doing the minimal work of checking if the message hashes to the
>    value in the fulfillment. I get why checking a preimage-sha256 is, in a
>    sense, meaningless: as long as you have 32 bytes, you have a hash, but it
>    seems that validate is called with the message whose hash the fulfillment
>    would contain, so why not check it?
>
>
> Thanks,
>
> Nik
>
> --
> *Nikolaos D. Bougalis* *|* SENIOR SOFTWARE ENGINEER *|* *RIPPLE *
> +1.702.480.1405 *|* *nikb@ripple.com <nikb@ripple.com>* *|* *https://ripple.com
> <https://ripple.com>*
>