2016-09 (September 2016) Meetings

Owned by Eve Maler
Last updated: Sept 29, 2016
11 min read

This page records the Discussion Group's meeting notes for September 2016. We meet Tuesdays at 7:30am PT / 10:30am ET / 3:30pm UK / 4:30pm CET 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.

Thursday, September 29

Agenda:

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:

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. (smile)

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:

  • Informal report writing

Attending: Adam, Thomas, Kathleen, JohnW, Adrian, JeffS

Adrian's use cases are reasonable, and not new.  Thomas: Identity is a problem that predates blockchains technologies. So BSC-DG will not address this as a new issue. Identity is an issue separate from blockchains.

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 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 Europeans at next HL7/Security WG.

JohnW: bchains can also be used by abusers (e.g. Bob pressures Alice to sign consent) to record. Thomas: agree bchains don't solve socio-cultural (people) problems.

Looking at list of uses cases, Thomas suggested we rename the "Stellar" use case into a better title ("Data Sharing Agreements"). JohnW will contribute 1/2 page (maybe copying from his coming whitepaper).

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:

  • Informal report writing

Matisse, JohnW, Kathleen, JohnM, ScottS, Thomas, Adrian,

Continue the use case.

MedRec use case: Tracking medical records on blockchain to track. Patient (Alice) wants control regards to who she shares data with, revoke consent, etc. PM needs more specific info regarding patients (e.g. with HIV of a given type).  Similar to UMA.

Bchain provides method to log access to patient data in an immutable manner.

JohnW:  patient has not choice/control who the receiver of the data.  So Bchain provides a way to provide accountability of the entities that access/use Alice’s data.  All entities in the ecosystem need to record their accesses to the bchain. The agreement could travel with the data. A private bchain could be used to provide privacy to the patient.  Also, anonymous identities could be used while allowing Alice to point to her transactions.

Adrian asked about using hash of the contract (by the provider).  Kathleen: yes that’s one way to do it. Matisse: also sees the need to use private bchains. JohnW: desirable outcome is to not have 1 gatekeeper. Use the distributed models inherent in bchains today. (see CISWG diagram). Adrian: Vermont bill may allow orgs and governments to accept evidence recorded on a blockchain.

Adrian: 3 uses of bchain: identity, timestamp, AppCoins.

https://medium.com/the-coinbase-blog/app-coins-and-the-dawn-of-the-decentralized-business-model-8b8c951e734f#.igpa4pecn

https://s3.amazonaws.com/stampery-cdn/docs/Stampery-BTA-v5-whitepaper.pdf

 

Friday, September 9

Agenda:

  • Informal report writing

Attending: Eve, Andrew, Thomas, Domenico, Luk?, Kathleen

Thoughts for the report: If some topics aren't "use cases" because they assume technologies/techniques, could we still include them as "tests" (e.g. real-world case studies that use blockchain)? MedRec is one such case study. That would allow us to include a lot of up-to-the-minute information.

Also, we would like to include some thread of blockchain vs. smart contracts. We already have this covered in the report outline.

We're thinking that maxing out on the number of use cases and case studies (five each, or even less) will be fine; that will elicit the analysis we need. We could easily analyze up to five actual real projects/pilots/POCs ("case studies") out there; there are so many. The distinction in the name is "theoretical vs. actual". Hmm, we might not want to put a limit on case studies as long as we keep illustrating real technologies/techniques. Let's limit theoretical use cases, though. In which case we've probably hit our limit among those submitted.

We'd like to propose that our meetings use a pattern in our meetings of using the half-hour for use case work, and a second half-hour for deep-dive report writing (that is to say, doing this twice a week).

Next week Eve can't attend due to being awesomely in Barcelona. Can Thomas run the meetings next week? Please confirm to the list.

Kathleen took an action to flesh out some MedRec case study text for next week.

Tuesday, September 6

Agenda:

  • Pick a time for an ad hoc report working session
  • Work on use cases on the call (finally!)

Attending: Eve, Kathleen, Jeff S, Adam M, John M, Scott S, Domenico, Adrian, Jim, John W

NOTE: No BSC telecon this Thursday because we couldn't find a chair pro tem.

Eve, Thomas, Kathleen, and Scott D had expressed particular interest in an editing session. We'll work out a time for that and advertise the time. (John W and Domenico have some interest.)

Regarding the Stellar Consensus Protocol-involving use case: John W notes: "Disclaimer re: Stellar Consensus Protocol. I work with JLINC Labs which uses the Stellar blockchain for our open source JLINC protocol."

John M describes his new "Evidence Notebook" use case: It's trying to achieve what Jim describes as proof-of-existence in a way that can be private at first. He provides three variations, e.g. to provide signatures. Community peers could even provide counter-signatures even if they can't see the content. He's prepared for lots of discussion over all of this. Adrian ties these ideas to his for doctors signing patient-centric prescriptions, noting that no smart contract is needed in his scenario; for John's use case, the signature is independent and doesn't need smart contracts while the escrow does.

Observing commonalities in use cases: John W sees that there are attributes (facts??) that are frozen and verifiable. In the identity space, these might be identity attributes.

 

 

Thursday, September 1

Agenda:

  • Working session on report text to capture sentiment around "central tension" (vs. cooperative "outlet") and action items for fleshing it out
    • Could result in text in use case(s) and technology/technique description/analysis too

Attending: Eve, Thomas, Matisse, Jim, John W, Adrian, Scott D, Kathleen

We'd really like to delve into all the use cases being contributed. But it seems we need to deal with this elephant in the room; then we can make quicker progress on the use cases and the technologies/techniques!

How to address the tensions and mitigations in our deliverables? There's a kind of recursion we can see in how reliability of interactions is increased (Scott D's traffic lights example). Or is it commoditization? Race to the top? Standardization? All of the above? Almost any use case could do, he thinks, as long as they capture the same pattern. Merkel turtles!

Scott suggests that channel integrity be applied along with reliability here. Financial products are commoditized though intangible. A blockchain is a time machine. Jim adds: Each event is a record, linking to the prior state and to any code or prose needed to execute or understand.

John asks: Is model-view-controller an apt design pattern to apply here? Jim notes: parameters-prose-code seems awfully close.

Applying security and privacy, Kathleen adds the concept of dynamism. Capturing someone's consent requires capturing their parameters.

The forthcoming paper on computational sovereignty is about "Who do you put in the 'turtle' position?" (Turtles all the way down...)

Identity comes in because you need to test "halt, who goes there" and "state your business" (authentication and authorization) and your purpose of use. But then you're right back to the "poison of centralization"! PKI, DNS, third-party asserted identity, IdPs, cross-domain SSO, and all the rest. Unless you're doing "decentralization" in a single-domain sandbox, which is less interesting (discussed on Tuesday), or doing ZKP tricks that are (Eve's position) too technically tricky and expensive for users' desires, IAM today is a centralization play.

Can we call it the "drug of centralization" instead, to be more philosophically neutral? Yes. Or even the "siren song".

Who's interested to put together the awesome 1-2 page summary of this? Eve, Thomas, Kathleen, Scott D.

Scott D points to Cope's Rule in biology as gainsaying Eve's belief that decentralization as inherently unstable in most circumstances. Scott: Rule-making, operations, and enforcement can be separated so that not all need to be centralization. (Also see the network effect.) Eve's version says that "No committee ever recommends its own demise." (smile) This is why she hopes that we stick to our six-month plan!

Can we find a chair pro tem for next Thursday?