The Irregular Newsletter of Z/Yen Group Limited
Cass Business School Masterclass - Evidence-Based Decision Making For Charities
Ian Harris recently delivered a masterclass on evidence-based decision making for charities, for the consultancy practice at the Centre for Charity Effectiveness, Cass Business School (Cass CCE).
Adapted from Z/Yen’s popular Predictive Analytics Appreciation Courses, the session proved to be informative and useful for all concerned. As Ian himself said in his response to the positive feedback from the group:
“…[i]t was a very thoughtful group coming at the topic from a different angle compared with our clients and previous audiences. This made it a useful learning experience for all of us.”
This particular sub group of Cass CCE experts mainly specialised in leadership and governance, so their take on measurement was mostly focussed towards proving and improving impact. This thinking links with Z/Yen’s previous work on Evidence of Worth for Charities, while highlighting the need to orient charity analytics towards such evidence.
This is not entirely new ground to Z/Yen and Cass CCE of course; we collaborated several years ago on Predicting the Effectiveness of Grant Making. One of the conclusions from the masterclass was that we should now deploy similar approaches in other aspects of charity sector work, such as return on social impact investment.
There were lively discussions on why emerging techniques might profoundly change charities’ decision-making at all levels, from operations through leadership to governance.
Another emerging idea was to build on the work that Z/Yen, Cass and the Institute of Directors (IoD) did last year on corporate governance benchmarking and deploy a similar approach for charities. Cass CCE is now actively seeking sponsorship for an initiative in this governance area.
Security Forward Workshop and Dinner - 22 March 2016
Security Forward Risk and Intelligence Forum’s Spring meeting was held Z/Yen on 22 March 2016. Unusually, the meeting started with a presentation from our host, Alderman Professor Michael Mainelli, Executive Chairman of Z/Yen. Michael promised at our last meeting to be our guest speaker for a change and to give an explanation of the highly technical area of mutual distributed ledgers (MDLs, aka blockchains) and their importance to security issues. Michael and his team explained some of their MDL applications, such as identity systems, clinical records storage, and insurance messaging. They demonstrated one open system MetroGnomo (www.metrognomo.com), that is being used for ‘timestamping and file retrieval’. They also starred in their own feature film (4 minutes!). It was clear that many current cyber threats will be mitigated as such technology becomes more mainstream, however equally it means that moving more of life online will increase digital vulnerability. In some ways, the big long-term threats are more governments undermining ‘strong crypto’ with backdoors, or a massive electromagnetic pulse (e.g. a Carrington Event), than today’s necessary focus on cyber criminals. Despite the high technical content, there were quite a few self-satisfied expressions of “I even understood that”.
After our usual round-robin to identify ‘in tray’ issues and concerns, our second speaker was our own ‘Speaker in Residence’, Lt Colonel Crispin Black, MBE, MPhil. Crispin is an independent expert on terrorism, intelligence and security, as well as a novelist. Crispin’s presentation was entitled "Has The West Lost Its Edge In Scientific & Technical Education". Crispin’s presentation dealt with an old theme that has recently re-entered mainstream thinking, exacerbated by political turbulence in both Europe and the United States - a perceived haemorrhaging of power, energy and influence from the West to other parts of the world. He pointed out forcefully that Germany was the leading scientific and technical country in the world when Hitler came to power in January 1933. Its universities, such as Gottingen and Munich, where then more technically advanced than Cambridge, Harvard or MIT. But within months, thanks to Nazi pseudo-science and anti-Semitism , Germany's edge evaporated. Many important scientific programmes including, crucially, the German atomic bomb project foundered once Jewish scientists went into exile and the dead hand of totalitarianism began to stifle free thought. Many of the same forces seem to be in play in the Islamic World today which seems highly unlikely, for now, to become a serious competitor. China however, is a different prospect with its scientists able to exploit the achievements of the Americans and Europeans with ease in the internet age. Crispin suggested, as Europe’s borders begin to close to the outside world and various forms of group-think establish themselves on university campuses we may have to work hard to ensure that our scientists and engineers keep an open mind to developments elsewhere.
Following the meeting, we dined at The Honourable Artillery Company at Armoury House. Our cocktail of choice, in commemoration of the Empire changes of a century ago, the Irish Easter Rising, and Crispin's concluding image of Trinity College Dublin (one of Michael's alma maters) being defended by British forces and students, was the Black Velvet (Guinness and champagne). The parade in progress directly outside our window gave those of our Members with a military background an opportunity to see the HAC recruits being put through their paces. As all the NCO’s at the HAC are provided by The Brigade of Guards, the drill was of a high standard. Our dinner speaker was Professor Eugene Rogan, Director of The Middle East Centre at St Anthony’s College, University of Oxford. He is the author of "The Arabs: A History" (Penguin-2009), which has been translated in eleven languages and was named one of the best books of 2009 by The Economist, The Financial Times and Atlantic Monthly. His latest book is entitled "The Fall of The Ottomans: The Great War in The Middle East, 1914-1920". He spoke most eloquently about the book and then patiently and informedly took questions from the very knowledgeable group around the table. At the end of dinner, everybody was presented with a copy of his book and a very lively conversation followed. It was agreed that this had been one of our best meetings to date.
Future meetings for 2016 are planned for 29 June, 26 September and 7 December.
Terminology Wars – I Record Therefore I Ledger; I Block Therefore I Chain?
What is, and what isn’t, a ‘blockchain’? The Bitcoin cryptocurrency uses a data structure that I have often termed as part of a class of ‘mutual distributed ledgers’. Let me set out the terms as I understand them:
- ledger – a record of transactions;
- distributed – divided among several or many, in multiple locations;
- mutual – shared in common, or owned by a community;
- mutual distributed ledger (MDL) – a record of transactions shared in common and stored in multiple locations;
- mutual distributed ledger technology – a technology that provides an immutable record of transactions shared in common and stored in multiple locations.
The Bitcoin Wiki defines blockchain as “a transaction database shared by all nodes participating in a system based on the Bitcoin protocol.” (https://en.bitcoin.it/wiki/block_chain, 30 January 2016) So, ‘blockchain’ is, strictly, only the Bitcoin protocol transaction database. A Bitcoin purist might maintain “there is only one blockchain, the Bitcoin blockchain!” Yet Ripple (predating Bitcoin and blockchain terminology, from 2004) supposedly has a blockchain, Ethereum (2015) claims to have a blockchain, and about a thousand other cryptocurrencies have a blockchain, though most are copies of the Bitcoin protocol.
Wikipedia is, etymologically, a rather authoritative source on the current shared understanding of words we use to communicate. Wikipedia looks at blockchains more widely – “a block chain or blockchain is a permissionless distributed database based on the bitcoin protocol that maintains a continuously growing list of data records hardened against tampering and revision, even by operators of the data store's nodes. The initial and most widely known application of the block chain technology is the public ledger of transactions for bitcoin which has been the inspiration for similar implementations often known as altchains.” (https://en.wikipedia.org/wiki/Block_chain_(database), 30 January 2016). Wikipedia’s definition permits databases similar to Bitcoin’s blockchain to be called ‘blockchains’.
Interestingly, the 2008 Satoshi Nakamoto paper that preceded the 1 January 2009 launch of the Bitcoin protocol does not use the term ‘blockchain’ or ‘block chain’. It does refer to ‘blocks’. It does refer to ‘chains’. It does refer to ‘blocks’ being ‘chained’ and also a ‘proof-of-work chain’. The paper’s conclusion echoes a MDL – “we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.” (Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, bitcoin.org (2008), https://bitcoin.org/bitcoin.pdf)
I have been unable to find the person who coined the term ‘block chain’ or ‘blockchain’ [contributions welcome!, though I think that https://twitter.com/derosetech points out conclusively this source code from Satoshi Nakamoto as the origin of the term - https://github.com/trottier/original-bitcoin/blob/master/src/main.h#L795-L803 The term ‘blockchain’ only makes it into Google Trends in March 2012, over three years from the launch of the Bitcoin protocol.
And the tide may be turning. In July 2015 the States of Jersey issued a consultation document on regulation of virtual currencies and referred to ‘distributed ledger technology’ (see here). In January 2016, the UK Government Office of Science fixed on ‘distributed ledger technology’, as does the Financial Conduct Authority and the Bank of England. Etymological evolution is not over.
Wuz we first? Back in 1995, our firm, Z/Yen, faced a technical problem. We were building a highly secure case management system that would be used in the field by case officers on personal computers. Case officers would enter confidential details on the development and progress of their work. We needed to run a large concurrent database over numerous machines. We could not count on case officers ‘out on the road’ ‘dialling in’ or using internet connections. Given the highly sensitive nature of the cases, security was paramount and we couldn’t even trust the case officers overly much, so a full audit trail was required.
We took advantage of our clients’ ‘four eyes’ policy. Case officers never worked alone. Case officers worked on all cases together with someone else, and not on all cases with the same person. Case officers had to jointly agree on a final version of a case file. We could count on them (mostly) running into sufficient other case officers over a reasonable period of time and use their encounters to transmit data on all cases. So we built a decentralised system where every computer had a copy of everything, but encrypted so case officers could only view their own work, oblivious to the many other records on their machine. When case officers met each other their machines would ‘openly’ swap their joint files over a cable or floppy disk, but ‘confidentially’ swap everyone else’s encrypted files behind the scenes too. Even back at headquarters four servers treated each other as peers rather than having a ‘master’ central database. If a case officer failed to ‘bump into’ enough people, then he or she would be called and asked to dial in or meet someone or drop by headquarters to synchronise. This was, in practice, rarely required.
We called these decentralised chains of data ‘stacks’. We encrypted all of the files on the machines, permitting case officers to share keys only for their shared cases. We encrypted a hash of every record within each subsequent record, a process we called ‘sleeving’. We wound up with a highly successful system that had a continuous chain of sequentially encrypted records across multiple machines treating each other as peers. We had some problems with synchronising a concurrent database, but they were surmounted. At that time, I also held a senior post in the Ministry of Defence in charge of technology commercialisation, including ITSEC. I commented to colleagues that the most secure system Z/Yen had built had not been for the military. Their immediate reaction was our sleeved stacks were too complex and insecure because the data was not centrally held.
Whether it’s Newton or Leibniz, Von Neumann or Turing, Diffie-Hellman-Merkle/Rivest-Shamir-Adleman/Ellis-Cocks-Williamson, simultaneous invention is common. People facing similar problems reach for the contemporary tools available and frequently craft similar solutions. By the time we approached our problem, people had been working on concurrent and distributed databases for about two decades. They might say many of their ideas were in our software. Around the time of our work, there were other attempts to do similar highly secure distributed transaction databases, e.g. Ian Grigg’s and Ricardo on payments, Stanford University and LOCKSS and CLOCKSS for academic archiving. Some people might point out that we weren’t probably truly peer-to-peer, reserving that accolade for Gnutella in 2000. Whatever. We may have been bright, perhaps even first, but were not alone.
I saw my first database in the late 1970s. Yes, there was a time when they were the new new thing. In 1970, ‘Ted’ Codd publicly released some internal IBM work from 1969. I was too young to notice. It was ok. Codd’s work took some time to get recognised. An explosion of interest both within IBM and outside in firms such as Ingres and Oracle only started in the late 1970s. In fact, I saw my first database in Cincom’s Total, rather coincidentally and somewhat confusingly at the French oil firm Total, around this time.
Imagine two scenes. A – I come back to tell people about the database idea. “Look at this, holds oil data.” “Michael, that’s great but we’re working in cartography. Can it hold mapping data?” “Sure, we just change the name of an oil well to the name of an appropriate river, or the depth of the well to the height of the contour…” Too many people have discovered MDLs via cryptocurrency blockchains, so they think all MDLs work the same way. There are a lot of choices as we’ll see below.
B - I come back to tell people about the database idea, including my boss. “Hey boss, look at this. I have a sample database of everyone in the company’s salaries, and see, here, I can change the amount of my salary and it retotals the entire wage bill automatically without us having to write it out to magnetic tape or punch cards or paper tape.” In my excitement I may overlook the boss’s tone when he or she says, “Michael, perhaps you could make sure that people can’t change that without authorisation? Perhaps you could even add an audit trail that records all transactions?” “Boss, sure I could, but that would add a lot of processing time and storage costs…”
In a strict sense, MDLs are ‘bad’ databases. They wastefully store information about every single alteration or addition, and never delete. In another sense, MDLs are great databases. In a world of connectivity and cheap storage it can be a good engineering choice to record everything ‘forever’. MDLs make great ‘central databases’, logically central but physically distributed. This means that they eliminate a lot of messaging. Rather than sending you a file to edit, which you edit, send back a copy to me, then send a further copy on to someone else for more processing, all of us can access a central copy with a full audit trail of all changes. The more people involved in the messaging, the more ‘mutual’ participation, the more efficient this approach becomes.
Trillions Of Choice
Perhaps the most significant announcement of 2015 was in January from IBM and Samsung. They announced their intention to work together on mutual distributed ledgers (aka blockchain technology) for the Internet-of-Things. ADEPT (Autonomous Decentralized Peer-to-Peer Telemetry) is a jointly developed system for distributed networks of devices.
In summer 2015 a North American energy insurer raised an interesting problem with us. They were looking at insuring US energy companies about to offer reduced electricity rates to clients who allowed them to turn appliances on-and-off, for example a freezer. Now freezers in America can hold substantial and valuable quantities of foodstuffs, often several thousand dollars. Obviously, the insurer was worried about correctly pricing a policy for the electricity firm in case there was some enormous cyber-attack or network disturbance.
Take for example coming home to find your freezer off and several thousands of dollars worth of defrosted mush in your freezer. You ring your home & contents insurer who notes that you have one of those new-fangled electricity contracts. It was probably the electricity company. Go claim from them. You ring the electricity company. In a fit of customer service, they deny they had anything to do with turning off your machine, but, if anything, it was probably the freezer manufacturer who is at fault. The freezer manufacturer knows for a fact that there is nothing wrong except that you and the electricity company must have installed things improperly. Of course, you may not be all you seem to be. Perhaps you unplugged the freezer to vacuum your house and forgot to reconnect things. Or perhaps you were a bit tight on funds and thought you could turn your frozen food into ‘liquid assets’.
I believe IBM and Samsung foresee, correctly, ten billion people with hundreds of ledgers each, a trillion distributed ledgers. My freezer-electricity-control-ledger, my entertainment system, home security system, heating-and-cooling systems, telephone, autonomous automobile, local area network, etc. In future, machines will make decisions and send buy-and-sell signals to each other that have large financial consequences. Somewhat coyly, we pointed out to our North American insurer that they should perhaps be telling the electricity company which freezers to shut off first, starting with the low value contents ones.
A trillion or so ledgers will not run through a single one. The idea behind cryptocurrencies is ‘permissionless’ participation, any of the billions of people on the planet can participate. Another way of looking at this is that all of the billions of people on the planet are ‘permissioned’ to participate in the Bitcoin protocol for payments. The problem is that they will not be continuous participants. They will dip in and out. And if there is an opportunity for a temporary majority of cheats to defraud the system, they will. But for the other trillion-minus-1 ledgers, we know the participants who need to participate, us, the electricity company, the insurer, our bank, our freezer installer.
Some obvious implementation choices are: public versus private – is reading the ledger open to all or just to defined members of a limited community? Permissioned versus permissionless – are only people with permission allowed to add transactions, or can anyone attempt to add a transaction? True peer-to-peer or merely decentralized – are all nodes equal and performing the same tasks, or do some nodes have more power and additional tasks? People also need to decide if they want to use an existing ledger service (e.g. Bitcoin, Ethereum, Ripple), copy a ledger ‘off-the-shelf’, or build their own. Building your own is not easy, but it’s not impossible. People have enough trouble implementing a single database, so a welter of distributed databases is more complex, sure. However, if my firm can implement a couple of hundred with numerous variations, then it is not impossible for others.
The Coin Is Not The Chain
Another sticking point of terminology is adding new transactions. There are numerous validation mechanisms for authorizing new transactions, e.g. proof-of-work, proof-of-stake, consensus or identity mechanisms. I divide these into ‘proof-of-work’, i.e. ‘mining’, and consider all others various forms of ‘voting’ to agree. Sometimes one person has all the votes. Sometimes a group. Sometimes more complicated voting structures are built to reflect the power and economic environment in which the MDL operates. As Stalin noted, “I consider it completely unimportant who in the party will vote, or how; but what is extraordinarily important is this — who will count the votes, and how.”
As the various definitions above show, the blockchain is the data structure, the mechanism for recording transactions, not the mechanism for authorising new transactions. So the taxonomy starts with a MDL or shared ledger; one kind of MDL is a permissionless shared ledger; and one form of permissionless shared ledger is a blockchain.
Last year, Z/Yen created a new timestamping service, MetroGnomo, with the States of Alderney. We used a mutual distributed ledger technology, i.e. a technology that provides an immutable record of transactions shared in common and stored in multiple locations. However, we did not use ‘mining’ to authorise new transactions. Because the incentive to ‘cheat’ appears irrelevant here, we used an approach called ‘agnostic woven’ broadcasting from ‘transmitters’ to ‘receivers’. To paraphrase Douglas Hofstadter, an Eternal Golden Braid. Because we are writing single transactions against a UTC clock, our blocks are UTC time. We don’t strictly have blocks of grouped transactions.
So is MetroGnomo based on a blockchain? I say that MetroGnomo uses a MDL, part of a wider family that includes the Bitcoin blockchain along with others that claim use technologies similar to the Bitcoin blockchain. I believe that the mechanism for adding new transactions is novel (probably). For me it is a moot point if we ‘block’ a group of transactions or write them out singly (blocksize = 1).
Yes, I struggle with ‘blockchain’. When people talk to me about ‘blockchain’ it’s as if they’re trying to talk about databases yet keep referring to “The Ingres” or “The Oracle”. They presume the technological solution, “I think I need an Oracle” (sic), before specifying the generic technology, “I think I need a database”. Yet, I also struggle with MDL. It may be strictly correct, but it is long and boring. Blockchain, or even ‘Chains’ or ‘ChainZ’, is cuter.
We have tested alternative terms such as “replicated authoritative immutable ledger”, “persistent, pervasive, and permanent ledger”, and even the louche “consensual ledger”. My favourite might be ChainLedgers. Or Distributed ChainLedgers. Or LedgerChains. Who cares about strictly correctness? Let’s try to work harder on a common term. All suggestions welcome!
Thanks – I would like to thank Dave Birch of Consult Hyperion and David Bannister of Ovum for kicking off, and kicking around, this thinking.
Distributed Futures Forum, “Identity”, City of London Club, 17 March 2016
Nearly twenty of our group succeeded in digging out their tube passes, credit cards, and passports to attend our forum on Identity. Vinay kicked off the event with a presentation of his own, “Decisions And Profiles: Identity, Proof and Transactions”. He postulated a dozen theses on identity, viz.:
12 Theses On Identity
I. The quest for a philosophically satisfying definition of identity is a
II. Biological identity is a shifting goal post: what we can detect (say
DNA sequences) we soon manipulate, duplicate or edit.
III. Identifying people for taxation purposes is the backbone of our
common ID systems.
IV. Identity is poorly suited to many decision areas because it reveals
too much private profile information (i.e. health status).
V. Knowing who a person is in absolute terms can be dangerous or
expensive (i.e. liability for later identity theft).
VI. Mostly we need a context for decision-making and an ability to
follow up in the event of later trouble.
VII. Proving that two people are the same person at different points in
time is relatively easy (passwords, say).
VIII. Proving that two people are not the same person (KYC, auction,
online poker) is much harder without physical inspection.
IX. People’s footprints in different areas of their lives pile up in
different record keeping systems which may or may not have a
similar enough frame of reference to later merge (credit card into
with passports, say).
X. Private key ownership can be used to unify various records through
one key signing another key - but this provides for VII but not VIII,
which is a major problem in many applications.
XI. Voting is a special case, but could be the core case for state identity
XII. Do we have an inherent right to define ourselves, or are we part of
the stock? Does this vary from one context to another?
His theses provoked a fascinating discussion and seemed to get everyone involved from one side or the other of debate, ranging from “identity issues matter most to the security & intelligence communities” versus “identity issues matter most to the tax authorities”, or “DNA forging will be common in about a decade”. A recent article by Michael and Vinay covers some of these identity issues from a financial services perspective:
Michael Mainelli and Vinay Gupta
Banking Technology (February 2016).
We followed with a Round Robin of what people had in their ‘in trays’, always one of the most useful points in the forum where people work out how to link up on projects. Then we moved to three punchy presentations on a range of identity issues.
Matthew Commons, CEO of Cambridge Blockchain, and one of our founder members, flew in from Boston to share his thoughts on “Identity And A Future Of Frictionless Transactions”. He explored some of the trials and research that he and his team are conducting in financial securities and incremental sharing of sensitive information. The group discussed the potential of blockchain technology for applications in identity management and compliance among financial institutions and Matthew provided some materials showing how this would work on a sample blockchain.
John Bullard, Global Ambassador for IdenTrust, gave a presentation on “Dictum Meum Pactum … In The Internet Era”. IdenTrust is a bank consortium acting as a public key certificate authority and secure applications provider whose members include some of the largest banks in the world. John’s presentation of a much older (well, started in 1999, so older than most of the blockchain start-ups in identity) institution’s difficulties in gaining scale gave many both pause for thought and opportunity. It was noted that the aggregation of so much legal work in creating a solid consortium over nearly two decades had a value all of its own.
Anna Mazzone, Global Head of Client Development & Managing Director of Trunomi and one of our new members, spoke about “Barriers To Digital On-Boarding In Europe”. Her talk focused on the importance of EU data protection reforms that have led to the General Data Protection Regulation (GDPR). She convincingly presented these reforms as amongst the most challenging for large firms handling clients’ data. However, she felt that these reforms might make Europe extremely competitive in the information and financial sectors. Her talk rang bells with people involved in discussions with policy-makers over strong encryption rights and the recent Apple v FBI iPhone unlocking case of San Bernadino.
All three talks generated valuable discussion on the opportunities for new technology. Sadly, we had to break for dinner, heading to the Capital Club and its bar. Our signature cocktail for the day celebrated the importance of identity in two ways. First, the beer cocktail concerned was invented at Brook’s Club, involved in ensuring the identity and credit of gamblers. Second, the drink is a celebratory one for St Patrick’s Day itself, the Black Velvet. We headed up to the wood-panelled boardroom where, before dinner, Martin Lloyd, the Famous Author, told three stories from his most original and highly regarded book, “The Passport: The History Of Man's Most Travelled Document”. Martin kindly showed some passports from the nearly 1,300 in his collection and answered questions on the Neither-Civil-Nor-Servant life of an immigration officer, Nansen passports, and cycling through France and Spain. At the end of a convivial dinner, members and guests left happily knowing more about themselves and each other, and maybe a bit more about their own identities.