Re: Composable Conditions

+1 on "Smart Conditions"

There's a fair amount of blockchain talk about "Smart Contracts". A key,
simple use case for such contracts, I suspect, is "payment against
delivery". It seems to me that this work could map well onto support of
such a scenario.
On May 20, 2016 1:21 PM, "Jehan Tremback" <jehan.tremback@gmail.com> wrote:

I have a similar concept in UPC- "smart conditions" (which is what got me
interested in this standard in the first place). My smart conditions are
some executable code that returns not a boolean, but a number between 0 and
1. This is used for unlocking only part of some funds. Wondering if this is
something you have thought about in this new iteration?

-Jehan

On Fri, May 20, 2016 at 1:03 PM, Daniel Bateman <7daniel77@gmail.com> wrote:

> 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.
>>
>