Re: Crypto-condition Update

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>
>

Received on Monday, 21 March 2016 23:35:49 UTC