- From: Jehan Tremback <jehan.tremback@gmail.com>
- Date: Fri, 20 May 2016 13:48:36 -0700
- To: Roger Bass <roger@traxiant.com>
- Cc: Rafael Pereira <rafael@rippex.net>, Daniel Bateman <7daniel77@gmail.com>, Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CABG_PfTMHSXU9sKOJ+bL3mgy7k3QftZ-yO38rWyd62-Y0kL-5g@mail.gmail.com>
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 20:49:04 UTC