- From: Evan Schwartz <evan@ripple.com>
- Date: Mon, 21 Mar 2016 15:14:24 -0700
- To: Jehan Tremback <jehan.tremback@gmail.com>
- Cc: "zaki@manian.org" <zaki@manian.org>, Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAONA2jWvBgAu4jwJZ9geVkT7oNXYgzJq5MkP1=SpdW2MVZNn9w@mail.gmail.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>
Received on Monday, 21 March 2016 22:15:14 UTC