Re: Composable Conditions

Looks good to me too.
On May 18, 2016 6:53 PM, "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.
>