Re: Crypto-condition Spec and Status

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