Re: Crypto-condition Spec and Status

On 1 March 2016 at 10:34, Stefan Thomas <stefan@ripple.com> wrote:

> > 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?
>
> It's interesting to note that legal contracts actually use delegation. Do
> you go to your bank (=ledger) to enforce a contract? No, you go to a
> dedicated entity like a judge (=smart oracle) to interpret your contract
> and then you take the resulting order to the bank.
>

Well I think you have both.  Banks do have a loan book which is a number of
legal contracts based on a set of rules (repayments).  As you rightly point
out there is also a delegated layer on top.  I agree these are things I'd
like to see developed more.


>
> And it seems obvious why it evolved that way - interpreting contracts is
> complex, so you want to have that complexity in a specialized system,
> rather than every bank, business, person, etc. having to be able to do it
> by themselves. And it also avoids the non-determinism issue - what if banks
> interpreted contracts, but two different banks judged the outcome of a
> given contract differently? By using a judge, you guarantee that there is
> only one decision.
>

So I think we are agreeing, what I suggested was a market for
specialization in contracts.  So you look at a contract at the start, and
then over the course of its life time to see if it is fulfilled.


>
> It's not a perfect analogy, but I thought it was interesting enough to
> point out.
>

Very good analogy, imho.  We've traditionally had this code written in
books.  In moving it to the electronic sphere I think it's valuable to look
at what has worked before.


>
> On Mon, Feb 29, 2016 at 3: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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>