Re: Crypto-condition Update

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