Re: Crypto-condition Update

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