1. Topics
  2. Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

Andreas Freund <andreas.freund@...>
 

Hi Oskar, see my comments below, marked with AF. Apologies for the delay. Work.

Have a great  weekend.

Cheers,
Andreas

Dear Andreas Freund,

Thank you for your comment below, which I have received via Google Docs. As noted in my response to you in the Google Doc, the place to discuss fundamental requirements issues is at the Hyperledger RequirementsWG mailing list (this list).

I believe that your comment is missing the essence of my document.


 *   That opens the door to collusion of all sorts
A qualified majority of validators can always collude (cf. Ethereum+DAO). An essence of blockchain is that they cannot collude covertly.
AF: Of course validators can collude covertly, that is exactly the game theoretic problem that Casper is tackling. That is a hard problem.

But coming back to requirements. To start with I would suggest that underlying assumptions such as "law abiding consortium" are validated. I would prefer the assumption that at any moment there is a malicious set of participants in a consortium which will try to either censor or subvert decisions. Given what we know about human behavior, this is a sensible assumption. Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Hence, there are several requirements IMHO that are spawned from the above threat based assumption. Assumption is that we are talking about a Blockchain ecosystem:
  1. External claims such as a court order have to be validated by a randomly chosen set of validators. Where randomly refers to a randomized selection process that is performed in the blind
  2. Only Blockchain identities can become validators
  3. The status of validator is obtained through a collusion resistant, privacy preserving process
  4. Validators are incentivized to make themselves available to validate an external claim
  5. Validators are rewarded for validating an external claim truthfully to the best of their ability
  6. Validators are censored for not reporting on external claims truthfully
  7. An external claim is found to be validated if a p-majority of validators decides that an external claim is valid within the predetermined timeframe
  8. The result of any validation has to be broadcast to all Blockchain identities
  9. The validity of a validated external claim can be challenged by a Blockchain identity by posting a challenge bond of meaningful size for the claimant within a certain time period of an external claim being validated.
  10. In the case of a challenge, a new, randomly chosen set of validators is assigned and validates the external claim. If the challenge is resolved in favor of the challenger, the rewards of the incorrectly reporting majority are given to the challenger. If the challenge is resolved against the claimant, the challenge bond is lost and paid out to the truthfully reporting validators
  11. An outcome of a validation can be challenged more than once
  12. The reassigning ownership of a Blockchain asset be it either fully digital or representing an analog asset has to follow the process requirements #1 - #11. A digital asset can be anything from a token to a smart contract code

     *   running a Blockchain platform does not mean you should know who controls smart contracts.
    My document is not about identity not does it make assumptions about the implementation. It is a set of requirements for a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction. I believe that the formulated requirements are fair, even if your hypothetical current implementation cannot comply to them.

    AF: See above and "a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction" has implicit assumptions in it that are not defined anywhere. For example, what is enterprise grade? Why even refer to that, I do not think that this is necessary? What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China? Just to show the implicit complexity of potential requests.

    Generally speaking, Blockchain consortium members should not know who owns/controls assets e.g. smart contracts on the consortium platform as long as applicable regulatory requirements can be fulfilled. I would formulate that as a requirement.

     *   validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside.
    The Hyperledger RequirementsWG is about requirements, not about implementations that can or cannot comply to the requirement.

    AF: Then let me formulate this as a requirement. Blockchain network nodes should not be accessible by anyone or anything after deployment, except for Blockchain identities to submit transactions/blocks. Note Blockchain identities could be also other nodes. Furthermore, all node processes must remain hidden and inaccessible to anyone or anything from the outside. Lastly, node processes have to be structured in such a way that they cannot influence one another unless it is part of the Blockchain protocol design.

     *   What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities
    One cannot “after-the-fact” retrofit an existing and validated smart contract with m-of-n multisig, nor does my proposed set of requirements require this. Your solution can be used to addresses the “lost keys” problem, which is not what my document is about.

    AF: First, of course, you can, if you use a smart contract system, secondly, you must be able to update smart contract systems to delete, add or change functionality such as m-of-n multi sig. Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

    Please let me know if I am missing something.

    Best regards,

    Oskar


From: Andreas Freund (Google Docs) [mailto:d+MTA5ODc1OTgwNjAwMDc1MTUwNjY3-MTAzNTMzNjc5Njk5NDU1ODU5NTU0 at docs.google.com]
Sent: Tuesday, 18 July, 2017 23:39
To: Deventer, M.O. (Oskar) van <oskar.vandeventer at tno.nl>
Subject: Hyperledger - Aft... - That opens the door to collusion of a...

Andreas Freund added a comment to Hyperledger - After-the-fact mandate changes<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>
[Andreas Freund]

Andreas Freund
A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”).

That opens the door to collusion of all sorts ... running a Blockchain platform does not mean you should know who controls smart contracts. In fact, validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside. What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities

Open<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&usp=comment_email_discussion&ts=596e7ff5>










Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

You have received this email because you are subscribed to all discussions on Hyperledger - After-the-fact mandate changes<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>.Change what Google Docs sends you.<https://docs.google.com/document/docos/notify?id=1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo&title=Hyperledger+-+After-the-fact+mandate+changes>You can reply to this email to reply to the discussion.


[cid:image001.png at 01D30078.4F641170]


Best Regards
Dr. Andreas Freund
Senior Manager, Global Consulting Practice - NextGen Strategy Practice & Blockchain Advisory
Tata Consultancy Services Limited
Ph:- +1-858-699-7022
Cell:- +1-858-699-7022
Mailto: andreas.freund@...
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________



From:        hyperledger-requirements-wg-request@...
To:        hyperledger-requirements-wg@...
Date:        07/20/2017 08:35 AM
Subject:        Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
Sent by:        hyperledger-requirements-wg-bounces@...



Send Hyperledger-Requirements-WG mailing list submissions to
                hyperledger-requirements-wg@...

To subscribe or unsubscribe via the World Wide Web, visit
                https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg

or, via email, send a message with subject or body 'help' to
                hyperledger-requirements-wg-request@...

You can reach the person managing the list at
                hyperledger-requirements-wg-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hyperledger-Requirements-WG digest..."


Today's Topics:

  1. Re: FW: Document "After-the-fact mandate changes" ready for
     external review (Deventer, M.O. (Oskar) van)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Jul 2017 15:35:12 +0000
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...>
To: Mark Parzygnat <markparz@...>
Cc: "hyperledger-requirements-wg@..."
                <hyperledger-requirements-wg@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document
                "After-the-fact mandate changes" ready for external review
Message-ID:
                <BA5A0ED6E909E749AD5CB0D3750A6D2A221E659D@...>
Content-Type: text/plain; charset="utf-8"

Hi Mark,


 *   The main question I am asking is there a project that doesn't currently handle these scenarios?
This question can only be answered based on well formulated requirements. The RequirementsWG has worked on these for the last two months. Initial feedback suggests that there are Hyperledger projects that do not support this set of requirements. Moreover, the support may be difficult for some of them without major architectural changes.


 *   figure out what features are currently missing
The purpose of the RequirementsWG is to figure out what features are needed.
(The fact that a feature is missing does not imply that there is a market need, more likely the opposite.)


 *   UIs for each of the platform projects, interoperability aspects that could be used from one project into another
So we should spell out the associated use case and requirements, correct?
(By the way, I am particularly interested in inter-project use cases and requirements.)

Best regards,

Oskar

From: Mark Parzygnat [mailto:markparz@...]
Sent: Thursday, 20 July, 2017 16:30
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Cc: hyperledger-requirements-wg@...
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review


Hi Oskar,

Thanks. It's probably just my misunderstanding, so apologies for asking what maybe be silly questions. This particular document looks to be about access controls, after initial deployments. Broken down nicely in several different scenarios. The main question I am asking is there a project that doesn't currently handle these scenarios? Iroha, Sawtooth, and Fabric seem to handle these scenarios from what I can tell. I'm wondering is this a document for new projects to verify they fulfill these use cases, or is there a specific project or area that currently needs these requirements?

