Re: Crypto-condition Update

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