Re: Crypto-condition Spec and Status

You can't have anything fuzzy in crypto.  Something needs to be verifiably
from a specific source.  And that source needs to be able to revoke a key /
scheme if its integrity is compromised.  So.... yes, English is fuzzy.
Really fuzzy.  It is why there are so many lawyers.  But crypto, and
crypto-signed documents, are not.  Kind of the point.  "I did this.  Here
is your proof.  You can follow-your-nose and prove it out."

On Mon, Feb 29, 2016 at 5:09 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 29 February 2016 at 23:34, Stefan Thomas <stefan@ripple.com> wrote:
>
>> > Why create and standardize a language when we have javascript already?
>>
>> We would need a deterministic version of JavaScript. The way that
>> crypto-conditions are used in ILP, connectors do not need to understand the
>> condition, because a fulfillment that is valid on one ledger will be
>> guaranteed to be valid on any ledger that is compatible with that type of
>> condition.
>>
>> That's really important because we want to build lots of more specific
>> protocols on top of ILP, so we don't know what all of their conditions are
>> going to look like yet. So if ledgers and connectors can be
>> condition-agnostic, that's awesome.
>>
>> Just to give a concrete example: Here is Math.sin(1) in Chrome and
>> Firefox:
>>
>> http://i.imgur.com/KmKsuMd.png
>>
>
> I didnt know that, thanks for pointing it out!
>
>
>>
>>
>> If this happened with crypto-conditions, an attacker could defraud a
>> connector by creating a condition that fulfills on the ledger right of the
>> victim and doesn't on the ledger left of the victim.
>>
>> So if you wanted to have programmable conditions you would need a
>> programming language that is perfectly defined down to the last bit for
>> every possible execution path. As of today, JavaScript has nowhere near
>> that level of precision in it's standardization. You'd need a stricter
>> subset, or perhaps more realistically, something like WebAssembly.
>>
>> Cryptographic algorithms, of course, do have that level of
>> standardization - if I give you a bytestring to hash with SHA-256, you will
>> always get the exact same hash I got, every time, no matter which
>> programming language and which SHA-256 implementation you're using.
>>
>
> Couldnt the market take care of this by people not signing contracts with
> sin() functions (or similar) in them?
>
> It could be argued that the English language is too ambiguous to make a
> legal contact.  Or that we need a strict subset of englsh to make a legal
> contract.  But isnt it just the case the people look over contracts before
> they sign them, or get a professional to, if there's something more serious
> involved?
>
>
>>
>>
>> > You could make it so that when an issue is closed a bounty is released
>> to that user.  It would be verified by a github 'hook'.
>>
>> That's unfortunately not possible. The real world is non-deterministic
>> and so is the web. If one ledger makes (or receives) an HTTP(S) call to (or
>> from) Github there is no guarantee that a similar call on another ledger
>> will have the same result. So once again as a connector I can't treat the
>> condition opaquely - I have to understand that it's an API call and that
>> it's to Github and that Github is likely to respond with the same response.
>> What's more, I'm now taking Github's server into my risk profile - if their
>> server is down, the ledger on my left may not be able to validate the
>> condition. An attacker being able to DoS Github would now allow customer to
>> defraud me as a connector.
>>
>> So, to summarize, programmable conditions are hard to do (due to the need
>> for a powerful, perfectly standardized, deterministic programming language)
>> and maybe not a good idea (larger attack surface.) HTTP calls and other
>> non-deterministic actions are not possible.
>>
>> But that sounds worse than it is. Delegation solves both use cases quite
>> nicely imho. In both cases, complex logic and HTTP calls, we can have a
>> node that runs the code or makes the HTTP calls and signs the result. If
>> fault tolerance is desired we can have a group of nodes that runs a
>> consensus protocol. That way, our code doesn't even have to be
>> deterministic at all. The consensus protocol can deal with any
>> non-determinism by voting. The signed result will then be deterministic
>> even if the inputs aren't.
>>
>> On Mon, Feb 29, 2016 at 12:38 PM, Melvin Carvalho <
>> melvincarvalho@gmail.com> wrote:
>>
>>>
>>>
>>> On 29 February 2016 at 20:57, 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?)
>>>>
>>>
>>> Why create and standardize a language when we have javascript already?
>>>
>>> So I think you're saying it has a large attack surface?  Im not yet
>>> persuaded by this argument, but would be open to understanding more.
>>>
>>>
>>>>
>>>> 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 McCarron
Projects Manager, Spec-Ops