IMO, it would be a huge benefit for all of us in the requirements WG to look across the projects and figure out what features are currently missing in the projects that should be implemented. For instance, nice UIs for each of the platform projects, interoperability aspects that could be used from one project into another, or specific project needs based on what people are looking for like Fabric needs a JS chaincode, etc. I know it's a big task, but I think worth the investment.

Hope I'm making sense.

Regards,
Mark





[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in]"Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in collaboration with several others. It is likely to becom

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: Mark Parzygnat <markparz@...<mailto:markparz@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/20/2017 09:21 AM
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

________________________________



Hi Mark,

De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.

    *   Hyperledger Fabric has all these controls in place via channels. In order to be able ?
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.

Does this make sense?

Best regards,

Oskar

Dr. ir. M.O. (Oskar) van Deventer
Senior Scientist Blockchain Networking
Dept. Networks

T +31 (0)88 866 70 78
M +31 (0)65 191 49 18
E oskar.vandeventer@...<mailto:oskar.vandeventer@...>

Location<http://www.tno.nl/locaties/DHA>

[]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.






From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Cc: Boulton, Clive <clive.boulton@...<mailto:clive.boulton@...>>; hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>; hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

Hi Everyone,

Apologies I've not been able to attend the req-wg meetings as I have conflicts with the timing. However looking this over, I would like to know a bit more about this particular document. Is this to gather input on how this currently works project by project? Hyperledger Fabric has all these controls in place via channels. In order to be able to instantiate the chaincode(smart contract) you have to have the authorization, which also means you have ownership since it's installed on your file system.

Regards,
Mark


[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact]"Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact mandate changes" was discussed in detail in the Hyperled

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: "Boulton, Clive" <clive.boulton@...<mailto:clive.boulton@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/18/2017 05:35 AM
Subject: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Sent by: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>

________________________________




Hi Clive, all,

The document ?After-the-fact mandate changes? was discussed in detail in the Hyperledger Identity working group. There were ten participants, including a person from Hyperledger Indy. There were some discussions about solution directions and potential implementation issues. The general feedback was that the document was well written and clear. No further changes were made.
Let us now formally close the document, that is, PDF it, add it to the Wiki list, and formally share it with the Architecture and Identity working groups. OK?
Best regards,
Oskar

________________________________
From: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...> <hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Sent: Wednesday, July 5, 2017 12:57 AM
To: Boulton, Clive
Cc: hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>
Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review

Hi Clive, all,

I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.

Requirement 1: A user (?anchor?) shall be able to sign over its authorization over a smart contract to another user (?guardian?) after the fact.

1a: The original user (?anchor?) loses its authorization over the smart contract.

1b: The original user (?anchor?) maintains its authorization over the smart contract.

Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (?anchor?) to another user (?guardian?).

Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (?anchor?) to another user (?guardian?) in a single action.

Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (?anchor?) user.

Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys.

Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain.

Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction.

Requirement 8: The solution to requirements 1-4 may be programmable.

Following your suggestion, I shall share the document also with hyperledger-arch-wg@...<mailto:hyperledger-arch-wg@...> and hyperledger-identity-wg@...<mailto:hyperledger-identity-wg@...>.

As always, reviews, comments and suggestions remain very welcome!

Best regards,

Oskar

From: Deventer, M.O. (Oskar) van
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...<mailto:aaron.b.benningfield@...>>
Cc: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

          *   My comments did not make it in Oskar's Document for what ever reason
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.

          *   What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go.
I am not sure how your comment relates to the subject of my document. My document is about ?after-the-fact mandate changes?. Here either the authorized user (?anchor?) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (?guardian?).

Oskar

From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,

________________________________

From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Sent: Monday, July 3, 2017 3:41:25 PM
To: Aaron Benningfield
Cc: Deventer, M.O. (Oskar) van
Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

Do you know any mandated cases?

What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.

Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.

-Clive.

---------- Forwarded message ----------
From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>

The minutes from [last] Monday's Requirements Working Group bi-weekly are here:

https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017

Domain experts please review the use case:

?After-the-fact mandate changes?<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit>

Our next meeting July 10 - 1pm EST / 10am PST

-Clive

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...<mailto:Hyperledger-Requirements-WG@...>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2396 bytes
Desc: image002.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.png>

------------------------------

_______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


End of Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
**********************************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
 

Dear Andreas,

 

Thank you for your detailed analysis, which is highly appreciated!

 

  • Assumption is that we are talking about a Blockchain ecosystem:
  • 1 … 12

Many of your bullets seem to be requirements for a solution to be qualified as “blockchain”. If these requirements have not yet been formally documented by the Hyperledger RequirementsWG, then I hope that they will be in due process. Some of your bullets (e.g. “An external claim is found to be validated if a p-majority of validators… ”) seem to describe a technical solution. I’d love to discuss these with you and get a better understanding of the concept that you are describing. The HyperledgerArchitectureWG may be a good place for that.

 

However,

  • How do your points relate to my set of requirements?
  • What do they mean in terms of work to be done, either in the RequirementsWG or elsewhere?

 

  • underlying assumptions such as "law abiding consortium" are validated.

That is a fair point. I have started a document about functional roles in a Hyperledger blockchain, see https://docs.google.com/document/d/1CIMzpsCYNyFuJ_IgJhrsIY-ZxEk23w-pf8sQ2d79ASc. In the functional model, the service layer hosts consortium(s) of blockchain service providers (“validators”). The document did not get much traction in the RequirementsWG, so I have abandoned it for now.

 

Within the Netherlands, a consortium of disparate Dutch companies (“Techruption”, with banks, telco’s, universities, start-ups, government branches, …) is now working on the “Techruption Consortium Blockchain”. “Consortium Blockchain” (a.k.a. permissioned blockchain) is the experimental blockchain that will be run by the partners. So this is a Dutch Consortium running nodes in The Netherlands for Dutch users under Dutch law. The use cases from my “after-the-fact” document came up at a consortium meeting.

 

  • what is enterprise grade?

This is blockchain network and technology that a major enterprise would rely on for core business processes. This currently disqualifies the highly volatile and unclearly governed public Bitcoin and public Ethereum blockchains. Our conjecture is that a consortium of disparate companies may create a blockchain that enterprises and government can rely on not to be colluding.

 

  • What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China?

As JFK said, “we are not doing this because it is easy”. As Google has learned in China and Europe, multinational organisations are not above the law. The same is true for multinational consortia. My document is not a legal treatise. It is formulating a set of requirements that a law-abiding blockchain consortium would want to be able to satisfy.

 

  • Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

Are you saying that all the Hyperledger projects satisfy my set of eight requirements already? If that is correct, then our work is done. However, based on feedback from others I am not sure whether this is indeed the case.

 

  • Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Let us discuss that over beer some time.

 

Thank you again, and looking forward to the continuation of this discussion. I shall participate in the RequirementsWG call of this Monday 24 July.

 

Best regards,

 

Oskar

 

 

From: Andreas Freund [mailto:andreas.freund@...]
Sent: Saturday, 22 July, 2017 01:20
To: hyperledger-requirements-wg@...; Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Subject: Re: Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

 

Hi Oskar, see my comments below, marked with AF. Apologies for the delay. Work.

Have a great  weekend.

Cheers,
Andreas

Dear Andreas Freund,

Thank you for your comment below, which I have received via Google Docs. As noted in my response to you in the Google Doc, the place to discuss fundamental requirements issues is at the Hyperledger RequirementsWG mailing list (this list).

I believe that your comment is missing the essence of my document.


 *   That opens the door to collusion of all sorts
A qualified majority of validators can always collude (cf. Ethereum+DAO). An essence of blockchain is that they cannot collude covertly.

AF: Of course validators can collude covertly, that is exactly the game theoretic problem that Casper is tackling. That is a hard problem.

