Re: Composable Conditions

Hi all,

+1 for cryptographic one-way functions and ways to compose them.

Breaking this down a bit:

INPUT: One-way functions in a crypto-context
OPERATOR: Compositions is correct as it only allows for AND, OR and
threshold. But excludes NOT, hence no true boolean logic.
OUTPUT: Conditions might also be a bit ambiguous, but is correct. One could
mistake conditional statements (if - then - else) for the conditions that
need to be evaluated.

In the nomenclature of Composable Conditions I am missing the one-way
functions/crypto somewhat.

Alternatively one could go for crypto-compositions but that might not
emphasize the condition part enough (focus on input rather than output)

Dimitri De Jonghe, PhD

Senior Developer, ascribe GmbH

Wichertstr. 17, 10439 Berlin. Managing Director: Bruce Pon. Registered in
Berlin HRB 160856B. info@ascribe.io

2016-05-19 1:18 GMT+02:00 Stefan Thomas <stefan@ripple.com>:

> Hi list,
>
> During one of the recent community group calls we promised that we would
> work on a better nomenclature for crypto-conditions.
>
> The main criticism we heard was that it seemed like it was called
> crypto-conditions based on a very narrow use case (triggering events based
> on signatures) in five-bells-ledger and that using them for multi-sig was
> going to be a more common use case.
>
> However, one person also commented that hashlocks aren't really
> signatures. (We've called them zero-bit signatures before, but that's like
> calling a road a "zero-river bridge".)
>
> I've discussed the terminology with Evan and here is what we propose:
>
> Composable Conditions are a standard for cryptographic one-way functions
> and ways to compose them.
>
> The idea here is that "condition" is actually broader than "signature". A
> signature verification algorithm is a function which returns a boolean:
> valid/invalid. A hashlock is also a function which returns a boolean:
> valid/invalid. In the future we may add a scriptable condition, but it
> would still return true or false. The general term for a thing that returns
> true or false is a "condition".
>
> Once you think about the idea of a "condition", you can also understand
> the use cases for this standard. Conditions can be triggers for events, but
> they can also be used for authentication ("accept any command that meets
> this condition".)
>
> The term "condition" also neatly expresses what we think is not in scope:
> Our spec specifically does not allow you to perform computation (returning
> values other than true or false.)
>
> Aside from the fact that it abstracts the condition type, the other
> significant feature of the standard is that it provides condition types
> which are a composition of other conditions.
>
> That's why we propose "Composable Conditions" as the new name. Please let
> us know your feedback in this thread!
>
> - Stefan
>