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

Re: Composable Conditions

From: <zaki@manian.org>
Date: Thu, 19 May 2016 02:13:53 -0700
Message-ID: <CAJQ8TmBHD6XJ_oU5TMPcZ3NRiGh0b-aGJ9_g4n1J6+_-0q2CRQ@mail.gmail.com>
To: Rafael Pereira <rafael@rippex.net>
Cc: Interledger Community Group <public-interledger@w3.org>, Stefan Thomas <stefan@ripple.com>
I disagree with statement that hashlocks aren't really signatures. See
Lamport signatures, xmss.

So I think it's fully proper to calm this a signature system.

I do find myself using the words condition and signature somewhat
interchangeably when talking about this kind of thing.
On May 19, 2016 3:53 AM, "Rafael Pereira" <rafael@rippex.net> wrote:

> LGTM
>
> Em qua, 18 de mai de 2016 às 20:20, Stefan Thomas <stefan@ripple.com>
> escreveu:
>
>> 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
>>
> --
>
> Obrigado,
> Rafael
>
> *Rafael Olaio - CEO*
> tel +55 11 2337.2225
> cel +55 11 99522.7572
> rippex.net
>
> Esta mensagem pode conter informação confidencial e/ou privilegiada. Se
> você não for o destinatário ou a pessoa autorizada a receber esta mensagem,
> não poderá usar, copiar ou divulgar as informações nela contidas ou tomar
> qualquer ação baseada nessas informações. Se você recebeu esta mensagem por
> engano, por favor avise imediatamente o remetente, respondendo o e-mail e
> em seguida apague-o.This message may contain confidential and/or
> privileged information. If you are not the addressee or authorized to
> receive this for the addressee, you must not use, copy, disclose or take
> any action based on this message or any information here in. If you have
> received this message in error, please advise the sender immediately by
> reply e-mail and delete this message.
>
Received on Thursday, 19 May 2016 09:14:23 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 May 2016 09:14:23 UTC