W3C home > Mailing lists > Public > public-interledger@w3.org > February 2016

Re: Crypto-condition Spec and Status

From: Shane McCarron <shane@halindrome.com>
Date: Mon, 29 Feb 2016 14:34:26 -0600
Message-ID: <CAJdbnOA10Nr2-CXm8=RHR0jzLFp4ONF8ij7WCKMJU=2xuvcr-w@mail.gmail.com>
To: Stefan Thomas <stefan@ripple.com>
Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Interledger Community Group <public-interledger@w3.org>
I think we should avoid using "verifiable *" because it has the potential
for confusion with another effort already within the payments space at W3C
(Verifiable Claims Task Force is a TF of the Web Payments Interest Group).
As to "Smart Signatures"...  not bad.  However, note that as Stefan
mentioned these signatures aren't really that smart as it stands ;-)

On Mon, Feb 29, 2016 at 1:57 PM, Stefan Thomas <stefan@ripple.com> wrote:

> > But why, 'crypto' conditions, rather than 'verifiable' conditions -- it
> is branding or do we want to limit the scope?
> Regarding limiting the scope: I believe that any real-world use case that
> I've seen can be served by delegation. (I.e. the ledger delegates authority
> over a given transaction to some threshold tree of keys.) That avoids
> having to create and standardize a programming language (hard) with
> bit-perfect precision (very hard). And it avoids having to have the large
> attack surface that programmability brings - one person I will quote
> anonymously quipped it was the "ActiveX of blockchain." If anyone wants the
> programmability, they can select a set of smart oracles that is large
> enough to represent the same security level as the ledger and delegate the
> decision to those nodes. If ledgers widely believe that offering smart
> oracle functionality to their customers is beneficial, they can run such a
> smart oracle separately from the ledger itself. That way, any user who does
> not need or want the smart oracle functionality is not at risk if the smart
> oracle gets hacked, because it's separate from the ledger. (Large attack
> surface, remember?)
> That said, the scheme is such that programmability could be added to it.
> At the workshop I mentioned that if you wanted you could define a condition
> type where the condition is the hash of a piece of JavaScript and the
> fulfillment is the input to that piece of JavaScript. You'd have to select
> a language or subset of a language that is fully deterministic, perfectly
> specified and perfectly implemented. The slightest difference in execution
> between nodes is a complete break in security. WebAssembly, perhaps...
> someday?
> I'm not at all married to the name in any way. I kind of like "Smart
> Signatures", which is a related effort:
> https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust/blob/master/final-documents/smart-signatures.pdf
> Main reason we didn't use the term "smart signatures" is because we'd want
> to talk to the people behind it first to see if our goals align enough to
> merge our efforts.
> On Mon, Feb 29, 2016 at 11:32 AM, Melvin Carvalho <
> melvincarvalho@gmail.com> wrote:
>> On 29 February 2016 at 20:07, Stefan Thomas <stefan@ripple.com> wrote:
>>> Just wanted to follow up on Thursday's discussion by posting a first
>>> draft and example implementation of the crypto-conditions spec:
>>> https://github.com/interledger/five-bells-condition/tree/feature/binary-merkle
>>> Also here are the slides I presented on Thursday. For those who weren't
>>> able to join, the presentation was recorded and we will seek to make the
>>> recording available as soon as we can.
>>> http://www.slideshare.net/Interledger/ilp-workshop-cryptoconditions
>> I like it!
>> But why, 'crypto' conditions, rather than 'verifiable' conditions -- it
>> is branding or do we want to limit the scope?
>>> - Stefan

Received on Monday, 29 February 2016 20:34:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 February 2016 20:34:55 UTC