Date   

[Hyperledger Project TSC] agenda items?

Christopher B Ferris <chrisfer@...>
 

Does anyone have agenda items for tomorrow's call?


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402


Re: [Hyperledger Project TSC] new github org

Christopher B Ferris <chrisfer@...>
 

Right, please share your github ID with Mike Dolan. Also, I would guess Eric would be handling Blockstream's contribution? 
Eric, please share your github id with Mike as well, thanks.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Tamas Blummer <tamas@...>
To: Christopher B Ferris/Waltham/IBM@IBMUS
Cc: hyperledger-tsc <hyperledger-tsc@...>
Subject: Re: [Hyperledger Project TSC] new github org
Date: Wed, Mar 2, 2016 10:59 AM
 
Hi Chris,
 
Thanks, I will push our candidate as soon as I have access.
In addition we should fork Blockstream's for parts of the chain code DSL implementation.
 
Tamas Blummer
Chief Ledger Architect

 
On 02 Mar 2016, at 09:54, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:
 
Mike has created an incubator github org [1] for purposes of driving the experiment we agreed on last week's TSC call.

Binh (IBM) and Tamas (DAH) should create repos under the hyperledger-incubator org for their respective code bases and we can begin work on the proposal [1]

[1] https://github.com/hyperledger-incubator
[2] https://docs.google.com/document/d/1XV6U3kgZ31vZOz2nBLGe3vJgoLTnmOwv5qf3wo4lI68/edit

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
 


Re: [Hyperledger Project TSC] new github org

Tamas Blummer <tamas@...>
 

Hi Chris,

Thanks, I will push our candidate as soon as I have access.
In addition we should fork Blockstream's for parts of the chain code DSL implementation.

Tamas Blummer
Chief Ledger Architect


On 02 Mar 2016, at 09:54, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:

Mike has created an incubator github org [1] for purposes of driving the experiment we agreed on last week's TSC call.

Binh (IBM) and Tamas (DAH) should create repos under the hyperledger-incubator org for their respective code bases and we can begin work on the proposal [1]

[1] https://github.com/hyperledger-incubator
[2] https://docs.google.com/document/d/1XV6U3kgZ31vZOz2nBLGe3vJgoLTnmOwv5qf3wo4lI68/edit

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


[Hyperledger Project TSC] new github org

Christopher B Ferris <chrisfer@...>
 

Mike has created an incubator github org [1] for purposes of driving the experiment we agreed on last week's TSC call.

Binh (IBM) and Tamas (DAH) should create repos under the hyperledger-incubator org for their respective code bases and we can begin work on the proposal [1]

[1] https://github.com/hyperledger-incubator
[2] https://docs.google.com/document/d/1XV6U3kgZ31vZOz2nBLGe3vJgoLTnmOwv5qf3wo4lI68/edit

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402


[Hyperledger Project TSC] Project proposal template draft

Vipin Bharathan
 

https://github.com/hyperledger/hyperledger/wiki/Proposals, I have added a link to draft 0.2 which can be commented on. I have added changes based on feedback from tsc meetings and list communication.

Expecting feedback from tsc members. Also, it would be good for current IBM/DAH proposal for DAH merger to follow this template if possible.

Regards,
Vipin


[Hyperledger Project TSC] Minutes 02.25.16

Todd Benzies <tbenzies@...>
 

