Re: Crypto-condition Update

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

Received on Monday, 21 March 2016 23:37:44 UTC