Re: Crypto-condition Spec and Status

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

> > Couldnt the market take care of this by people not signing contracts
> with sin() functions (or similar) in them?
>
> There are a lot of such sources of non-determinism - as in: thousands.
> Just for fun, here's some more:
>
> (""+0['constructor'])[30] // Firefox: "e", Chrome: "d"
> try { new Error.stackTraceLimit } catch (e) { console.log(e.message[31]) }
> // Firefox: "c", Chrome: "e"
> __proto__.constructor.TEMPORARY // Firefox: undefined, Chrome: 0
>
> I don't think it is possible to enumerate (blacklist) them all. I would
> estimate there are thousands of these, some of which being incredibly
> subtle. It was just never a design goal of JavaScript to make it run
> deterministically. You could try to create a deterministic subset
> (whitelist) of JavaScript, but even that would be quite difficult since for
> a deterministic language you would likely make some very different design
> choices.
>
> Regarding HTTP calls:
>
> > I agree it's a challenge, but I dont think it's impossible.
>
> Apologies, I should have been more precise, making them deterministic is
> impossible. Deterministic means that there cannot be a different outcome
> given the same inputs. The outside world isn't deterministic and the
> outcome of HTTP calls may depend on the outside world. Therefore HTTP is
> not deterministic.
>
> What you're arguing I think is that determinism is not necessary. That
> goes back to my earlier point that without determinism, the connector has
> to understand the condition. So we can no longer build a general-purpose
> value transfer network that is use-case agnostic. Now any connector on the
> path of your payment has to explicitly allow calls to Github specifically
> and is exposed to risk related to Github not working.
>
> And again, I want to point out that you can avoid all these issues simply
> by using delegation. With delegation you can have a payment depend on a
> call to Github and still have the resulting condition be deterministic.
>
>
> > Im guided here by Satoshi's bitcoin paper where he says 'a certain
> amount of fraud is accepted as unavoidable' -- so while ddos is a fact of
> life on the web, we can hope that services such as github have enough
> uptime to be nevertheless useful.
>
> I totally agree with your general point that sometimes it is better to
> accept some fraud than to try and prevent it. But you should probably point
> out the context of that quote. Satoshi is arguing *against* accepting that
> fraud as unavoidable. In that sentence he's talking about the broken status
> quo which he intends to fix by creating Bitcoin.
>

The context is the first paragraph of the bitcoin paper:

Commerce on the Internet has come to rely almost exclusively on financial
institutions serving as trusted third parties to process electronic
payments. While the system works well enough for most transactions, it
still suffers from the inherent weaknesses of the trust based model.
Completely non-reversible transactions are not really possible, since
financial institutions cannot avoid mediating disputes. The cost of
mediation increases transaction costs, limiting the minimum practical
transaction size and cutting off the possibility for small casual
transactions, and there is a broader cost in the loss of ability to make
non-reversible payments for nonreversible services. With the possibility of
reversal, the need for trust spreads. Merchants must be wary of their
customers, hassling them for more information than they would otherwise
need. *A certain percentage of fraud is accepted as unavoidable.* These
costs and payment uncertainties can be avoided in person by using physical
currency, but no mechanism exists to make payments over a communications
channel without a trusted party.

https://bitcoin.org/bitcoin.pdf

So the way I read the context here, is that where you have trust, there is
a certain percentage of fraud, that is accepted as unavoidable.  Note also
that Satoshi says that this system "works well enough for most
transactions".  I dont see anywhere where satoshi says the status quo is
broken.  My take is that adding a zero trust option (ie the electronic
equivalent of cash) makes the total landspace that much better.

I see a similar situation with ILP and a deterministic model.  For sure
it's a good thing and it would make the overall landscape better.  But I
also think that the trust based system we have come to use on the web also
"works well enough for most transactions".  Consider advertizing revenue is
a major driver of commerce, and often has (click) fraud rates in the double
digit percentage points.  It's accepted as a cost of doing business, even
by security experts, with an eye for detail.


>
> On Mon, Feb 29, 2016 at 11:56 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
>>>
>>> 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.
>>>
>>
>> I agree it's a challenge, but I dont think it's impossible.  Im intending
>> to actually build a proof of contract using github smart contracts to
>> release payments for coding (in open source projects).  Im guided here by
>> Satoshi's bitcoin paper where he says 'a certain amount of fraud is
>> accepted as unavoidable' -- so while ddos is a fact of life on the web, we
>> can hope that services such as github have enough uptime to be nevertheless
>> useful.
>>
>>
>>>
>>> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>