[note: minutes and recordings will now also be posted at https://github.com/hyperledger/hyperledger/wiki/Technical-Steering-Committee]


Hyperledger Project

Technical Steering Committee (TSC) Meeting

February 25, 2016 (7:00am - 8:30am PT)

via GoToMeeting


TSC Members

Emmanuel Viale

Accenture

Yes

Stan Liberman

CME Group

Yes

Tamas Blummer

DAH

Yes

Stefan Teis

Deutsche Boerse Group

Yes

Pardha Vishnumolakala

DTCC

Yes

Kei Taniuchi

Fujitsu

Yes

Satoshi Oshima

Hitachi


Chris Ferris

IBM

Yes

Mic Bowman

Intel

Yes

David Voell

J.P. Morgan

Yes

Richard G. Brown

R3

Yes


Resources:


Agenda:

  • Welcoming Chris Ferris as TSC Chair

  • DAH/IBM Proposal


TSC Chair

  • The election for the TSC Chair has concluded -- Chris Ferris has been elected as the TSC Chair


DAH/IBM Proposal


  • Digital Assets-IBM joint proposal for initial starting point.

  • Binh provided an overview of the DAH/IBM Joint Project Proposal

  • Tamas noted that the 2 individual proposals have different origins

    • DAH - experience with bitcoin network (deploy apps in financial services domain, more limited set of functionality).  This is sufficient for most of DAH’s use cases.

    • IBM - rethink with benefit of how this network unlocks further possibilities (more flexible framework)

  • Questions/Comments?

    • Richard:  What is the argument for why we should be trying to bring these 2 code bases together?  They seem to be designed to solve different problems and optimized for different scenarios -- are there use cases that require both?

      • Shaul -- Code bases are very complimentary.  Flexible framework with composable architecture.

      • Getting first instantiation of a network up.  Not the last… but just a start.  Will allow this code to be useable in the near future.  The merge allows the start of a discussion.

    • Kelly:   How are malicious docker images are dealt with?

      • Binh -- talked with Docker about this at IBM Interconnect… current version of docker has capabilities to shut down all activities from container to host system.  Should be no problem with sandboxing code to run in container.

    • David:  Recognize the strength of smart contracts (security guarantees).  But, also believe it is important to get something going this year to be demonstrated.  Do DAH/IBM have a timeframe for conversion?  What kind of framework?

      • Tamas -- we should organize a hackathon to speed up convergence.  Do not want to define with a time point.

      • Binh -- clarify that base of OBC code is there to support smart contracts.  People can still write this in golang, Java, and node.js.  Smart contract is there, UTXO model is there.

    • Kelly:  If the goal is to merge the security and “battle-testedness” of Bitcoin and the UTXO model, why go with DAH instead of Blockstream, which is the core codebase for Bitcoin?

      • Tamas -- DAH has an integration with Blockstream code.  Combination of enterprise friendly architecture for application program and integration with Bitcoin-originated Blocksteam code makes sense to go forward.  Integrating this with IBM’s flexible framework enables a lot of new use cases.  It can also be a template for similar integrations.

    • Kelly:  Regarding privacy, how those need to move into an off-chain transaction?

      • Binh -- the model in OBC is similar to what is being used for bitcoin.  The generation of public key to be used in transaction is different.  This is described in whitepaper and protocol spec.

      • This is a permissioned network.  Every member (including clients -- whether application or device) would have to have a membership registration with entity called “membership services” -- this will generate a certificate called “enrollment certificate”... a client would have this.  Then a client can request a transaction certificate.  This is what is being used to transact on network.  Transaction certificate generated in a way that it contains various info in certificate to allow us with proper authority (auditor or regulator) to collaborate with member.  This is anonymous, with the exception of counterparties and regulators/auditors.

    • Mic:  Consensus mechanisms

      • Binh -- look at consensus a bit different in OBC.  Our specific implementation of BFT is like transaction ordering (a time keeper).  One could treat it as a black box.  Send transactions to it.  Output is a list of all transactions to execute or validate.  Does not matter what is happening in there, the output is a list of transactions to validate in order.

      • Mic -- though Ripple model may be more obvious fit for state transition approach.

      • CF -- idea is to get things moving and provide Project with framework that can be evolved as appropriate and as the community chooses… this is not the end-all answer.  This is a starting point to bring together pieces that have been proposed.  This does not exclude other proposals.  This is a foundation to build on as the community sees fit.

      • Dave -- this is important and we have technology we’d like to propose.  May be able to talk about it next week.  Like the idea of flexible framework.  There are concerns around docker containers (VMs may answer some of that).

      • CF -- highly encourages proposals to come forward.  People have different use cases.

      • Mic -- to evaluate if this is the right flexible architecture for diversity of group… can we determine specifics of what hyperledger project is solving that isn’t already covered by Blockstream, for example.

      • CF -- worthwhile if community could pull together white paper addressing exactly this.  Could harvest some thoughts from existing IBM white paper… or combine several existing white papers.  Should be a collaboration.  Does this work for people?  Pulling together high level use cases?

        • David Voell, Stefan Teis, Igor, Ram, all happy to help.

        • ACTION:  Chris Ferris to create a Google doc of white paper and link through wiki

    • Chris Ferris:  Are people comfortable with the DAH/IBM proposal to move forward?

      • Pardha -- agree, some working on white paper, some working on code in tandem.

      • Mic -- generally in favor of moving ahead quickly.  2 concerns -- would like to see what step 2 is to ensure flexibility and modularity (so isn’t single solution).  2)  moving fast is both good and bad.  Let’s move ahead, but ensure flexibility of architecture.

      • Stan -- 2nd what Mic says.  Let’s get started quickly…. but, if we start before white paper, should focus that architecture is modular enough.

      • David Voell -- move quickly and check to make sure everyone is comfortable with flexibility.  Test, fail, move on.  Don’t get stuck in analysis paralysis.

        • CONSENSUS:  No objections to DAH/IBM proposal.  Moving forward with starting on modular/extensible code base, and integrate UTXO transaction model into OBC.  In parallel, white paper that outlines where we are going and identify use cases.

        • Mic -- emphasis that both are important.  Requirements will set us up for evolution of project.  CF agrees.


