Re: Crypto-condition Spec and Status

On 1 March 2016 at 12:54, Adrian Hope-Bailie <adrian@hopebailie.com> wrote:

> I think the key point here is that ILP is intended to be the core/base
> protocol and therefor has no tolerance for any risk.
> As such it defines conditions that MUST be based on deterministic
> evaluation of the fulfillment data.
>
> One could compare this to TCP/IP and the fact that when you build
> applications on top of this you can make certain assumptions about the data
> stream (such as byte ordering).
>

I think to compare ILP to TCP/IP is not quite like for like.  They do
different things, and TCP/IP now has ubiquitous support in a largely design
neutral way (that last point could possibly be debated tho).  ILP is simply
one possible way to link ledgers, there could be more.  Dont get me wrong,
I do like it, and I would also like to implement it, but there are
artifacts and design choices which other developers may make design
decisions for.

Much also depends on your trust profile, ILP looks like a good solution in
zero trust environments, but perhaps overkill in some high trust
environments.  There also may be some differences in how ledgers are
constructed, to work out how to link them.

It's going to be quite interesting when we get to the point of interop
tests, this kind of thing will become clearer,


>
> That said, it is possible to build more complex and flexible applications
> on top of ILP by delegating conditions up to the application layer in the
> same way as you build more complex protocls on top of TCP/IP (like HTTP).
>
> Applications built on ILP MUST be able to assume that if a condition is
> fulfilled and the escrow is released from one ledger it will be released by
> all ledgers in the payment path.
>
> I can imagine a system like the one you propose where the condition is
> defined as requiring a signature from Github's servers or a smart oracle
> setup by the system for this purpose. The point is that once the condition
> has been fulfilled and the signed receipt is received by the payee that
> same receipt can be provided to every ledger in the payment path to release
> the escrows they are holding.
>
> In this case the executable logic is held by the smart-oracle and the only
> thing that must be defined in the ILP condition is who the oracle is so
> that their signature can be verified.
>
>
>
> On 1 March 2016 at 11:44, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>