Re: Cryptoconditions-based escrow

Hi Evan,

Indeed, it's true that you can omit an inverted branch and pretended you
didnt see it. Hence it's not a clean solution
Do you think there is something like a VETO fulfillment?

Regarding the delegated inversion:
- Our main use case is to create a switch: either one of 2 signature
branches is valid based upon a fact/condition. If there are other ways to
create a switch, I would be more than happy to explore.
- The inversion would only be approved by an authority/attestor?
- I assumed that the inversion would mainly apply about facts that can be
verified, not about signatures or other crypto-conditions. Otherwise we end
up with ignored branches or veto's.
- We can set up something of a fact inversion in BigchainDB. Any
thoughts/comments are more than welcome.

Regarding the clock condition:
- The UNIX epoch leap seconds are indeed a PITA. One assumption would be to
set a warning/disclaimer that time is not monotonic or exact and the
fulfillment should occur within reasonable bounds (eg expiry_time - 1
minute or so)

Best,

Dimi

Op do 26 mei 2016 om 19:36 schreef Stefan Thomas <stefan@ripple.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
>>
>
>