Face-to-Face Technical Meeting


  • Week for 7th, 14th, 21st

  • Poll:  http://doodle.com/poll/syyqricigc2gaewq

  • David Voell / JPM has offered potential meeting space in Manhattan

  • F2F is open to all in the technical community, not just the 11 TSC members


On-going



--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] Scheduling / Technical F2F

Dave Neary <dneary@...>
 

Hi Todd,

Is there an opportunity to co-host this session with an industry event
(the day before or the day after) to make it a two-for-one for those
travelling in? I would suggest Consensus 2016, but early May might be
too far away.

Thanks,
Dave.

On 02/25/2016 07:56 PM, Todd Benzies via hyperledger-tsc wrote:
Hyperledger Project Technical Community,

As discussed on the TSC call today, there is interest for the TSC to
hold a technical face-to-face during the month of March. Note, this is
open to all in the technical community, not just the 11 TSC members.

Please indicate your availability to attend a F2F in NY. There are
currently 3 weeks being considered.

http://doodle.com/poll/syyqricigc2gaewq

If you have any questions, please send me an email directly.

Regards,

Todd

--
*Todd Benzies*
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
tbenzies@... <mailto:tbenzies@...>
Skype: tbenzies


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338


[Hyperledger Project TSC] Scheduling / Technical F2F

Todd Benzies <tbenzies@...>
 

Hyperledger Project Technical Community,

As discussed on the TSC call today, there is interest for the TSC to hold a technical face-to-face during the month of March.  Note, this is open to all in the technical community, not just the 11 TSC members.

Please indicate your availability to attend a F2F in NY.  There are currently 3 weeks being considered.


If you have any questions, please send me an email directly.

Regards,

Todd

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] Intro from Dan Conner of DisLedger

Allen
 

Hi Dan, my bad--I'll retract the question and post it to the technical list. Thanks, Allen

On Thu, Feb 25, 2016 at 1:15 PM, Allen <allenpmd@...> wrote:
Hi Dan,

Interesting whitepaper.  Question: If Alice conveys AssetX to Bob, my understanding is that this transaction shows up in the joint ledger between Alice and Bob, and both parties have an identical copy of this ledger.  Now Bob wants to convey AssetX to Charlie.  How does Charlie know that Bob is the owner of AssetX, or does Charlie just have to take Bob on his word?  Would it make a difference I rephrased that question to read "10 units of X" instead of "AssetX"?

Thanks,

Allen



Re: [Hyperledger Project TSC] Intro from Dan Conner of DisLedger

Allen
 

Hi Dan,

Interesting whitepaper.  Question: If Alice conveys AssetX to Bob, my understanding is that this transaction shows up in the joint ledger between Alice and Bob, and both parties have an identical copy of this ledger.  Now Bob wants to convey AssetX to Charlie.  How does Charlie know that Bob is the owner of AssetX, or does Charlie just have to take Bob on his word?  Would it make a difference I rephrased that question to read "10 units of X" instead of "AssetX"?

Thanks,

Allen


[Hyperledger Project TSC] Intro from Dan Conner of DisLedger

Dan Conner (dan.conner@disledger.com) <dan.conner@...>
 

That was an interesting TSC call this morning, I’m glad I got to listen in.

 

