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:11:51 +0000
Message-ID: <CADkP8CqB-xTBMb5B17EmoGxJJxwz4-fe6K8UkSQZW0fwR9EM9w@mail.gmail.com>
To: Adrian Hope-Bailie <adrian@hopebailie.com>, "zaki@manian.org" <zaki@manian.org>
Cc: Rafael Pereira <rafael@rippex.net>, Interledger Community Group <public-interledger@w3.org>, Stefan Thomas <stefan@ripple.com>
+1 for sentimental value

Op do 19 mei 2016 om 11:34 schreef Adrian Hope-Bailie <adrian@hopebailie.com

> I am +1 for keeping the word "conditions"
> I am not that keen on dropping the "crypto" part of it though
> Do we really need to change the name?
> Maybe I'm being sentimental but I have grown attached to it :)
> On 19 May 2016 at 11:13, zaki@manian.org <zaki@manian.org> wrote:
>> 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 10:12:38 UTC

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