Re: Crypto-condition Spec and Status

> 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

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.


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