Todd Benzies <tbenzies@...>
[note: minutes and recordings will now also be posted at https://github.com/hyperledger/hyperledger/wiki/Technical-Steering-Committee]
Technical Steering Committee (TSC) Meeting
February 25, 2016 (7:00am - 8:30am PT)
Deutsche Boerse Group
Richard G. Brown
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)
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?
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?
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
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
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)