Attached is brief paper on the distributed concurrence ledger architecture ( also available at: )  http://www.disledger.com/DisLedger_Whitepaper_23Feb2016a.pdf

 

It’s pretty high-level but thought it might be of interest to some in the community.

 

Best Regards,

Dan

 

Dan Conner

DisLedger

www.DisLedger.com

mobile +1 703 597 1413


[Hyperledger Project TSC] link to joint DAH-IBM proposal

Christopher B Ferris <chrisfer@...>
 

Since the mailing list seems to strip the attachments from the archives, I have copied the proposal to a google-doc.

https://docs.google.com/document/d/1XV6U3kgZ31vZOz2nBLGe3vJgoLTnmOwv5qf3wo4lI68/edit?usp=sharing

I have also created a Wiki page where we can post proposals going forward.

Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402


[Hyperledger Project TSC] resend of joint proposal

Tamas Blummer <tamas@...>
 


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
Tamas Blummer
Chief Ledger Architect



[Hyperledger Project TSC] Introduction Mail from Suresh @ MobiSwipe India

Suresh <suresh@...>
 

Dear All,

 

Good to connect with you on Hyper ledger Project. 

 

I am the Co-Founder of MobiSwipe, mPOS Payments Solutions Start-up based in India. MobiSwipe is PCI-DSS and PA-DSS Compliant Highly Secured mPOS Solution that enables Merchants to Accept Credit & Debit Card Payments Anywhere & Anytime by using their Smart Phone or Tablet loaded with MobiSwipe Application that gets connected to the EMV Certified Pocket-Size Card Reader. We are seed funded by Vijay Shekhar Sharma of PAYTM. 

 

We would like to be part of Hyper Ledger Project and explore Blockchain Technology use case for enabling Person to Merchant Debit and Credit Card Payments Acquiring solution which can Reduce Transaction Cost and other applicable Banking charges such as Interchange, Association fees, processing etc… and enable Real-Time settlements.

 

I look forward to getting involved. Have a Good Day.

 

Thank you

 

Regards

70

 

Suresh S

Co-Founder & Joint CEO

MobiSwipe Technologies Private Limited

Suresh@... / +91 9884170040

 

This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version.

 

ANd9GcQwKEz4FVNAunrtrI3xCDZD3-YfOVgeDnTCmQTYHAAhsM4DN6qHBA

www.Facebook.com/MobiSwipe

 


Re: [Hyperledger Project TSC] IBM whitepaper

Tamas Blummer <tamas@...>
 

Hi Mic,

a joint proposal, that we circulated earlier on this list and will discuss on today's TSC call, attempts to merge a forward-looking technology exploration friendly fabric with an API for higher level application layers and the mature technology of the Bitcoin network. 

Our hlp-candidate that serves as one of the starting points in the proposal and might accommodate some of your uses. We hope on your contribution into the merge process we suggest, so features and design choices you like will be preserved.

Tamas Blummer
Chief Ledger Architect


On 24 Feb 2016, at 23:16, Bowman, Mic via hyperledger-tsc <hyperledger-tsc@...> wrote:

Thanks for putting this together. The white paper is a good starting point. That said, I have some concerns and a few questions. My concerns boil down to two areas: how do we ensure that the architecture/implementation is not limited to the usages we start with (that is, that we do not preclude additional usages) and how do we ensure that the architecture preserves the disintermediation that distinguishes digital ledgers from simple replicated databases.
 
