Re: Cryptoconditions-based escrow

Hi Bob,

Thanks for the additions and clarifications.

It would be interesting to see if something can be implemented like “key”
happened. Maybe a notary ledger could indeed foresee these kind of actions?

I've removed the negative weights and went for a simple
InvertedThresholdSha256, which simply inherits from ThresholdSha256 and
inverts the validate.
I'm fully aware that it requires more complex logic to identify this
component in the branch, but once you do - you would know it can only
output False if the ThresholdSha256 had validated to True. Maybe that's a
path forward? For know, I'll see how to fit this inside BigchainDB, without
opening it to the ILP spec. Suggestions
<https://github.com/bigchaindb/cryptoconditions/pull/13/files> are always
welcome (re delegated inversion gates of @justmoon)...

Thanks,

Dimi







Op vr 27 mei 2016 om 18:37 schreef Bob Way <bob@ripple.com>:

> 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 <ben@ripple.com> | 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>
> 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
>>
>
>
>