But coming back to requirements. To start with I would suggest that underlying assumptions such as "law abiding consortium" are validated. I would prefer the assumption that at any moment there is a malicious set of participants in a consortium which will try to either censor or subvert decisions. Given what we know about human behavior, this is a sensible assumption. Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Hence, there are several requirements IMHO that are spawned from the above threat based assumption. Assumption is that we are talking about a Blockchain ecosystem:

  1. External claims such as a court order have to be validated by a randomly chosen set of validators. Where randomly refers to a randomized selection process that is performed in the blind
  1. Only Blockchain identities can become validators
  1. The status of validator is obtained through a collusion resistant, privacy preserving process
  1. Validators are incentivized to make themselves available to validate an external claim
  1. Validators are rewarded for validating an external claim truthfully to the best of their ability
  1. Validators are censored for not reporting on external claims truthfully
  1. An external claim is found to be validated if a p-majority of validators decides that an external claim is valid within the predetermined timeframe
  1. The result of any validation has to be broadcast to all Blockchain identities
  1. The validity of a validated external claim can be challenged by a Blockchain identity by posting a challenge bond of meaningful size for the claimant within a certain time period of an external claim being validated.
  1. In the case of a challenge, a new, randomly chosen set of validators is assigned and validates the external claim. If the challenge is resolved in favor of the challenger, the rewards of the incorrectly reporting majority are given to the challenger. If the challenge is resolved against the claimant, the challenge bond is lost and paid out to the truthfully reporting validators
  1. An outcome of a validation can be challenged more than once
  1. The reassigning ownership of a Blockchain asset be it either fully digital or representing an analog asset has to follow the process requirements #1 - #11. A digital asset can be anything from a token to a smart contract code

     *   running a Blockchain platform does not mean you should know who controls smart contracts.
    My document is not about identity not does it make assumptions about the implementation. It is a set of requirements for a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction. I believe that the formulated requirements are fair, even if your hypothetical current implementation cannot comply to them.

    AF: See above and "a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction" has implicit assumptions in it that are not defined anywhere. For example, what is enterprise grade? Why even refer to that, I do not think that this is necessary? What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China? Just to show the implicit complexity of potential requests.

    Generally speaking, Blockchain consortium members should not know who owns/controls assets e.g. smart contracts on the consortium platform as long as applicable regulatory requirements can be fulfilled. I would formulate that as a requirement.

     *   validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside.
    The Hyperledger RequirementsWG is about requirements, not about implementations that can or cannot comply to the requirement.

    AF: Then let me formulate this as a requirement. Blockchain network nodes should not be accessible by anyone or anything after deployment, except for Blockchain identities to submit transactions/blocks. Note Blockchain identities could be also other nodes. Furthermore, all node processes must remain hidden and inaccessible to anyone or anything from the outside. Lastly, node processes have to be structured in such a way that they cannot influence one another unless it is part of the Blockchain protocol design.

     *   What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities
    One cannot “after-the-fact” retrofit an existing and validated smart contract with m-of-n multisig, nor does my proposed set of requirements require this. Your solution can be used to addresses the “lost keys” problem, which is not what my document is about.

    AF: First, of course, you can, if you use a smart contract system, secondly, you must be able to update smart contract systems to delete, add or change functionality such as m-of-n multi sig. Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

    Please let me know if I am missing something.

    Best regards,

    Oskar


    From: Andreas Freund (Google Docs) [mailto:    d+MTA5ODc1OTgwNjAwMDc1MTUwNjY3-MTAzNTMzNjc5Njk5NDU1ODU5NTU0 at docs.google.com]
    Sent: Tuesday, 18 July, 2017 23:39
    To: Deventer, M.O. (Oskar) van <    oskar.vandeventer at tno.nl>
    Subject: Hyperledger - Aft... - That opens the door to collusion of a...

    Andreas Freund added a comment to Hyperledger - After-the-fact mandate changes<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>
    [Andreas Freund]

    Andreas Freund
    A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”).

    That opens the door to collusion of all sorts ... running a Blockchain platform does not mean you should know who controls smart contracts. In fact, validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside. What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities

    Open<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&usp=comment_email_discussion&ts=596e7ff5>










    Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

    You have received this email because you are subscribed to all discussions on Hyperledger - After-the-fact mandate changes<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>.Change what Google Docs sends you.<https://docs.google.com/document/docos/notify?id=1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo&title=Hyperledger+-+After-the-fact+mandate+changes>You can reply to this email to reply to the discussion.


    [cid:    image001.png at 01D30078.4F641170]




Best Regards
Dr. Andreas Freund
Senior Manager, Global Consulting Practice - NextGen Strategy Practice & Blockchain Advisory
Tata Consultancy Services Limited
Ph:- +1-858-699-7022
Cell:- +1-858-699-7022
Mailto: andreas.freund@...
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________




From:        hyperledger-requirements-wg-request@...
To:        hyperledger-requirements-wg@...
Date:        07/20/2017 08:35 AM
Subject:        Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
Sent by:        hyperledger-requirements-wg-bounces@...




Send Hyperledger-Requirements-WG mailing list submissions to
                hyperledger-requirements-wg@...

To subscribe or unsubscribe via the World Wide Web, visit
                https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg

or, via email, send a message with subject or body 'help' to
                hyperledger-requirements-wg-request@...

You can reach the person managing the list at
                hyperledger-requirements-wg-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hyperledger-Requirements-WG digest..."


Today's Topics:

  1. Re: FW: Document "After-the-fact mandate changes" ready for
     external review (Deventer, M.O. (Oskar) van)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Jul 2017 15:35:12 +0000
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...>
To: Mark Parzygnat <markparz@...>
Cc: "hyperledger-requirements-wg@..."
                <hyperledger-requirements-wg@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document
                "After-the-fact mandate changes" ready for external review
Message-ID:
                <BA5A0ED6E909E749AD5CB0D3750A6D2A221E659D@...>
Content-Type: text/plain; charset="utf-8"

Hi Mark,


 *   The main question I am asking is there a project that doesn't currently handle these scenarios?
This question can only be answered based on well formulated requirements. The RequirementsWG has worked on these for the last two months. Initial feedback suggests that there are Hyperledger projects that do not support this set of requirements. Moreover, the support may be difficult for some of them without major architectural changes.


 *   figure out what features are currently missing
The purpose of the RequirementsWG is to figure out what features are needed.
(The fact that a feature is missing does not imply that there is a market need, more likely the opposite.)


 *   UIs for each of the platform projects, interoperability aspects that could be used from one project into another
So we should spell out the associated use case and requirements, correct?
(By the way, I am particularly interested in inter-project use cases and requirements.)

Best regards,

Oskar

From: Mark Parzygnat [mailto:markparz@...]
Sent: Thursday, 20 July, 2017 16:30
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Cc: hyperledger-requirements-wg@...
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review


Hi Oskar,

Thanks. It's probably just my misunderstanding, so apologies for asking what maybe be silly questions. This particular document looks to be about access controls, after initial deployments. Broken down nicely in several different scenarios. The main question I am asking is there a project that doesn't currently handle these scenarios? Iroha, Sawtooth, and Fabric seem to handle these scenarios from what I can tell. I'm wondering is this a document for new projects to verify they fulfill these use cases, or is there a specific project or area that currently needs these requirements?

IMO, it would be a huge benefit for all of us in the requirements WG to look across the projects and figure out what features are currently missing in the projects that should be implemented. For instance, nice UIs for each of the platform projects, interoperability aspects that could be used from one project into another, or specific project needs based on what people are looking for like Fabric needs a JS chaincode, etc. I know it's a big task, but I think worth the investment.

Hope I'm making sense.

Regards,
Mark





[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in]"Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in collaboration with several others. It is likely to becom

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: Mark Parzygnat <markparz@...<mailto:markparz@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/20/2017 09:21 AM
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

________________________________



Hi Mark,

De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.

    *   Hyperledger Fabric has all these controls in place via channels. In order to be able ?
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.

Does this make sense?

Best regards,

Oskar

Dr. ir. M.O. (Oskar) van Deventer
Senior Scientist Blockchain Networking
Dept. Networks

T +31 (0)88 866 70 78
M +31 (0)65 191 49 18
E oskar.vandeventer@...<mailto:oskar.vandeventer@...>

Location<http://www.tno.nl/locaties/DHA>

[]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.






From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Cc: Boulton, Clive <clive.boulton@...<mailto:clive.boulton@...>>; hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>; hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

Hi Everyone,

