Re: Crypto-condition Spec and Status

On 29 February 2016 at 21:34, Shane McCarron <shane@halindrome.com> wrote:

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

Well the idea of verifiable was to use the same terminology as verifyable
claims.  ie cryptographic proofs are one way of verifying something, but
not the only way.  Do you see a specific clash conceptually?


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