Re: Crypto-condition Spec and Status

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


-- 
-Shane