AThis This page records the Discussion Group's meeting notes for September 2016. We meet Tuesdays for 30 minutes at at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET . We meet Thursdays for 30 minutes at and Thursdays at 11am PT / 2pm ET / 7pm UK / 8pm CET for 60 minutes. US times are normative during daylight saving time changes. We use Kantara Line A (US +1-805-309-2350, Skype +99051000000481, international options, web interface, more info, code 4022737) and http://join.me/findthomas for screen sharing. See the DG calendar for our full meeting schedule. Previous meeting minutes are here: July, August.
| Table of Contents | ||||||
|---|---|---|---|---|---|---|
|
Thursday, September 29
Agenda:
- Report writing
Attending: Eve, Thorsten, Andrew, Scott S, Kathleen, Matisse
We did a lot of report writing work, directly in the report.
AI: Eve: Ask Scott D if he will take an action to write the "Legal Contracts" section of the report, providing a definition, a short discussion of strengths and weakness of the current way of doing things, and pointers to the other technology and technique sections as appropriate for starters. Bringing in the ethics perspective would also be awesome.
AI: Eve: Ask Thomas if he will take an action to write the "IPFS" section along the lines just above.
AI: Eve: Ask John W if he will take an action to write the "Consent Receipts" section along the lines just above, and either write or find a designee for the "User-Submitted Terms" section.
Others took AIs to fill in other similar report sections on the call; see the report for those.
Everyone please review the report for the latest!
Tuesday, September 27
Agenda:
- Report writing
Attending: Eve, Thomas, Thorsten, Andrew, John W, Jim H, Matisse
We have a LOT of new information sources, including some comparative material, to help us complete our thematic introduction in the report.
(One new source shared on the call: Stellar info.)
Is it meaningful to achieve "transactional empowerment" use cases if you are some way down the path of decentralization, or must you reach 100% decentralization? Andrew suggests that where perfect decentralization can't be achieved, transparency and accountability can shore up the necessarily centralized parts of the system. Having "an authority" (vs. "your peers") detect a transgression requires traditional controls. But, speaking of roles here, depending on what sort of blockchain technology and governance model and blockchain contents are involved, are they really "your peers"? There seem to be a lot of ways that the node miners' interests may not be strictly aligned with yours.
Matisse believes the main value of choosing blockchain for "transactional empowerment" would be smart contracts – being able to withdraw your consent from a contract and, say, get your money back from a smart vending machine. Jim notes that smart contracts are really a different technology from blockchain – based on blockchain technology but a specific application that requires "contract semantics" at the nodes.
Regarding economic efficiencies, a big attraction of Bitcoin use cases has been to make transactions more efficient by removing intermediaries. However, the world has been finding that technical inefficiencies (performance challenges) have arisen.
Specific use cases: currency (a la Bitcoin), certification (a la notary services), smart contracts (a la vending machine, land registry, drone control)... Jim has made the case that smart contracts need to connect to the legal world through both format and semantics. A transactional system presumably must take into account the "business/legal" environment in some fashion, even if just implicitly (say, by referencing certain jurisdictional laws, terms, and concepts). So either a smart contract is a non-contract (the way a contract with a killer would be – though perhaps with consequences less dire!) or it is a true contract precisely by taking into account its surrounding business/legal environment through a standardized format and semantics. It had better be possible for a true "smart contract" to have parties who have the proper rights and responsibilities.
AIs:
- Jim: Share his draft Kantara blog post on the list
- Eve: Take the latest notes and try and squeeze them into the report for review on Thursday
- All: Please review all the resources shared on the list and in the notes before Thursday
Thursday, September 22
Agenda:
- Report writing
- Search for independent and dependent variables among the "tensions", as inspired by Kathleen and John W for the report
- Review use case analysis inputs from John W for the report, if available
Attending: Eve, Matisse, Thomas, Colin, Andrew, Marco, Matisse
News: News has hit of an "editable" blockchain technology that Accenture has prototyped. This seems...kind of scammy. They seem to have created a private blockchain. Does it require proof of work? Is it really a blockchain? Why would you want to "accelerate...adoption" of blockchain by removing a key defining feature of actual blockchains? Maybe this makes enterprises feel cool, but tamper-evident ledgers can be done right now without having to involve the "b-word". We pronounce this another b-word: bogus. 
Tension/theme analysis: Can a blockchain be considered "a distributed system" in the formal sense? There are a number of resources we could draw on to analyze its characteristics if so: scalability, transparency, etc. See this article. Matisse supports this analysis, as it's the premise of her PhD. thesis!
A neutral way of stating the columns Kathleen has added on the right that our participants are more invested in, for use-case reasons, would be (all, please offer feedback on this):
- "Balance of control" in transactions (which can include contracts and data sharing) – enabling individuals to rise to the level of a "peer" to traditionally more empowered entities
- "Transactions" is the broadest possible term in common usage
- This item is the broad descriptor
- "Granularity of control" ?? in transactions – enabling not a totality of trust and liability but an apportioning that is appropriate
- Supposedly Bitcoin, a special-purpose blockchain, has protected individuals on this dimension, but each smart contract could still leave individuals open to abuse
- "Dynamism of control" ?? in transactions – enabling individual choice both over time and just-in-time
When is a public blockchain appropriate, vs. a consortium-model blockchain, vs. a private blockchain?
AI: Matisse: Share pointers to papers to let us analyze specific blockchain types for next time.
Next time: Get into both specific blockchain mentions and use case-specific analysis, and try to flesh out the report intro for good and all.
Tuesday, September 20
Agenda:
- Report writing
- Identify strengths and weaknesses of traditional and new distributed methods of solving use cases
Attending: Eve, Scott S, Jeff, Matisse, Andrew, Jim H, Domenico, John W
Eve reviewed a graph that Kathleen essayed in private email, with three axes: economic paradigm, (political) governance model, and (openness) community type. (s/oligarchy/oligopoly/)
We're enthusiastic about finding out how technologies would get plotted. We wonder if there are exactly three axes and if they're really orthogonal. Can we start by taking the matrix approach in Kathleen's first email, and "checking off" (as in John W's Stellar matrix example) characteristics/features that each technology has? Since there are so many consensus protocols and they change fast, we want to take a relatively high-level approach for a key sampling of these.
For the Alice Participates in Bob's Research Study use case, what are the strengths and weaknesses of doing things using today's technologies and techniques?
- Registries related to particular diseases, such as cancer – clinicaltrials.gov – centralized control systems record the outcome of studies but don't engage with the patient in any way.
- To add such functionality, you'd have to bolt something on, or develop a linking mechanism in between the two.
How could things be different?
- An information sharing agreement (a la JSON-LD) would point to the study (which has a study number) and to the data needed (or a pointer to it).
- Consent?
- Retrofit?
- Efficiency?
- Accountability?
- Trust mechanism? How do you establish that the next slot in the chain is trustable? To what extent does this involve the "drug of centralization" once again?
- Automatability/dynamism?
- If solved with "just blockchain", has these S&W
- If solved with "smart contracts", has these S&W
- If solved with both...
- If solved with IPFS...
A pattern we're imagining in the report is that many use cases will have similar strength and weakness patterns, and we'll want to discuss those in one big analysis section. Each use case may then have its own small subsection(s) discussing delta as necessary. For example, if we think that "automation vs. manual" is a strength of new tech vs. old tech, and "privacy" is a weakness of new tech vs. old tech, we can say that once in the big analysis section.
We might end up recommending a Work Group that develops an architecture, or set/range of architectures, that targets optimal outcomes among the strengths, and mitigates the risks among the weaknesses.
The ISO now has a blockchain group.
Next time:
- Search for independent and dependent variables among the "tensions", as inspired by Kathleen and John W for the report
- Review use case analysis inputs from John W for the report, if available
Friday, September 15
Agenda:
...
Thomas: do the MedRec issues get solved using bchains. For consent captured, yes. Kathleen: but bchains does not solve the policy issues, notably in the contesxt context of EHR record access and sharing. There is also the added issue of PII-leakgae. (Kathleen may write it up - critique of medrec and solutions). Thomas asks about how people do EHR in Europe. Kathleen will ask the Europewns Europeans at next HL7/Security WG.
JohnW: bchains can also be used by abusers (e.g. Bob pressures Alice to sign conswentconsent) to record. Thomas: agree bchains don't solve socio-cultural (people) problems.
...
JohnW: The ability to write the next block in the chain is a "right" to be earned. Bitcoin uses PoW. Stellar uses a separate consensus algorithm. No single answer. Depends on scenario. Aspects include leader-selection, etc. Notion of "leader" means the node who finishes/wins PoW and gets the right to write to bchains. https://www.stellar.org/how-it-works/stellar-basics/
Jeff: Ethereum uses Proof of Stake (PoS) which is more efficient and lower CPU usage barrier. Hopefully new methods of verification techniques will be developed.
Adrian: Many services are covering multiple chains/currencies.
Tuesday, September 13
Agenda:
...