Apologies I've not been able to attend the req-wg meetings as I have conflicts with the timing. However looking this over, I would like to know a bit more about this particular document. Is this to gather input on how this currently works project by project? Hyperledger Fabric has all these controls in place via channels. In order to be able to instantiate the chaincode(smart contract) you have to have the authorization, which also means you have ownership since it's installed on your file system.

Regards,
Mark


[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact]"Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact mandate changes" was discussed in detail in the Hyperled

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: "Boulton, Clive" <clive.boulton@...<mailto:clive.boulton@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/18/2017 05:35 AM
Subject: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Sent by: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>

________________________________




Hi Clive, all,

The document ?After-the-fact mandate changes? was discussed in detail in the Hyperledger Identity working group. There were ten participants, including a person from Hyperledger Indy. There were some discussions about solution directions and potential implementation issues. The general feedback was that the document was well written and clear. No further changes were made.
Let us now formally close the document, that is, PDF it, add it to the Wiki list, and formally share it with the Architecture and Identity working groups. OK?
Best regards,
Oskar

________________________________
From: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...> <hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Sent: Wednesday, July 5, 2017 12:57 AM
To: Boulton, Clive
Cc: hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>
Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review

Hi Clive, all,

I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.

Requirement 1: A user (?anchor?) shall be able to sign over its authorization over a smart contract to another user (?guardian?) after the fact.

1a: The original user (?anchor?) loses its authorization over the smart contract.

1b: The original user (?anchor?) maintains its authorization over the smart contract.

Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (?anchor?) to another user (?guardian?).

Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (?anchor?) to another user (?guardian?) in a single action.

Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (?anchor?) user.

Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys.

Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain.

Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction.

Requirement 8: The solution to requirements 1-4 may be programmable.

Following your suggestion, I shall share the document also with hyperledger-arch-wg@...<mailto:hyperledger-arch-wg@...> and hyperledger-identity-wg@...<mailto:hyperledger-identity-wg@...>.

As always, reviews, comments and suggestions remain very welcome!

Best regards,

Oskar

From: Deventer, M.O. (Oskar) van
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...<mailto:aaron.b.benningfield@...>>
Cc: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

          *   My comments did not make it in Oskar's Document for what ever reason
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.

          *   What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go.
I am not sure how your comment relates to the subject of my document. My document is about ?after-the-fact mandate changes?. Here either the authorized user (?anchor?) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (?guardian?).

Oskar

From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,

________________________________

From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Sent: Monday, July 3, 2017 3:41:25 PM
To: Aaron Benningfield
Cc: Deventer, M.O. (Oskar) van
Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

Do you know any mandated cases?

What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.

Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.

-Clive.

---------- Forwarded message ----------
From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>

The minutes from [last] Monday's Requirements Working Group bi-weekly are here:

https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017

Domain experts please review the use case:

?After-the-fact mandate changes?<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit>

Our next meeting July 10 - 1pm EST / 10am PST

-Clive

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...<mailto:Hyperledger-Requirements-WG@...>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2396 bytes
Desc: image002.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.png>

------------------------------

_______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


End of Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
**********************************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Andreas Freund <andreas.freund@...>
 

Hi Oskar,

My requirements are in fact quite general and not necessarily predicated to a blockchain. However since were talking about block chain consortium, the qualifier is OK in my opinion.

The requirements are stated with the assumption that a consortium is not necessarily collusion free and that certain members are not always law-abiding. The requirements are a security layer that can ensure fairness in decision-making through game theoretic means.

Which brings me to your comment about the technical implementation when I mentioned P-majority. This is a mathematical term. And has nothing to do with a specific technical implementation. Happy to discuss all of these requirements further. I see these requirements as foundational building blocks for a consortium running one or more block trains for either the public or Enterprises.

To see a direct application of such requirements in an active project, I would recommend that you look at the Augur project that is currently being finalized on Ethereum. Augur is a decentralized prediction market.

I see the requirements I stated in addition to what you have written down and not in replacement of them. As well as these being more of a clarification at certain points.

I will try and see if I can join the working group call on Monday. But I might be traveling.

Cheers,


On Jul 22, 2017, at 9:11 AM, Deventer, M.O. (Oskar) van <oskar.vandeventer@...> wrote:

Dear Andreas,

 

Thank you for your detailed analysis, which is highly appreciated!

 

  • Assumption is that we are talking about a Blockchain ecosystem:
  • 1 … 12

Many of your bullets seem to be requirements for a solution to be qualified as “blockchain”. If these requirements have not yet been formally documented by the Hyperledger RequirementsWG, then I hope that they will be in due process. Some of your bullets (e.g. “An external claim is found to be validated if a p-majority of validators… ”) seem to describe a technical solution. I’d love to discuss these with you and get a better understanding of the concept that you are describing. The HyperledgerArchitectureWG may be a good place for that.

 

However,

  • How do your points relate to my set of requirements?
  • What do they mean in terms of work to be done, either in the RequirementsWG or elsewhere?

 

  • underlying assumptions such as "law abiding consortium" are validated.

That is a fair point. I have started a document about functional roles in a Hyperledger blockchain, see https://docs.google.com/document/d/1CIMzpsCYNyFuJ_IgJhrsIY-ZxEk23w-pf8sQ2d79ASc. In the functional model, the service layer hosts consortium(s) of blockchain service providers (“validators”). The document did not get much traction in the RequirementsWG, so I have abandoned it for now.

 

Within the Netherlands, a consortium of disparate Dutch companies (“Techruption”, with banks, telco’s, universities, start-ups, government branches, …) is now working on the “Techruption Consortium Blockchain”. “Consortium Blockchain” (a.k.a. permissioned blockchain) is the experimental blockchain that will be run by the partners. So this is a Dutch Consortium running nodes in The Netherlands for Dutch users under Dutch law. The use cases from my “after-the-fact” document came up at a consortium meeting.

 

  • what is enterprise grade?

This is blockchain network and technology that a major enterprise would rely on for core business processes. This currently disqualifies the highly volatile and unclearly governed public Bitcoin and public Ethereum blockchains. Our conjecture is that a consortium of disparate companies may create a blockchain that enterprises and government can rely on not to be colluding.

 

  • What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China?

As JFK said, “we are not doing this because it is easy”. As Google has learned in China and Europe, multinational organisations are not above the law. The same is true for multinational consortia. My document is not a legal treatise. It is formulating a set of requirements that a law-abiding blockchain consortium would want to be able to satisfy.

 

  • Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

Are you saying that all the Hyperledger projects satisfy my set of eight requirements already? If that is correct, then our work is done. However, based on feedback from others I am not sure whether this is indeed the case.

 

  • Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Let us discuss that over beer some time.

 

Thank you again, and looking forward to the continuation of this discussion. I shall participate in the RequirementsWG call of this Monday 24 July.

 

Best regards,

 

Oskar

 

 

From: Andreas Freund [mailto:andreas.freund@...]
Sent: Saturday, 22 July, 2017 01:20
To: hyperledger-requirements-wg@...; Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Subject: Re: Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

 

Hi Oskar, see my comments below, marked with AF. Apologies for the delay. Work.

Have a great  weekend.

Cheers,
Andreas

Dear Andreas Freund,

Thank you for your comment below, which I have received via Google Docs. As noted in my response to you in the Google Doc, the place to discuss fundamental requirements issues is at the Hyperledger RequirementsWG mailing list (this list).

I believe that your comment is missing the essence of my document.


 *   That opens the door to collusion of all sorts
A qualified majority of validators can always collude (cf. Ethereum+DAO). An essence of blockchain is that they cannot collude covertly.

AF: Of course validators can collude covertly, that is exactly the game theoretic problem that Casper is tackling. That is a hard problem.

