- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Fri, 20 May 2016 15:01:00 -0700
- To: Stefan Thomas <stefan@ripple.com>
- Cc: Roger Bass <roger@traxiant.com>, Rafael Pereira <rafael@rippex.net>, Daniel Bateman <7daniel77@gmail.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CABG_PfSCHcs=wy2j=xh48VEKsH3tAWLfQBGKAQqM4+BdZjOjUA@mail.gmail.com>
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. >>>>> >>>> >>> >> >
Received on Friday, 20 May 2016 22:01:28 UTC