Re: Crypto-condition Update

We've also put aside a bunch of structure. In the earlier concept, messages
had an inherent key value structure that was available to the ledger or
ignored by it.

Now any structure to the message and parsing is at potentially a higher
protocol level.

I think is a good and desirable simplification and it really read like a
composite signature scheme.


On Mon, Mar 21, 2016 at 9:09 PM, Stefan Thomas <stefan@ripple.com> wrote:

> > I'm somewhat comfortable dropping the message requirement. It
> definitely fits the Bitcoin norm of treating pubkeys as single use tokens.
>
> Just to be clear here. We are dropping the ability to have *multiple*
> messages. The ability to have one message is very much part of the spec and
> as you can see isn't adding much complexity to it. I'll add some more
> explanation on how the message will work.
>
> In general, we should add more explanations throughout the spec, but it
> seemed like a good idea to get the binary format more settled first,
> because we don't want to write a bunch of prose we'll have to immediately
> rewrite.
>
> On Mon, Mar 21, 2016 at 4:45 PM, Evan Schwartz <evan@ripple.com> wrote:
>
>> 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>
>>
>
>