But coming back to requirements. To start with I would suggest that underlying assumptions such as "law abiding consortium" are validated. I would prefer the assumption that at any moment there is a malicious set of participants in a consortium which will try to either censor or subvert decisions. Given what we know about human behavior, this is a sensible assumption. Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Hence, there are several requirements IMHO that are spawned from the above threat based assumption. Assumption is that we are talking about a Blockchain ecosystem:

  1. External claims such as a court order have to be validated by a randomly chosen set of validators. Where randomly refers to a randomized selection process that is performed in the blind
  1. Only Blockchain identities can become validators
  1. The status of validator is obtained through a collusion resistant, privacy preserving process
  1. Validators are incentivized to make themselves available to validate an external claim
  1. Validators are rewarded for validating an external claim truthfully to the best of their ability
  1. Validators are censored for not reporting on external claims truthfully
  1. An external claim is found to be validated if a p-majority of validators decides that an external claim is valid within the predetermined timeframe
  1. The result of any validation has to be broadcast to all Blockchain identities
  1. The validity of a validated external claim can be challenged by a Blockchain identity by posting a challenge bond of meaningful size for the claimant within a certain time period of an external claim being validated.
  1. In the case of a challenge, a new, randomly chosen set of validators is assigned and validates the external claim. If the challenge is resolved in favor of the challenger, the rewards of the incorrectly reporting majority are given to the challenger. If the challenge is resolved against the claimant, the challenge bond is lost and paid out to the truthfully reporting validators
  1. An outcome of a validation can be challenged more than once
  1. The reassigning ownership of a Blockchain asset be it either fully digital or representing an analog asset has to follow the process requirements #1 - #11. A digital asset can be anything from a token to a smart contract code

     *   running a Blockchain platform does not mean you should know who controls smart contracts.
    My document is not about identity not does it make assumptions about the implementation. It is a set of requirements for a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction. I believe that the formulated requirements are fair, even if your hypothetical current implementation cannot comply to them.

    AF: See above and "a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction" has implicit assumptions in it that are not defined anywhere. For example, what is enterprise grade? Why even refer to that, I do not think that this is necessary? What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China? Just to show the implicit complexity of potential requests.

    Generally speaking, Blockchain consortium members should not know who owns/controls assets e.g. smart contracts on the consortium platform as long as applicable regulatory requirements can be fulfilled. I would formulate that as a requirement.

     *   validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside.
    The Hyperledger RequirementsWG is about requirements, not about implementations that can or cannot comply to the requirement.

    AF: Then let me formulate this as a requirement. Blockchain network nodes should not be accessible by anyone or anything after deployment, except for Blockchain identities to submit transactions/blocks. Note Blockchain identities could be also other nodes. Furthermore, all node processes must remain hidden and inaccessible to anyone or anything from the outside. Lastly, node processes have to be structured in such a way that they cannot influence one another unless it is part of the Blockchain protocol design.

     *   What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities
    One cannot “after-the-fact” retrofit an existing and validated smart contract with m-of-n multisig, nor does my proposed set of requirements require this. Your solution can be used to addresses the “lost keys” problem, which is not what my document is about.

    AF: First, of course, you can, if you use a smart contract system, secondly, you must be able to update smart contract systems to delete, add or change functionality such as m-of-n multi sig. Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

    Please let me know if I am missing something.

    Best regards,

    Oskar


    From: Andreas Freund (Google Docs) [mailto:    d+MTA5ODc1OTgwNjAwMDc1MTUwNjY3-MTAzNTMzNjc5Njk5NDU1ODU5NTU0 at docs.google.com]
    Sent: Tuesday, 18 July, 2017 23:39
    To: Deventer, M.O. (Oskar) van <    oskar.vandeventer at tno.nl>
    Subject: Hyperledger - Aft... - That opens the door to collusion of a...

    Andreas Freund added a comment to Hyperledger - After-the-fact mandate changes<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>
    [Andreas Freund]

    Andreas Freund
    A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”).

    That opens the door to collusion of all sorts ... running a Blockchain platform does not mean you should know who controls smart contracts. In fact, validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside. What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities

    Open<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&usp=comment_email_discussion&ts=596e7ff5>










    Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

    You have received this email because you are subscribed to all discussions on Hyperledger - After-the-fact mandate changes<    https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>.Change what Google Docs sends you.<https://docs.google.com/document/docos/notify?id=1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo&title=Hyperledger+-+After-the-fact+mandate+changes>You can reply to this email to reply to the discussion.


    [cid:    image001.png at 01D30078.4F641170]




Best Regards
Dr. Andreas Freund
Senior Manager, Global Consulting Practice - NextGen Strategy Practice & Blockchain Advisory
Tata Consultancy Services Limited
Ph:- +1-858-699-7022
Cell:- +1-858-699-7022
Mailto: andreas.freund@...
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________




From:        hyperledger-requirements-wg-request@...
To:        hyperledger-requirements-wg@...
Date:        07/20/2017 08:35 AM
Subject:        Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
Sent by:        hyperledger-requirements-wg-bounces@...




Send Hyperledger-Requirements-WG mailing list submissions to
                hyperledger-requirements-wg@...

To subscribe or unsubscribe via the World Wide Web, visit
                https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg

or, via email, send a message with subject or body 'help' to
                hyperledger-requirements-wg-request@...

You can reach the person managing the list at
                hyperledger-requirements-wg-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hyperledger-Requirements-WG digest..."


Today's Topics:

  1. Re: FW: Document "After-the-fact mandate changes" ready for
     external review (Deventer, M.O. (Oskar) van)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Jul 2017 15:35:12 +0000
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...>
To: Mark Parzygnat <markparz@...>
Cc: "hyperledger-requirements-wg@..."
                <hyperledger-requirements-wg@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document
                "After-the-fact mandate changes" ready for external review
Message-ID:
                <BA5A0ED6E909E749AD5CB0D3750A6D2A221E659D@...>
Content-Type: text/plain; charset="utf-8"

Hi Mark,


 *   The main question I am asking is there a project that doesn't currently handle these scenarios?
This question can only be answered based on well formulated requirements. The RequirementsWG has worked on these for the last two months. Initial feedback suggests that there are Hyperledger projects that do not support this set of requirements. Moreover, the support may be difficult for some of them without major architectural changes.


 *   figure out what features are currently missing
The purpose of the RequirementsWG is to figure out what features are needed.
(The fact that a feature is missing does not imply that there is a market need, more likely the opposite.)


 *   UIs for each of the platform projects, interoperability aspects that could be used from one project into another
So we should spell out the associated use case and requirements, correct?
(By the way, I am particularly interested in inter-project use cases and requirements.)

Best regards,

Oskar

From: Mark Parzygnat [mailto:markparz@...]
Sent: Thursday, 20 July, 2017 16:30
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Cc: hyperledger-requirements-wg@...
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review


Hi Oskar,

Thanks. It's probably just my misunderstanding, so apologies for asking what maybe be silly questions. This particular document looks to be about access controls, after initial deployments. Broken down nicely in several different scenarios. The main question I am asking is there a project that doesn't currently handle these scenarios? Iroha, Sawtooth, and Fabric seem to handle these scenarios from what I can tell. I'm wondering is this a document for new projects to verify they fulfill these use cases, or is there a specific project or area that currently needs these requirements?

IMO, it would be a huge benefit for all of us in the requirements WG to look across the projects and figure out what features are currently missing in the projects that should be implemented. For instance, nice UIs for each of the platform projects, interoperability aspects that could be used from one project into another, or specific project needs based on what people are looking for like Fabric needs a JS chaincode, etc. I know it's a big task, but I think worth the investment.

Hope I'm making sense.

Regards,
Mark





[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in]"Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in collaboration with several others. It is likely to becom

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: Mark Parzygnat <markparz@...<mailto:markparz@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/20/2017 09:21 AM
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

________________________________



Hi Mark,

De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.

    *   Hyperledger Fabric has all these controls in place via channels. In order to be able ?
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.

Does this make sense?

Best regards,

Oskar

Dr. ir. M.O. (Oskar) van Deventer
Senior Scientist Blockchain Networking
Dept. Networks

T +31 (0)88 866 70 78
M +31 (0)65 191 49 18
E oskar.vandeventer@...<mailto:oskar.vandeventer@...>

Location<http://www.tno.nl/locaties/DHA>

[]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.






From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Cc: Boulton, Clive <clive.boulton@...<mailto:clive.boulton@...>>; hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>; hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

Hi Everyone,

Apologies I've not been able to attend the req-wg meetings as I have conflicts with the timing. However looking this over, I would like to know a bit more about this particular document. Is this to gather input on how this currently works project by project? Hyperledger Fabric has all these controls in place via channels. In order to be able to instantiate the chaincode(smart contract) you have to have the authorization, which also means you have ownership since it's installed on your file system.

