Re: Composable Conditions

Jehan,

Sorry I didn't mean to write as if I missed your substantive point about
the technology.

Valid as that point may be (and I'm not best qualified to comment), I think
this thread was mainly about the naming issue.

But, despite the possible risk of confusion with your different (?)
technology under the "Smart Conditions" name, I do think using that term
could be quite important in indicating alignment with the notion of smart
contracts.

Roger
On May 20, 2016 1:48 PM, "Jehan Tremback" <jehan.tremback@gmail.com> wrote:

> Roger, I'm not suggesting it as a new name for the crypto-conditions
> protocol, just wondering if people have thought of returning a fraction
> instead of a boolean.
>
> Here's the paper it's from:
> http://altheamesh.com/documents/universal-payment-channels.pdf
>
> On Fri, May 20, 2016 at 1:30 PM, Roger Bass <roger@traxiant.com> wrote:
>
>> +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.
>>>>
>>>
>>
>