Re: Cryptoconditions-based escrow

This is indeed a very interesting thread. In fact it is the very reason that I lobbied for the “notary” addition to ILP that enables atomic mode.

The notary concept was intended to build on top of the  crypto-condition system.

In my mind, for ILP there are two important questions that apply to an ILP transaction:
 1. Did the “key” crypto-condition happen?     [ Did Bob sign the receipt promising to deliver the goods to Alice. ]
 2. Did the “key” crypto-condition happen BEFORE some particular time?   [ Did Bob beat the pre-agreed deadline? ]


The first question works well enough with the model:
 a. I can prove “key" happened.  TRUE
 b. I can’t yet prove “key" happened. DON’T KNOW

However, the second question requires a different model:
 a. I can prove “key" happened.  TRUE
 b. I can prove “key”  didn’t happen.  FALSE


As the second question involves time, there is need for a “time keeper”. This is the primary duty of the notary.
In fact, the notary only needs to know the time and that “key” evaluates to true.
The notary doesn’t need to know the ILP significance of “key” evaluating to true.

So if “key” is a crypto-condition, then there are two related (but mutually exclusive) composite crypto conditions.
 a. “key” AND “true" AND "notarized by X”
 b. “key” AND “false” AND "notarized by X”

Of course, proving ((a) XOR (b)) is as problematic as proving (NOT key).


This leads to the corollary “honest notary” problem.
 1. It is impossible to prove that a notary is honest  [ will never violate ((a) XOR (b)) ]
 2. But it is easy to prove that a notary is dishonest  [ there exists ((a) AND (b)) ]

In the real world, notaries are kept honest by their physical journals. A journal lists chronological entries for everything a notary has notarized.
Like a crypto-condition, the notary journal entry doesn’t contain the significance of what is being notarized, just a reference to details kept externally.

In the crypto world, the digital corollary to a notary’s physical journal is a hash chain. The hash chain could be implemented as a public blockchain. 
This avoids “trusting” any given notary service to maintain the journal (hash chain) and provide an honest query interface to its history.


Anyway, just thoughts to ponder.
Bob Way
Integration Architect | Ripple
bob@ripple.com <mailto:ben@ripple.com> | ripple.com <http://ripple.com/>







> On May 27, 2016, at 4:33 AM, Dimitri De Jonghe <dimi@ascribe.io> wrote:
> 
> Putting this topic in the community, as tagged 'interesting enough'
> 
> ---------- Forwarded message ---------
> From: Stefan Thomas <stefan@ripple.com <mailto:stefan@ripple.com>>
> Date: do 26 mei 2016 om 19:36
> Subject: Re: Cryptoconditions-based escrow
> To: Dimitri De Jonghe <dimi@ascribe.io <mailto:dimi@ascribe.io>>
> Cc: Evan Schwartz <evan@ripple.com <mailto:evan@ripple.com>>, Adrian Hope-Bailie <adrian@hopebailie.com <mailto: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 <mailto: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 <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
>