Re: Crypto-condition Update

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>