Re: Blockchain community- today's minutes

inspired by this excellent blog -  we should try measuring usecases we list
against criteria.

https://www.multichain.com/blog/2015/11/avoiding-pointless-blockchain-project/

regards / groetjes / adios  / gruesse

Benedikt Herudek

On 19 July 2017 at 11:08, benedikt herudek <benedikt.herudek@gmail.com>
wrote:

> Hi,
>
> I would suggest next to a taxonomy to try to formulate decision criteria,
> when Blockchains are a good idea. With the amount of marketing and hype
> 'cutting through' could be a useful contribution.
>
> Not an easy task, below my stab at it - also in the (outdated?) google doc.
>
> regards
>
> Benedikt
>
>
> List of criteria for using Blockchains
>
> The following list of criteria shall help to decide, if the use case is
> suitable for a (shared) database or blockchains:
>
>
>    1.
>
>    Are there different entities (persons, departments, corporations,
>    authorities) which have their own versions of facts in separate means
>    of recording like databases?
>
> Counter example: You write a diary with your own highly and highly
> confidential view
>
>    1.
>
>    Do you need one common version of the truth, e.g. a shared database,
>    into which several entities read and write to work efficiently ?
>
> Counter example: You work in a conglomerate in different geographies with
> highly
>
> separate business units. Coordinating for finance reporting via
>
> conventional exchange of aggregated data is sufficiently efficient
>
>    1.
>
>    Is there potential for meaningful and consequence bearing dispute
>    between these entities about what the ‘truth’ (status of the database) of
>    this shared database could be ?
>
> Counter example: You work in a conglomerate in different geographies with
> highly
>
> separated business units. Coordinating for finance reporting can be
>
> done via conventional exchange of aggregated data
>
>    1.
>
>    Is engaging a trusted intermediary to settle disputes not feasible for
>    e.g. economic reason or lack of such trusted middlemen ?
>
> Counter example: You are working in an environment, where trust in
> goverment or
>
> organisations like banks is low due to corruption or lack of resources
>
> of those intermediaries and costs might be higher than benefit.
>
>    1.
>
>    Instead of appointing one trusted intermediary are you able to
>    describe a set of entities and consensus based and automated process
>    to come to a conclusion which transactions will be allowed to be recorded
>    into the central blockchain?
>
> Counter example: You have a very small set of collaborators the majority
> of which you
>
> either do not trust or do not have a proper internal reporting or
>
> technological means to participate in such an automated process
>
>    1.
>
>    Can you set up a governance to follow up or enforce implications of
>    the consensus status of the Blockchains.
>
> Counter example: You set up a Blockchain Consortium between vendors &
> suppliers of
>
> natural resources but the homestates of major players in the
>
> consortium do not have legal nor economic agreements with your
>
> jurisdiction
>
> If any of these criteria are not fulfilled, a Blockchain might not be the
> right Design.
>
> A connected ‘softer’ criteria is linked to your design of transactions and
> the Blockchain.
>
>    1.
>
>    Can you describe simple, e.g. time-bound material relations between
>    transactions which can be reflected in the ordering and linking of
>    transactions
>
> Counter example: You setup an identity registry, where profiles are
> recorded separate of
>
> each other, e.g. a mother of a son could be recorded after her son and
>
> there is no link between the two
>
>
> regards / groetjes / adios  / gruesse
>
> Benedikt Herudek
>
> On 12 July 2017 at 17:24, Colleen Kirtland <cskirtland@yahoo.com> wrote:
>
>> Thanks to those who joined!
>> The only action item out of today's meeting is that Michael Palage and I
>> will continue to work offline to move the needle forward on the online
>> Blockchain Use Case taxonomy.  Michael will be leading the vetting of our
>> current taxonomy to ensure that terminology is standardized.
>>
>> We will keep the team updated.
>>
>> The next US based call is in 2 weeks.
>>
>
>