·         In the abstract you reference business to business and business to customers as the two focus areas. While I fully acknowledge the “idiosyncrasies” of Bitcoin, it remains (one of?) the most popular, most active, and most mature of the digital ledgers. In general, sacrificing consumer to consumer usages (of which Bitcoin is one example) before we even begin to explore the architecture seems unfortunate. Clearly we can think of an ordering of usages based on time criticality, business viability, and probability of adoption… however, considering a broad set of usages ensures that decisions made for the most immediate usages don’t preclude other usages that may become the focus later.
·         You’ve provided three usages though there seems to be significant overlap in the requirements driven by those three. If we are going to limit discussion to three or four usages, I would prefer that they stretch thinking about the architecture. I strongly favor moving quickly on what we know (that is, pick one of the usages you propose to focus early implementation), but not if that means sacrificing the flexibility to address in the future the full spectrum of distributed ledger applications. Architectures ossify very quickly with implementation (which is both good and bad). In addition to the ones you provided (which are clearly the most important in the short term) we have a couple additional usages that we use as the basis for our thinking. I’ll publish them in a separate message.
·         The document seems to focus entirely on permissioned ledgers with vetted participants with centrally distributed identities. The architecture has a very strong dependency on what you called the “Membership Service”. I couldn’t find any additional details about that service. From the description it looks like a centralized PKI service. Was that your intention? If so, who runs that? If not, then what is your thinking about the vetting process for participants? I presume there are both a technical and institutional aspects of the solution. How do you imagine multiple providers working together to provide that service? As you are probably aware, Intel is using EPID for enclave attestation in SGX. That provides a way to verify the integrity of computations based on a trusted execution environment without disclosing identity. We would certainly like to consider the role of that capability in the Registration Service.
·         In most of the deployed ledgers we’ve looked (and we found this to be the case for our own tests), there is some way to manage transaction ingress to avoid DOS attacks and manage over-subscription of capacity. I really like the Ripple approach of “burning XRPs” as a way of ensuring that there is some back-pressure on transaction submission (you can easily submit valid transactions but it’s hard to submit enough to perform a DOS attack). Bitcoin miners are free to establish mechanisms to prioritize the transactions selected for a particular block (and there appear to be many such policies). Even in a permissioned ledger, there is a danger of one institution monopolizing a substantial portion of the resources unless there is some decentralized policy for managing resource utilization. As a group, we should think about mechanisms for incentivizing good behavior or constraining (possibly correct but) inappropriate behavior.
·         In the Usage FAQ linked to the white paper the expected performance numbers are 100K tps with 15 validating nodes “running in close proximity”. What does “close proximity” mean in this case? Single data center? Single metropolitan area? Implementations traditional BFT algorithms are hard to get right and are *VERY* difficult to scale to large numbers of participants (where large is 50). Even if we assume that there are some (to be discovered) techniques for scaling that to a few 100’s of replicas, that severely limits the decentralization of the ledger validation service (so we end up with just a replicated database). What are your thought about the organizational/institutional impact of that architecture (e.g. are there hierarchies of consortiums)? Clearly not every organization that would use the ledger would be in a position to participate in the validation of transactions. That means, at best, we have to build some kind of consortium to manage the limited number of validators or, at worst, we end up with a single provider (in which case we aren’t really talking about a distributed ledger any more).
·         And on the performance… again, it seems likely that some form of traditional BFT algorithm is going to be necessary for the financial applications where there are problems with the rollback potential in the proof-of-* blockchain consensus algorithms (including the one I talked about in the review last week). BFT algorithms force us into a small validator pool deployment. However, not all workloads are intolerant of rollback and are amenable to more scalable (where scalable is defined in terms of number and decentralization of validation resources) algorithms.. It seems unlikely that the three usages in the white paper will expose those requirements. I’m fairly certain that the IoT device registries and some other uses like that would help to expand our thinking.
·         One more issue that is probably more implementation than architecture… we have some concerns about the use of containers. The most obvious is the increase in the number of docker exploits that have been documented recently (see for example https://www.oreilly.com/ideas/five-security-concerns-when-using-docker and https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357). The other concern that that containers limit access to unique HW capabilities like SGX.
 
Again… I really like the architecture for addressing the needs of small groups of vetted organizations with high transaction rate requirements which is the dominant use in FSI. I look forward to working through validation of that claim and to adapting this (or another architecture if appropriate) to a broader set of requirements.
 
--mic
 
C. Mic Bowman
Principal Engineer
Intel Corporation
 
 
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 8:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper
 
All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Re: [Hyperledger Project TSC] proposal

Michael Dolan <mdolan@...>
 

I think there may be gap in understanding between those who were part of the early formation discussions and those who have joined the public conversations after the launch. Prior to launch there was discussion of the scope for Hyperledger amongst the companies who worked on the formation. 

There may be some “catching up” that group needs to do explaining the scope they were thinking of to the broader community. The attached diagram I believe captures the final draft that was discussed from a scope perspective - maybe this would be a helpful topic to start with today prior to jumping into the proposal?

— Mike

---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
---



On Feb 25, 2016, at 9:12 AM, Middleton, Dan via hyperledger-tsc <hyperledger-tsc@...> wrote:

Hi Chris,
 
Before engaging in a consolidation project, I think it would be helpful to better define the overall goals.  It is difficult to assess the merits of a design without the context of the problems it is intended to solve.
 
I propose that we first define objectives of the system.  This needn’t be a document heavy DODAF-style requirements process.  But completely forgoing such a process seems to make our decisions arbitrary.
 
Ultimately the success of this project will hinge on whether the software solves real problems for which there isn’t already a satisfactory solution.  In particular my mind goes to distinctions between a distributed ledger and a replicated database before even getting to specialized features of transaction types.  But rather than focus on that exclusively or attempt to list all possible objectives here, I will instead suggest that the first ‘sprint’ of the group be to define high-level objectives. 
 
With those objectives defined we can then assess an architecture that selects components from the pool of contributions or creates new ones accordingly.
 
Regards,
Dan Middleton
intel
 
 
From: hyperledger-tsc-bounces@...[mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Tuesday, February 23, 2016 12:33
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] proposal
 
All,
 
IBM and Digital Assets would like to jointly submit the following proposal for discussion on this Thursday's TSC call.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


Re: [Hyperledger Project TSC] proposal

Middleton, Dan <dan.middleton@...>
 

Hi Chris,

 

Before engaging in a consolidation project, I think it would be helpful to better define the overall goals.  It is difficult to assess the merits of a design without the context of the problems it is intended to solve.

 

I propose that we first define objectives of the system.  This needn’t be a document heavy DODAF-style requirements process.  But completely forgoing such a process seems to make our decisions arbitrary.

 

Ultimately the success of this project will hinge on whether the software solves real problems for which there isn’t already a satisfactory solution.  In particular my mind goes to distinctions between a distributed ledger and a replicated database before even getting to specialized features of transaction types.  But rather than focus on that exclusively or attempt to list all possible objectives here, I will instead suggest that the first ‘sprint’ of the group be to define high-level objectives. 

 

With those objectives defined we can then assess an architecture that selects components from the pool of contributions or creates new ones accordingly.

 

Regards,

Dan Middleton

intel

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Tuesday, February 23, 2016 12:33
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] proposal

 

