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?

No, you get the fulfillment and the message. The message tells you the
sequence number (so you can make sure that this update is newer than any
updates you've previously seen) as well as the current state (e.g. the
balance of the payment channel). Then you verify the fulfillment against
the message and the condition. That's it.

On Fri, May 20, 2016 at 3:01 PM, Jehan Tremback <jehan.tremback@gmail.com>
wrote:

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