- From: <zaki@manian.org>
- Date: Mon, 21 Mar 2016 19:36:56 -0400
- To: Dimitri De Jonghe <dimi@ascribe.io>
- Cc: Evan Schwartz <evan@ripple.com>, Jehan Tremback <jehan.tremback@gmail.com>, Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAJQ8TmCaQaHCJ+-AwEyJjPy171f5KiiffwWVD4=o1SogXevgnw@mail.gmail.com>
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