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

Re: Composable Conditions

From: Rafael Pereira <rafael@rippex.net>
Date: Thu, 19 May 2016 01:51:32 +0000
Message-ID: <CAFk+OK=1wTjG5eHjZrevHfPa6Mxck4yZ878sGQK0G=tz6wk1QA@mail.gmail.com>
To: Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
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 01:52:13 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 19 May 2016 01:52:13 UTC