All,

 

IBM and Digital Assets would like to jointly submit the following proposal for discussion on this Thursday's TSC call.

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 


Re: [Hyperledger Project TSC] IBM whitepaper

Mic Bowman
 

Thanks for putting this together. The white paper is a good starting point. That said, I have some concerns and a few questions. My concerns boil down to two areas: how do we ensure that the architecture/implementation is not limited to the usages we start with (that is, that we do not preclude additional usages) and how do we ensure that the architecture preserves the disintermediation that distinguishes digital ledgers from simple replicated databases.

 

·         In the abstract you reference business to business and business to customers as the two focus areas. While I fully acknowledge the “idiosyncrasies” of Bitcoin, it remains (one of?) the most popular, most active, and most mature of the digital ledgers. In general, sacrificing consumer to consumer usages (of which Bitcoin is one example) before we even begin to explore the architecture seems unfortunate. Clearly we can think of an ordering of usages based on time criticality, business viability, and probability of adoption… however, considering a broad set of usages ensures that decisions made for the most immediate usages don’t preclude other usages that may become the focus later.

·         You’ve provided three usages though there seems to be significant overlap in the requirements driven by those three. If we are going to limit discussion to three or four usages, I would prefer that they stretch thinking about the architecture. I strongly favor moving quickly on what we know (that is, pick one of the usages you propose to focus early implementation), but not if that means sacrificing the flexibility to address in the future the full spectrum of distributed ledger applications. Architectures ossify very quickly with implementation (which is both good and bad). In addition to the ones you provided (which are clearly the most important in the short term) we have a couple additional usages that we use as the basis for our thinking. I’ll publish them in a separate message.

·         The document seems to focus entirely on permissioned ledgers with vetted participants with centrally distributed identities. The architecture has a very strong dependency on what you called the “Membership Service”. I couldn’t find any additional details about that service. From the description it looks like a centralized PKI service. Was that your intention? If so, who runs that? If not, then what is your thinking about the vetting process for participants? I presume there are both a technical and institutional aspects of the solution. How do you imagine multiple providers working together to provide that service? As you are probably aware, Intel is using EPID for enclave attestation in SGX. That provides a way to verify the integrity of computations based on a trusted execution environment without disclosing identity. We would certainly like to consider the role of that capability in the Registration Service.

