Re: Crypto-condition Update

A big part of the motivation for using crypto conditions (/ "composite
signatures") is to encode potentially complex trust relationships and allow
for various checks to be delegated to other systems.

Imagine a case where you have a condition for, say, an ILP transfer using
atomic mode. The condition would be composed of the signature from the
recipient as well as the signatures from the notaries. Now, let's also say
that you wanted to have some kind of manual override based on offline keys
owned by a variety of different parties. That override procedure would need
to be embedded in the condition in order for the ledger to verify it.
However, in normal operation you don't need to use that and don't need to
send around those details.

By sending only the hash of the condition, the ledger can verify whether a
particular fulfillment matches the condition without knowing the full
structure of the condition logic. Any branches that are falsy are replaced
with the hash of the subcondition so you only need to send the details of
the truthy branches.

On Mon, Mar 21, 2016 at 4:36 PM, zaki@manian.org <zaki@manian.org> wrote:

> I asked the same question when we were working together.
>
> It is to keep the size/ length of cryptocondition as a constant which is
> nice.
>
> Text Secure
> <https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms&hl=en>:
> +1650-862-5992
> Public Key
> <https://raw.github.com/zmanian/pub_keys/master/gpg/%3Czaki@manian.org%3E.public.gpg-key>
>
> On Mon, Mar 21, 2016 at 7:35 PM, Dimitri De Jonghe <dimi@ascribe.io>
> wrote:
>
>> Thanks Evan,
>>
>> Maybe a dumb question - but hey:
>> What's the main motivation to keep the fingerprint of the condition
>> compressed? Just asking since the fulfillment that gets passed around is of
>> full blown size, so don't know if there are significant performance gains
>> during validation. Or is it more from a privacy point of view? Both issues
>> would then be shifted to the higher-level scheme. So probably there is
>> something else I am overlooking...
>>
>>
>> Op di 22 mrt. 2016 om 00:06 schreef Evan Schwartz <evan@ripple.com>:
>>
>>> Here's the current mapping from the old terminology of conditions and
>>> fulfillments onto that of a signature scheme:
>>>
>>>    - Public key - full unhashed condition (which is generated by each
>>>    party rather than being sent around)
>>>    - (Public Key) Fingerprint - condition hash/id
>>>    - Private key - (doesn't necessarily exist in one place, as the keys
>>>    can be on different systems)
>>>    - Message - dynamic message previously included in the fulfillment
>>>    - Signature - fulfillment
>>>
>>> So, Dimi, to answer your question, you can't parse the structure of the
>>> condition/public key from the condition hash/fingerprint. The condition
>>> itself could be very large and comprised of many branches. The
>>> hash/fingerprint is a succinct identifier for that structure. Instead of
>>> parsing the condition details from the fingerprint, the current
>>> recommendation is that participants should generate the condition for
>>> themselves. The details of the condition will likely be defined in
>>> higher-level schemes. Does that make sense?
>>>
>>> On Mon, Mar 21, 2016 at 3:28 PM, Dimitri De Jonghe <dimi@ascribe.io>
>>> wrote:
>>>
>>>> Thanks for the update!
>>>>
>>>> As a matter of fact, we've converted the (old) spec into python to
>>>> better figure out how it fits in our system.
>>>> Details of the PR can be found here
>>>> <https://github.com/bigchaindb/bigchaindb/pull/146>
>>>>
>>>> As we are mainly using a signature scheme, your efforts are in line
>>>> with our thoughts:
>>>>
>>>> Our main use case is that people publish a condition, and actors in the
>>>> system should be able to propose a fulfillment, given a condition.
>>>> For an ED25519 condition in the new proposal, this should be fairly
>>>> easy by simply inspecting the condition type and the unhashed public key.
>>>> However it is still quite tedious to figure out the structure of a
>>>> (composed) threshold condition. Any ideas on that or am I missing something?
>>>>
>>>> Best,
>>>>
>>>> Dimi
>>>>
>>>>
>>>>
>>>> Op ma 21 mrt. 2016 om 23:16 schreef Evan Schwartz <evan@ripple.com>:
>>>>
>>>>> The instructions for turning the XML into RFC format can be found
>>>>> here:
>>>>> https://github.com/interledger/five-bells-condition/blob/master/docs/build.md
>>>>>
>>>>> On Mon, Mar 21, 2016 at 2:56 PM, Jehan Tremback <
>>>>> jehan.tremback@gmail.com> wrote:
>>>>>
>>>>>> What's the best way to view this new XML spec format?
>>>>>>
>>>>>> On Mon, Mar 21, 2016 at 12:55 PM, zaki@manian.org <zaki@manian.org>
>>>>>> wrote:
>>>>>>
>>>>>>> I'm somewhat comfortable dropping the message requirement. It
>>>>>>> definitely fits the Bitcoin norm of treating pubkeys as single use tokens.
>>>>>>>
>>>>>>> Definitely simplifies everything from a 1.0 perspective. Doesn't
>>>>>>> signficantly interfere with Skuchain's use case for generating ILP
>>>>>>> fulfillments from contract signatures.
>>>>>>>
>>>>>>> Should we document our discussion of governing the key value pairs
>>>>>>> in the message with the threshold somewhere?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Mar 21, 2016 at 3:08 PM, Evan Schwartz <evan@ripple.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Credit actually goes to Zaki for suggesting the word "composite"
>>>>>>>> when we were brainstorming succinct ways to describe this as a signature
>>>>>>>> scheme
>>>>>>>>
>>>>>>>> On Mon, Mar 21, 2016 at 12:00 PM, Stefan Thomas <stefan@ripple.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hey all,
>>>>>>>>>
>>>>>>>>> Last week, Jehan, Zaki, Evan and I met at Jehan's office to work
>>>>>>>>> on cryptoconditions, specifically the conversation turned to two things a)
>>>>>>>>> changing the scheme from a condition/fulfillment scheme to more of a
>>>>>>>>> signature scheme and b) fleshing out the multi-message functionality.
>>>>>>>>>
>>>>>>>>> After the conversation it turned out that the devil with
>>>>>>>>> multi-message is really in the details. So what I ended up doing over the
>>>>>>>>> weekend is update the spec with the change to make it act more like a
>>>>>>>>> signature scheme. This turned out to be a *hugely* simplifying change and
>>>>>>>>> I'm very happy with it, nice work Jehan, Zaki, Evan!
>>>>>>>>>
>>>>>>>>> As for adding multi-message support, I now believe that it should
>>>>>>>>> be out-of-scope for v1. It requires the ability to destructure objects and
>>>>>>>>> directing the right parts of the signed message to the right conditions. We
>>>>>>>>> should still work on it, but I think it's a very valid choice if we decide
>>>>>>>>> not to include it in v1. Neither Jehan's nor Five Bells use cases require
>>>>>>>>> it as a feature and it can be easily added in the future by adding a new
>>>>>>>>> condition type to do the destructuring.
>>>>>>>>>
>>>>>>>>> Note that we may also change the name of the scheme: Evan
>>>>>>>>> suggested "Composite Signatures" - which is the front-runner so far. But I
>>>>>>>>> didn't want to make a ton of nomenclature changes until we've all agreed on
>>>>>>>>> a new set of terminology.
>>>>>>>>>
>>>>>>>>> Here's the PR - all of the changes and rationale are described
>>>>>>>>> therein:
>>>>>>>>>
>>>>>>>>> https://github.com/interledger/five-bells-condition/pull/14
>>>>>>>>>
>>>>>>>>> - Stefan
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Evan Schwartz | Software Architect | Ripple
>>>>>>>> [image: ripple.com] <http://ripple.com>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Evan Schwartz | Software Architect | Ripple
>>>>> [image: ripple.com] <http://ripple.com>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Evan Schwartz | Software Architect | Ripple
>>> [image: ripple.com] <http://ripple.com>
>>>
>>
>


-- 
Evan Schwartz | Software Architect | Ripple
[image: ripple.com] <http://ripple.com>