W3C home > Mailing lists > Public > public-interledger@w3.org > May 2016

Re: Composable Conditions

From: Dimitri De Jonghe <dimi@ascribe.io>
Date: Thu, 19 May 2016 10:50:54 +0200
Message-ID: <CADkP8Cq3aZPSS=CQbz5wLhkABy3yraaC9E29731SeDFeX_Ocrw@mail.gmail.com>
To: Stefan Thomas <stefan@ripple.com>
Cc: Interledger Community Group <public-interledger@w3.org>
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
Received on Thursday, 19 May 2016 08:51:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:13:57 UTC