·         In most of the deployed ledgers we’ve looked (and we found this to be the case for our own tests), there is some way to manage transaction ingress to avoid DOS attacks and manage over-subscription of capacity. I really like the Ripple approach of “burning XRPs” as a way of ensuring that there is some back-pressure on transaction submission (you can easily submit valid transactions but it’s hard to submit enough to perform a DOS attack). Bitcoin miners are free to establish mechanisms to prioritize the transactions selected for a particular block (and there appear to be many such policies). Even in a permissioned ledger, there is a danger of one institution monopolizing a substantial portion of the resources unless there is some decentralized policy for managing resource utilization. As a group, we should think about mechanisms for incentivizing good behavior or constraining (possibly correct but) inappropriate behavior.

·         In the Usage FAQ linked to the white paper the expected performance numbers are 100K tps with 15 validating nodes “running in close proximity”. What does “close proximity” mean in this case? Single data center? Single metropolitan area? Implementations traditional BFT algorithms are hard to get right and are *VERY* difficult to scale to large numbers of participants (where large is 50). Even if we assume that there are some (to be discovered) techniques for scaling that to a few 100’s of replicas, that severely limits the decentralization of the ledger validation service (so we end up with just a replicated database). What are your thought about the organizational/institutional impact of that architecture (e.g. are there hierarchies of consortiums)? Clearly not every organization that would use the ledger would be in a position to participate in the validation of transactions. That means, at best, we have to build some kind of consortium to manage the limited number of validators or, at worst, we end up with a single provider (in which case we aren’t really talking about a distributed ledger any more).

·         And on the performance… again, it seems likely that some form of traditional BFT algorithm is going to be necessary for the financial applications where there are problems with the rollback potential in the proof-of-* blockchain consensus algorithms (including the one I talked about in the review last week). BFT algorithms force us into a small validator pool deployment. However, not all workloads are intolerant of rollback and are amenable to more scalable (where scalable is defined in terms of number and decentralization of validation resources) algorithms.. It seems unlikely that the three usages in the white paper will expose those requirements. I’m fairly certain that the IoT device registries and some other uses like that would help to expand our thinking.

·         One more issue that is probably more implementation than architecture… we have some concerns about the use of containers. The most obvious is the increase in the number of docker exploits that have been documented recently (see for example https://www.oreilly.com/ideas/five-security-concerns-when-using-docker and https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357). The other concern that that containers limit access to unique HW capabilities like SGX.

 

Again… I really like the architecture for addressing the needs of small groups of vetted organizations with high transaction rate requirements which is the dominant use in FSI. I look forward to working through validation of that claim and to adapting this (or another architecture if appropriate) to a broader set of requirements.

 

--mic

 

C. Mic Bowman

Principal Engineer

Intel Corporation

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 8:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper

 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.

 

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 


[Hyperledger Project TSC] TSC Chair - Results

Todd Benzies <tbenzies@...>
 

Hyperledger Project TSC,

The election for the TSC Chair has concluded.  Chris Ferris has been elected as the TSC Chair for the first year.

Regards,

Todd

--
Todd Benzies
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)
Skype: tbenzies


Re: [Hyperledger Project TSC] proposal

benedikt herudek <benedikt.herudek@...>
 

Is design and usecases from digital assets available, maybe we can share a link here ?

regards groet gruss

Benedikt

On 23 feb. 2016, at 20:34, Tamas Blummer via hyperledger-tsc <hyperledger-tsc@...> wrote:

Thanks a lot Chris for formulating our shared proposal. We look forward for feedback of the community.

Tamas Blummer
Chief Ledger Architect

<LogoVariations-03.jpg>

On 23 Feb 2016, at 13:32, Christopher B Ferris via hyperledger-tsc <hyperledger-tsc@...> wrote:

All,
 
IBM and Digital Assets would like to jointly submit the following proposal for discussion on this Thursday's TSC call.
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

<DAH-IBM Hyperledger Project Proposal - 20160223v2.docx>_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

3821 - 3840 of 3892