Regards,
Mark


[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact]"Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact mandate changes" was discussed in detail in the Hyperled

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: "Boulton, Clive" <clive.boulton@...<mailto:clive.boulton@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/18/2017 05:35 AM
Subject: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Sent by: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>

________________________________




Hi Clive, all,

The document ?After-the-fact mandate changes? was discussed in detail in the Hyperledger Identity working group. There were ten participants, including a person from Hyperledger Indy. There were some discussions about solution directions and potential implementation issues. The general feedback was that the document was well written and clear. No further changes were made.
Let us now formally close the document, that is, PDF it, add it to the Wiki list, and formally share it with the Architecture and Identity working groups. OK?
Best regards,
Oskar

________________________________
From: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...> <hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Sent: Wednesday, July 5, 2017 12:57 AM
To: Boulton, Clive
Cc: hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>
Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review

Hi Clive, all,

I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.

Requirement 1: A user (?anchor?) shall be able to sign over its authorization over a smart contract to another user (?guardian?) after the fact.

1a: The original user (?anchor?) loses its authorization over the smart contract.

1b: The original user (?anchor?) maintains its authorization over the smart contract.

Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (?anchor?) to another user (?guardian?).

Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (?anchor?) to another user (?guardian?) in a single action.

Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (?anchor?) user.

Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys.

Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain.

Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction.

Requirement 8: The solution to requirements 1-4 may be programmable.

Following your suggestion, I shall share the document also with hyperledger-arch-wg@...<mailto:hyperledger-arch-wg@...> and hyperledger-identity-wg@...<mailto:hyperledger-identity-wg@...>.

As always, reviews, comments and suggestions remain very welcome!

Best regards,

Oskar

From: Deventer, M.O. (Oskar) van
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...<mailto:aaron.b.benningfield@...>>
Cc: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

          *   My comments did not make it in Oskar's Document for what ever reason
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.

          *   What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go.
I am not sure how your comment relates to the subject of my document. My document is about ?after-the-fact mandate changes?. Here either the authorized user (?anchor?) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (?guardian?).

Oskar

From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,

________________________________

From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Sent: Monday, July 3, 2017 3:41:25 PM
To: Aaron Benningfield
Cc: Deventer, M.O. (Oskar) van
Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

Do you know any mandated cases?

What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.

Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.

-Clive.

---------- Forwarded message ----------
From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>

The minutes from [last] Monday's Requirements Working Group bi-weekly are here:

https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017

Domain experts please review the use case:

?After-the-fact mandate changes?<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit>

Our next meeting July 10 - 1pm EST / 10am PST

-Clive

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...<mailto:Hyperledger-Requirements-WG@...>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2396 bytes
Desc: image002.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.png>

------------------------------

_______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


End of Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
**********************************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
 

Hi Andreas,

 

Thank you for further clarifying the assumptions and associated requirements. It would be great if we could properly document these in the RequirementsWG.

 

Oskar

 

 

From: Andreas Freund [mailto:andreas.freund@...]
Sent: Saturday, 22 July, 2017 20:26
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Cc: hyperledger-requirements-wg@...
Subject: Re: Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

 

Hi Oskar,

 

My requirements are in fact quite general and not necessarily predicated to a blockchain. However since were talking about block chain consortium, the qualifier is OK in my opinion.

 

The requirements are stated with the assumption that a consortium is not necessarily collusion free and that certain members are not always law-abiding. The requirements are a security layer that can ensure fairness in decision-making through game theoretic means.

Which brings me to your comment about the technical implementation when I mentioned P-majority. This is a mathematical term. And has nothing to do with a specific technical implementation. Happy to discuss all of these requirements further. I see these requirements as foundational building blocks for a consortium running one or more block trains for either the public or Enterprises.

To see a direct application of such requirements in an active project, I would recommend that you look at the Augur project that is currently being finalized on Ethereum. Augur is a decentralized prediction market.


I see the requirements I stated in addition to what you have written down and not in replacement of them. As well as these being more of a clarification at certain points.

 

I will try and see if I can join the working group call on Monday. But I might be traveling.

Cheers,



On Jul 22, 2017, at 9:11 AM, Deventer, M.O. (Oskar) van <oskar.vandeventer@...> wrote:

Dear Andreas,

 

Thank you for your detailed analysis, which is highly appreciated!

 

Ø  Assumption is that we are talking about a Blockchain ecosystem:

Ø  1 … 12

Many of your bullets seem to be requirements for a solution to be qualified as “blockchain”. If these requirements have not yet been formally documented by the Hyperledger RequirementsWG, then I hope that they will be in due process. Some of your bullets (e.g. “An external claim is found to be validated if a p-majority of validators… ”) seem to describe a technical solution. I’d love to discuss these with you and get a better understanding of the concept that you are describing. The HyperledgerArchitectureWG may be a good place for that.

 

However,

·        How do your points relate to my set of requirements?

·        What do they mean in terms of work to be done, either in the RequirementsWG or elsewhere?

 

Ø  underlying assumptions such as "law abiding consortium" are validated.

That is a fair point. I have started a document about functional roles in a Hyperledger blockchain, see https://docs.google.com/document/d/1CIMzpsCYNyFuJ_IgJhrsIY-ZxEk23w-pf8sQ2d79ASc. In the functional model, the service layer hosts consortium(s) of blockchain service providers (“validators”). The document did not get much traction in the RequirementsWG, so I have abandoned it for now.

 

Within the Netherlands, a consortium of disparate Dutch companies (“Techruption”, with banks, telco’s, universities, start-ups, government branches, …) is now working on the “Techruption Consortium Blockchain”. “Consortium Blockchain” (a.k.a. permissioned blockchain) is the experimental blockchain that will be run by the partners. So this is a Dutch Consortium running nodes in The Netherlands for Dutch users under Dutch law. The use cases from my “after-the-fact” document came up at a consortium meeting.

 

Ø  what is enterprise grade?

This is blockchain network and technology that a major enterprise would rely on for core business processes. This currently disqualifies the highly volatile and unclearly governed public Bitcoin and public Ethereum blockchains. Our conjecture is that a consortium of disparate companies may create a blockchain that enterprises and government can rely on not to be colluding.

 

Ø  What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China?

As JFK said, “we are not doing this because it is easy”. As Google has learned in China and Europe, multinational organisations are not above the law. The same is true for multinational consortia. My document is not a legal treatise. It is formulating a set of requirements that a law-abiding blockchain consortium would want to be able to satisfy.

 

Ø  Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

Are you saying that all the Hyperledger projects satisfy my set of eight requirements already? If that is correct, then our work is done. However, based on feedback from others I am not sure whether this is indeed the case.

 

Ø  Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Let us discuss that over beer some time.

 

Thank you again, and looking forward to the continuation of this discussion. I shall participate in the RequirementsWG call of this Monday 24 July.

 

Best regards,

 

Oskar

 

 

From: Andreas Freund [mailto:andreas.freund@...]
Sent: Saturday, 22 July, 2017 01:20
To: hyperledger-requirements-wg@...; Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Subject: Re: Hyperledger-Requirements-WG Digest, Vol 12, Issue 9

 

Hi Oskar, see my comments below, marked with AF. Apologies for the delay. Work.

Have a great  weekend.

Cheers,
Andreas

Dear Andreas Freund,

Thank you for your comment below, which I have received via Google Docs. As noted in my response to you in the Google Doc, the place to discuss fundamental requirements issues is at the Hyperledger RequirementsWG mailing list (this list).

I believe that your comment is missing the essence of my document.


 *   That opens the door to collusion of all sorts
A qualified majority of validators can always collude (cf. Ethereum+DAO). An essence of blockchain is that they cannot collude covertly.

AF: Of course validators can collude covertly, that is exactly the game theoretic problem that Casper is tackling. That is a hard problem.

But coming back to requirements. To start with I would suggest that underlying assumptions such as "law abiding consortium" are validated. I would prefer the assumption that at any moment there is a malicious set of participants in a consortium which will try to either censor or subvert decisions. Given what we know about human behavior, this is a sensible assumption. Besides, would you really want to trust a court order in a jurisdiction with a history of corruption? See what is happening with Poland and the EU.

