Fwd: Cryptoconditions-based escrow

Putting this topic in the community, as tagged 'interesting enough'

---------- Forwarded message ---------
From: Stefan Thomas <stefan@ripple.com>
Date: do 26 mei 2016 om 19:36
Subject: Re: Cryptoconditions-based escrow
To: Dimitri De Jonghe <dimi@ascribe.io>
Cc: Evan Schwartz <evan@ripple.com>, Adrian Hope-Bailie <
adrian@hopebailie.com>


Hey Dimi,

First off - your logic is totally sound. But it raises some interesting
questions. Crypto-conditions provide a stateless method for systems to
interoperate. If you show me a signature, I know the act of signing
happened without me or the signer having to store any state. But there is
nothing you can show that tells me statelessly that the act of signing did
not happen.

Imagine if I have a fulfillment and it's for a threshold, but it doesn't
meet the threshold. I look at it more closely and I notice that it doesn't
meet the threshold because there is a condition in it that is fulfilled,
but has a negative weight. I can always remove that fulfillment and not
tell anyone about it and suddenly the condition is valid.

And it makes sense that that would be the case - crypto-conditions are
proofs. And you can't prove a negative cryptographically. There is nothing
that I can show you that convinces you that a certain signature DOESN'T
exist or that I DON'T know a certain preimage. I might just be pretending
that I don't know it.

This challenge is closely related to the purpose and value of blockchains.
David Schwartz always says that the point of a blockchain is the ability to
prove a negative. E.g "there is NO other transaction spending these same
bitcoins."

What that means is you can use BigchainDB as the inverter. I.e. any
BigchainDB node could sign a thing saying "this has not happened on MY
ledger before time X" - if that seems roundabout, notice that such a
condition could be evaluated by anyone, not just within BigchainDB, but on
any third-party system as well.

I think we want crypto-conditions to be the minimal thing that enables
different systems to interoperate securely.

- A clock condition is something that's already on our "things to look
into" list. I'd be in favor of spec'ing one out and implementing it just to
see if we run into any issues/weirdness. Expect some complexity, because
time has a tendency to have very subtle issues that need to be diligently
thought through. For instance, we can't use the unix epoch for our
timestamps because it is not monotonically increasing due to leap seconds.
ISO 8601 is, but it's also more complex. If you use neither of those two -
well, you're using some notion of time that isn't very widely supported,
which will cause other problems most likely.

- General inversion or negative weights do not work. (I can just leave it
out and pretend I don't know the fulfillments that don't help me.) I'd be
against adding them. They may be useful within a system, but that's not
really what crypto-conditions are meant for - many core features like
hashing, signatures etc. are all only useful between systems. So
representing logic circuits within a single system, crypto-conditions are
already not very good at. I'm happy to share my thoughts on how to do logic
within a blockchain system separately, if you're interested.

- But you could have delegated inversion gates, this would be a gate with
two subconditions. One is the condition (i.e. fact) being inverted, the
other is an attestor (i.e. a public key or key tree) who says that they
haven't seen a fulfillment for this condition. Inversion gates would also
have a timestamp which is the time by which the attestor has not seen a
fulfillment.

When delegated inversion gates are used within a ledger like BigchainDB,
maybe you'd even recognize you're the signer and shortcut the signature
verification, i.e. I trust myself, so I won't verify the signature.

Anyway, these are just some thoughts off the top of my head.

@Dimi: Do you mind if I forward this email thread to the mailing list? This
is exactly the kind of discussion we'd like to have more of. I understand
if you'd rather not, that's why I ask.

- Stefan



On Thu, May 26, 2016 at 2:01 AM, Dimitri De Jonghe <dimi@ascribe.io> wrote:

> Hi guys,
>
> Whilst implementing escrow in BigchainDB, I came to the conclusion that
> almost all building blocks are provided by cryptoconditions.
>
> PS: BigchainDB has no notion of transaction state (as five-bells-ledger
> does). So any transaction accepted by bigchaindb needs to be valid and
> final.
>
> I've put on my (old) electronics hat and came to the following conclusions:
>
> - thresholdconditions are reconfigurable gates (AND, OR and something
> smooth in between)
> - adding an *inverter* allows you to create almost all logic gates, see
> (a)
> - timing out an escrow only needs to be fed by a *clock, *see (b)
>
> (a) The inverter is easy: just account for negative weights in
> thresholdconditions, and make sure that negatively-weighted inputs to the
> threshold condition are inverted in validate.
>
> with (a), it is easy to create a `switch`:
> (C1 AND C_switch) OR (C2 AND NOT C_switch)
>
> (b) The timeout can be simply an extension to a hashlock:
> - put the expiry date in the preimage (no need to hide this actually)
> - pass the (normalized UTC) time to the validate
> - validate time <= expiry
>
> (a) seems solid from a crypto-security sense.
> (b) relies on the clock, which is a datasource that needs to be supported
> by the ledger. In fact, this would open more doors towards smart-contracts,
> hence the box of pandora. But restricting to a few basic datasources to
> inject in the validate might be a decision taken by the ledger. Of course
> you can easily tweak this to block_height instead of clock
>
> Anyhows, I gave it a try with fine results.
> You can see the explanation in more detail here:
>
> https://github.com/bigchaindb/bigchaindb/blob/feat/201/escrow/docs/source/python-server-api-examples.md#timeout-conditions
>
> What's the impact of this proposal?
> Any ledger that supports cryptoconditions and has a clock or a notion of a
> timeout-condtion supports escrow out of the box. I thought that was neat as
> it lowers the friction and powers the ledgers
>
> Let me know your thoughts,
>
> Best,
>
> Dimi
>