Re: Composable Conditions

So, you would just run a sequence of numbers through the condition to find
the right one? Is there some way to do a binary search?

I think it's possible to make a ledger that supports channels with any
iteration of crypto-conditions.

On Fri, May 20, 2016 at 2:31 PM, Stefan Thomas <stefan@ripple.com> wrote:

> @Jehan: Crypto-conditions do support your use case. Initially, we wanted
> to do it by making the *return* value of the condition a float and adding a
> serial number field. But then we realized that a much more flexible way is
> just to treat the dynamic value as an input and return whether this input
> was validated. This distinguishes a condition from a full programming
> language.
>
> The message is an arbitrary octet string, so it can be a float (fraction
> between 0 and 1) plus an integer (serial number) or whatever you want. The
> condition validates that the float was correctly signed. That way we can
> support your use case and many others without adding any complexity to the
> standard.
>
> With the current version of crypto-conditions it is possible to make a
> ledger that supports payment channels - unless I'm majorly missing
> something.
>
>
> On Fri, May 20, 2016 at 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.
>>>>>
>>>>
>>>
>>
>