Hence, there are several requirements IMHO that are spawned from the above threat based assumption. Assumption is that we are talking about a Blockchain ecosystem:

  1. External claims such as a court order have to be validated by a randomly chosen set of validators. Where randomly refers to a randomized selection process that is performed in the blind
  1. Only Blockchain identities can become validators
  1. The status of validator is obtained through a collusion resistant, privacy preserving process
  1. Validators are incentivized to make themselves available to validate an external claim
  1. Validators are rewarded for validating an external claim truthfully to the best of their ability
  1. Validators are censored for not reporting on external claims truthfully
  1. An external claim is found to be validated if a p-majority of validators decides that an external claim is valid within the predetermined timeframe
  1. The result of any validation has to be broadcast to all Blockchain identities
  1. The validity of a validated external claim can be challenged by a Blockchain identity by posting a challenge bond of meaningful size for the claimant within a certain time period of an external claim being validated.
  1. In the case of a challenge, a new, randomly chosen set of validators is assigned and validates the external claim. If the challenge is resolved in favor of the challenger, the rewards of the incorrectly reporting majority are given to the challenger. If the challenge is resolved against the claimant, the challenge bond is lost and paid out to the truthfully reporting validators
  1. An outcome of a validation can be challenged more than once
  1. The reassigning ownership of a Blockchain asset be it either fully digital or representing an analog asset has to follow the process requirements #1 - #11. A digital asset can be anything from a token to a smart contract code

     *   running a Blockchain platform does not mean you should know who controls smart contracts.
    My document is not about identity not does it make assumptions about the implementation. It is a set of requirements for a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction. I believe that the formulated requirements are fair, even if your hypothetical current implementation cannot comply to them.

    AF: See above and "a law-abiding consortium blockchain that is offering an enterprise-grade blockchain service that wants to be able to comply to a court order of their applicable jurisdiction" has implicit assumptions in it that are not defined anywhere. For example, what is enterprise grade? Why even refer to that, I do not think that this is necessary? What is an applicable jurisdiction? A court order by a US court trying to be enforced against an Argentinian national residing in China? Just to show the implicit complexity of potential requests.

    Generally speaking, Blockchain consortium members should not know who owns/controls assets e.g. smart contracts on the consortium platform as long as applicable regulatory requirements can be fulfilled. I would formulate that as a requirement.

     *   validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside.
    The Hyperledger RequirementsWG is about requirements, not about implementations that can or cannot comply to the requirement.

    AF: Then let me formulate this as a requirement. Blockchain network nodes should not be accessible by anyone or anything after deployment, except for Blockchain identities to submit transactions/blocks. Note Blockchain identities could be also other nodes. Furthermore, all node processes must remain hidden and inaccessible to anyone or anything from the outside. Lastly, node processes have to be structured in such a way that they cannot influence one another unless it is part of the Blockchain protocol design.

     *   What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities
    One cannot “after-the-fact” retrofit an existing and validated smart contract with m-of-n multisig, nor does my proposed set of requirements require this. Your solution can be used to addresses the “lost keys” problem, which is not what my document is about.

    AF: First, of course, you can, if you use a smart contract system, secondly, you must be able to update smart contract systems to delete, add or change functionality such as m-of-n multi sig. Being able to update smart contract systems has become a fundamental design requirement and principle in the ecosystem. Hence, I am truly puzzled by your statement.

    Please let me know if I am missing something.

    Best regards,

    Oskar


    From: Andreas Freund (Google Docs) [mailto:d+MTA5ODc1OTgwNjAwMDc1MTUwNjY3-MTAzNTMzNjc5Njk5NDU1ODU5NTU0 at docs.google.com]
    Sent: Tuesday, 18 July, 2017 23:39
    To: Deventer, M.O. (Oskar) van <oskar.vandeventer at tno.nl>
    Subject: Hyperledger - Aft... - That opens the door to collusion of a...

    Andreas Freund added a comment to Hyperledger - After-the-fact mandate changes<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>
    [Andreas Freund]

    Andreas Freund
    A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (“anchor”) to another user (“guardian”).

    That opens the door to collusion of all sorts ... running a Blockchain platform does not mean you should know who controls smart contracts. In fact, validators nodes provided by a consortium should be crytpographically sealed upon deployment without ability to access the node from the outside. What can be done is to have a function in a smart contract that allows reassignment based on m-of-n multisig of registered identities

    Open<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&usp=comment_email_discussion&ts=596e7ff5>










    Google Inc. 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

    You have received this email because you are subscribed to all discussions on Hyperledger - After-the-fact mandate changes<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit?disco=AAAAA_gQ6ak&ts=596e7ff5&usp=comment_email_document>.Change what Google Docs sends you.<https://docs.google.com/document/docos/notify?id=1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo&title=Hyperledger+-+After-the-fact+mandate+changes>You can reply to this email to reply to the discussion.


    [cid:image001.png at 01D30078.4F641170]




Best Regards
Dr. Andreas Freund
Senior Manager, Global Consulting Practice - NextGen Strategy Practice & Blockchain Advisory
Tata Consultancy Services Limited
Ph:- +1-858-699-7022
Cell:- +1-858-699-7022
Mailto: andreas.freund@...
Website: http://www.tcs.com
____________________________________________
Experience certainty.        IT Services
                       Business Solutions
                       Consulting
____________________________________________




From:        hyperledger-requirements-wg-request@...
To:        hyperledger-requirements-wg@...
Date:        07/20/2017 08:35 AM
Subject:        Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
Sent by:        hyperledger-requirements-wg-bounces@...




Send Hyperledger-Requirements-WG mailing list submissions to
                hyperledger-requirements-wg@...

To subscribe or unsubscribe via the World Wide Web, visit
                https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg

or, via email, send a message with subject or body 'help' to
                hyperledger-requirements-wg-request@...

You can reach the person managing the list at
                hyperledger-requirements-wg-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Hyperledger-Requirements-WG digest..."


Today's Topics:

  1. Re: FW: Document "After-the-fact mandate changes" ready for
     external review (Deventer, M.O. (Oskar) van)


----------------------------------------------------------------------

Message: 1
Date: Thu, 20 Jul 2017 15:35:12 +0000
From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...>
To: Mark Parzygnat <markparz@...>
Cc: "hyperledger-requirements-wg@..."
                <hyperledger-requirements-wg@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document
                "After-the-fact mandate changes" ready for external review
Message-ID:
                <BA5A0ED6E909E749AD5CB0D3750A6D2A221E659D@...>
Content-Type: text/plain; charset="utf-8"

Hi Mark,


 *   The main question I am asking is there a project that doesn't currently handle these scenarios?
This question can only be answered based on well formulated requirements. The RequirementsWG has worked on these for the last two months. Initial feedback suggests that there are Hyperledger projects that do not support this set of requirements. Moreover, the support may be difficult for some of them without major architectural changes.


 *   figure out what features are currently missing
The purpose of the RequirementsWG is to figure out what features are needed.
(The fact that a feature is missing does not imply that there is a market need, more likely the opposite.)


 *   UIs for each of the platform projects, interoperability aspects that could be used from one project into another
So we should spell out the associated use case and requirements, correct?
(By the way, I am particularly interested in inter-project use cases and requirements.)

Best regards,

Oskar

From: Mark Parzygnat [mailto:markparz@...]
Sent: Thursday, 20 July, 2017 16:30
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...>
Cc: hyperledger-requirements-wg@...
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review


Hi Oskar,

Thanks. It's probably just my misunderstanding, so apologies for asking what maybe be silly questions. This particular document looks to be about access controls, after initial deployments. Broken down nicely in several different scenarios. The main question I am asking is there a project that doesn't currently handle these scenarios? Iroha, Sawtooth, and Fabric seem to handle these scenarios from what I can tell. I'm wondering is this a document for new projects to verify they fulfill these use cases, or is there a specific project or area that currently needs these requirements?

IMO, it would be a huge benefit for all of us in the requirements WG to look across the projects and figure out what features are currently missing in the projects that should be implemented. For instance, nice UIs for each of the platform projects, interoperability aspects that could be used from one project into another, or specific project needs based on what people are looking for like Fabric needs a JS chaincode, etc. I know it's a big task, but I think worth the investment.

Hope I'm making sense.

Regards,
Mark





[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in]"Deventer, M.O. (Oskar) van" ---07/20/2017 09:21:14 AM---Hi Mark, De document was developed by me in collaboration with several others. It is likely to becom

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: Mark Parzygnat <markparz@...<mailto:markparz@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/20/2017 09:21 AM
Subject: RE: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

________________________________



Hi Mark,

De document was developed by me in collaboration with several others. It is likely to become an agreed document from the RequirementsWG very soon. The purpose of the document is input to IdentityWG, ArchitectureWG and (possibly indirectly) to Hyperledger projects, which includes Hyperledger Fabric.

    *   Hyperledger Fabric has all these controls in place via channels. In order to be able ?
I am not sure how I should read this statement. If Hyperledger Fabric does already intrinsically support the full set of requirements, then that is great. If not, then there is potential work for contributors to that project.

Does this make sense?

Best regards,

Oskar

Dr. ir. M.O. (Oskar) van Deventer
Senior Scientist Blockchain Networking
Dept. Networks

T +31 (0)88 866 70 78
M +31 (0)65 191 49 18
E oskar.vandeventer@...<mailto:oskar.vandeventer@...>

Location<http://www.tno.nl/locaties/DHA>

[]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.






From: Mark Parzygnat [mailto:markparz@...]
Sent: Wednesday, 19 July, 2017 19:33
To: Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Cc: Boulton, Clive <clive.boulton@...<mailto:clive.boulton@...>>; hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>; hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>
Subject: Re: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review

Hi Everyone,

Apologies I've not been able to attend the req-wg meetings as I have conflicts with the timing. However looking this over, I would like to know a bit more about this particular document. Is this to gather input on how this currently works project by project? Hyperledger Fabric has all these controls in place via channels. In order to be able to instantiate the chaincode(smart contract) you have to have the authorization, which also means you have ownership since it's installed on your file system.

Regards,
Mark


[Inactive hide details for "Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact]"Deventer, M.O. (Oskar) van" ---07/18/2017 05:35:53 AM---Hi Clive, all, The document "After-the-fact mandate changes" was discussed in detail in the Hyperled

From: "Deventer, M.O. (Oskar) van" <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
To: "Boulton, Clive" <clive.boulton@...<mailto:clive.boulton@...>>
Cc: "hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>" <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>
Date: 07/18/2017 05:35 AM
Subject: [Hyperledger-Requirements-WG] FW: Document "After-the-fact mandate changes" ready for external review
Sent by: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>

________________________________




Hi Clive, all,

The document ?After-the-fact mandate changes? was discussed in detail in the Hyperledger Identity working group. There were ten participants, including a person from Hyperledger Indy. There were some discussions about solution directions and potential implementation issues. The general feedback was that the document was well written and clear. No further changes were made.
Let us now formally close the document, that is, PDF it, add it to the Wiki list, and formally share it with the Architecture and Identity working groups. OK?
Best regards,
Oskar

________________________________
From: hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...> <hyperledger-requirements-wg-bounces@...<mailto:hyperledger-requirements-wg-bounces@...>> on behalf of Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Sent: Wednesday, July 5, 2017 12:57 AM
To: Boulton, Clive
Cc: hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>
Subject: [Hyperledger-Requirements-WG] Document "After-the-fact mandate changes" ready for external review

Hi Clive, all,

I have just updated the document "After-the-fact mandate changes" (https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo), incorporating the comments received at the 26-June RequirementsWG call. The full set of requirements now reads as follows.

Requirement 1: A user (?anchor?) shall be able to sign over its authorization over a smart contract to another user (?guardian?) after the fact.

1a: The original user (?anchor?) loses its authorization over the smart contract.

1b: The original user (?anchor?) maintains its authorization over the smart contract.

Requirement 2: A blockchain consortium shall be able to sign over the authorization over a smart contract from one user (?anchor?) to another user (?guardian?).

Requirement 3: It should be possible to re-assign the authorization over multiple or all a smart contracts for a user (?anchor?) to another user (?guardian?) in a single action.

Requirement 4: It should be possible to re-assign the authorization over a smart contract back to the original (?anchor?) user.

Requirement 5: The solution to requirements 1-4 shall not require the handing over of private keys.

Requirement 6: The solution to requirements 1-4 shall not require mutability of the blockchain.

Requirement 7: The introduction of a solution to requirements 1-4 should be backward compatible, such that they also apply to smart contracts that predate this introduction.

Requirement 8: The solution to requirements 1-4 may be programmable.

Following your suggestion, I shall share the document also with hyperledger-arch-wg@...<mailto:hyperledger-arch-wg@...> and hyperledger-identity-wg@...<mailto:hyperledger-identity-wg@...>.

As always, reviews, comments and suggestions remain very welcome!

Best regards,

Oskar

From: Deventer, M.O. (Oskar) van
Sent: Wednesday, 05 July, 2017 09:43
To: Aaron Benningfield <aaron.b.benningfield@...<mailto:aaron.b.benningfield@...>>
Cc: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Subject: RE: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

          *   My comments did not make it in Oskar's Document for what ever reason
I checked the document history of https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo, but I could not find any trace of your comments in earlier versions. Sorry about that.

          *   What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go.
I am not sure how your comment relates to the subject of my document. My document is about ?after-the-fact mandate changes?. Here either the authorized user (?anchor?) himself or the blockchain consortium (as ordered by court) turns over the authorization to another user (?guardian?).

Oskar

From: Aaron Benningfield [mailto:aaron.b.benningfield@...]
Sent: Wednesday, 05 July, 2017 02:18
To: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>; Deventer, M.O. (Oskar) van <oskar.vandeventer@...<mailto:oskar.vandeventer@...>>
Subject: Re: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

What about returns? As in merchandise you would have returned, maybe the person was going to take a flight, vacation etc. and now cannot go. My comments did not make it in Oskar's Document for what ever reason so I was going to add the aforementioned (returns) as one to think about,

________________________________

From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Sent: Monday, July 3, 2017 3:41:25 PM
To: Aaron Benningfield
Cc: Deventer, M.O. (Oskar) van
Subject: Fwd: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th

Hi Aaron,

Do you know any mandated cases?

What about a corporate bankruptcy: Assets and liabilities are often about the same. But who gets paid first is somehow always mandated.

Assuming so, how do we stop smart contracts auto paying out funds after a bankruptcy / untimely death from bank making automatic mortgage payments.

-Clive.

---------- Forwarded message ----------
From: clive boulton <clive.boulton@...<mailto:clive.boulton@...>>
Date: Mon, Jul 3, 2017 at 3:21 PM
Subject: [Hyperledger-Requirements-WG] Minutes from Monday, June 26th
To: Hyperledger Requirements <hyperledger-requirements-wg@...<mailto:hyperledger-requirements-wg@...>>

The minutes from [last] Monday's Requirements Working Group bi-weekly are here:

https://wiki.hyperledger.org/groups/requirements/requirements-wg/minutes#june_26th_2017

Domain experts please review the use case:

?After-the-fact mandate changes?<https://docs.google.com/document/d/1psJc9UWuteSzOqIG0VLIdzdlxFb9kq-Csw-dxcjPzEo/edit>

Our next meeting July 10 - 1pm EST / 10am PST

-Clive

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages._______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...<mailto:Hyperledger-Requirements-WG@...>
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: image001.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 2396 bytes
Desc: image002.gif
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 166 bytes
Desc: image004.png
URL: <http://lists.hyperledger.org/pipermail/hyperledger-requirements-wg/attachments/20170720/28626f4d/attachment.png>

------------------------------

_______________________________________________
Hyperledger-Requirements-WG mailing list
Hyperledger-Requirements-WG@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-requirements-wg


End of Hyperledger-Requirements-WG Digest, Vol 12, Issue 9
**********************************************************

=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
1 - 4 of 4