Free advice can be valuable… but only if you take it

If a client tells you your solution doesn’t solve their problem, it may not be the problem that needs to change…

I often argue for the importance of blockchain and distributed ledger technology by using the following chain of logic:

  • Bitcoin’s architecture solved the problem of censorship-resistant digital cash
  • But few, if any, financial firms are interested in censorship-resistant digital cash
  • So why are they looking at this technology?
  • Because some principles underpinning Bitcoin’s architecture – shared ledgers, for example – could be relevant to problems that banks face.

Sure, a blockchain or a replicated shared ledger could indeed be useful to banks. Perhaps it could reduce the need for reconciliation between firms if they all ran off a single ledger, for example. But this says nothing about whether blockchains are the optimal solution to any particular problem in banking.  That still has to be argued, of course.

Recall: the bitcoin architecture was a solution to a very specific, very carefully framed problem – how to transmit value without the risk of censorship. Just because the underlying architecture could be used to solve some pressing problems in banking doesn’t mean it’s the best way to do so. Indeed, although the interlocking aspects of the Bitcoin solution are in some ways quite elegant, there are also some compromises. After all, it is an engineering solution to a set of very specific constraints and so it has to be demonstrated that it’s the right solution when the constraints are different.

Lee Braine, of Barclays Investment Bank CTO Office, made an important contribution to this debate when he spoke at London Blockchain Conference 2015 recently.  The video is now available and I urge anybody working in this space to watch it and to internalise its message.

We all too often “talk past each other” in the distributed ledger world and we are quick to assume the other person just “doesn’t get it”.  I can assure you that Lee does get it and it would be a brave startup in this space that chooses to disregard what he said. He’s giving us free advice! Take it!

Like I say, watch the video for yourselves.

I think another way to capture the chain of logic in the video is as follows:

  • Assume the ongoing interest in the application of blockchain technology continues
  • Assume further that some banks identify some compelling business opportunities in deploying a cryptographically-secure shared ledger between themselves.
  • What is the probability that a derivative of Bitcoin or Ethereum or any other current platform will be the best solution to that specific problem?
  • Given that none of them were invented to solve that problem, surely it’s quite low, right?

So we could find ourselves in the situation that bitcoin and blockchain technology have catalysed an orgy of activity, that this activity has identified countless high-quality business problems and yet none of those opportunities are best addressed with the technology that triggered the excitement in the first place!

The theme of this blog is “free advice” and the free advice I’m taking from Lee’s comments includes:

First, we shouldn’t get enamoured by a particular implementation of a technology. Sure: if you have an implementation then you may have bought a place at the table.  But don’t make the mistake of assuming that if the business problem doesn’t fit the technology then it’s the business problem that needs to change!

Secondly, if you’re working in a financial institution, be careful to distinguish between the principles embodied in these technologies. Shared ledgers? Yes. That seems to be at the heart of this domain. Indiscriminate replication? Perhaps. Cryptographically-secured access down to the “row” level? Probably. And so on.

Thirdly, consider the complexity of banks’ existing IT environments. An idealised, “wouldn’t the world be perfect if…” solution is no use to anybody if it requires the whole world to move at once and/or if there is no credible migration path.  This points to a need to listen to the incumbents when they object.  Furthermore, consider the non-functional requirements which are simply a given in this space.

Fourthly, if we assume that today’s current hyperactivity will lead to a new understanding of the possibilities for banks but don’t assume that today’s blockchain platforms (permissioned or permissionless) are the (whole) answer, then surely we’re back in the land of engineering, architecture and hard work? Perhaps this means that the combination of persistence, data models, APIs, consensus, identity and other components that we need won’t all come from one firm.  So a common language, some common vision and an ability to collaborate may become critical. Where is your distinct differentiation? Where would you fit in an overall stack?

Brief thoughts on the Bitcoin block size debate

I’ve kept well away from the block size debate but the launch of Bitcoin XT is worth a quick mention.

My reasons for staying out of the debate are pretty obvious: I’m not a miner, I’m not a core developer, I don’t run a wallet service, I have no particular insight into the engineering trade-offs and, perhaps most importantly, I’m not mad. If I wanted to argue with people on the internet, there are far more interesting topics than Bitcoin’s block size…

But I’ve been asked by several people what I think.  And, at core, I think it might come down to three issues: 1) fear of two different types of failure, 2) a clash of visions and 3) no process for reconciling the first two issues.

Fear of Two Different Types of Failure

Fear of technical failure

I don’t contribute, but I do read the Bitcoin Development mailing list.  I find it immensely helpful in keeping up with much of the day-to-debate debate.  What becomes clear when you read it is that there are (at least!) two distinct cultures at work.

First, there is a very strong security engineering culture. I sometimes think the trick to being a good security engineer is to think like a software tester (and vice versa): “How could I break this?”… “How could an attacker get round this?”… “What could go wrong here?”… “How could I force the provider of this service to waste all their resources”  And so on.   Your job is to figure out all the ways something could fail, and fix it.

So, when presented with something like an increased block size, you obviously focus on all the things that could go wrong: miners on slow connections could get out-of-sync with those on the other side, the increased cost of running a node could create a centralisation pressure and so on.    And when you compare this against the potential benefits, you might not think the change makes sense:  there’s an increased technical and security risk but you haven’t fixed the underlying scalability issue at the heart of the system… you have, in some ways, just kicked the can down the road. So you might say that a driving issue here is “fear of technical failure”: the change, which has uncertain benefits, could cause catastrophic harm.  Better not do it just yet.

Fear of practical failure

But, on the other side, is a somewhat different culture, one that comes from a world where there are problems everywhere you look and they all need fixing.  So you pick the biggest one, fix it and move on.  The engineering functions of large companies are often like this.  You know your change might cause problems but if you believe “doing nothing” is not an option then it comes down to making the least-worst decision.  There are, after all, usually no good solutions, just compromises.

So, if you’re faced with a problem like blocks getting full in some foreseeable timeframe, it is natural to ask yourself: what is the risk of doing nothing? If your belief is that consumers mostly have choices and will simply abandon a system that can’t guarantee transaction confirmation in a reasonable period then you’ll likely see failure to increase the block size as something that will lead to a catastrophic exodus of users and your bias will likely be towards making the change.  For you, the issue is “fear of practical failure”: failing to increase the blocksize, a change which has uncertain risks in any case, will drive away users and make the system a failure in all practical cases.

I exaggerate for effect, of course and I’ve ignored many aspects of the argument (e.g. the fee market, etc). And I’m sure some of the details are simply wrong.  But note: even under this simplistic model, it doesn’t mean either side is “wrong” or “bad”: it is possible to hold either view quite legitimately and to passionately believe the other side is wrong

A Clash of Visions

Where it gets more complex is when it comes to vision: if there was common agreement on what outcome was desired (e.g. “x transactions per second across the blockchain by 2017” or “the system should support this number of consumer wallets”) then the discussion would be a pure engineering discussion: “what is the best way to achieve this goal?”  But it strikes me that there isn’t agreement on this underlying vision.

And so, the engineering discussions get lost in the sound of people talking past each other or, worse, resorting to ad hominem arguments.  If you’re arguing from different premises, you never get anywhere, sadly.  It’s what makes political discussions on the internet so tedious..!

Process

In most projects, these issues can be resolved, ultimately, through the “benevolent dictator” model. Linus just decides.  Unfortunately, that process just doesn’t work in a system like Bitcoin. It’s not enough to control which code goes into the “core” distribution: the prevailing network rules are a complex function of miner adoption, full node adoption, wallet adoption, major merchant/processor adoption, and more.  It’s an inherently messy and political process. So the block size debate is likely to just be the first of many such controversies in this world.   The launch of Bitcoin XT is an interesting way to force the debate towards a conclusion but it’s likely to be messy.

And I hope those looking at “private blockchains” aren’t feeling smug as they read this. Managing the maintenance and upgrades of shared ledger systems between firms won’t be a walk in the park, either.

I have no particular insight into where this will go or which vision of the future will prevail.  But I hope (perhaps forlornly) that it will be resolved through the actions of professionals acting in good faith and that neither side will resort to “dirty tricks”.

Bitcoin and Blockchain: two revolutions for the price of one?

I gave a brief talk on Bitcoin and blockchain technology to an audience of non-specialists at a dinner last week.  It covers many of the themes I’ve explored on this blog before. But the short, fifteen-minute, format forced me to be brief and clear.  This is an edited version of the speech

A £20 note has an obvious, yet extraordinary super-power.   I can hand it to anybody in this room and £20 of value will be transferred instantly, directly, peer-to-peer, person-to-person. Settlement, with finality, in central bank money!  And nobody else need know.  And nobody can stop me.

Super20

Super £20!!   [I really hope there’s no law against posting photos of money…]

But this super-power only works at close distance.  If I want to transfer £20 of value to somebody in a different town or in a different country, I need to trust other people.  Sure: I could put the £20 in an envelope and post it.  But even then I’d have to trust the postal service.

Or I could use a bank.  But I’d be trusting them to be good for the money. And I’d have handed over control: if my name’s on the wrong list, the bank would be obligated to seize my funds. And if you’re on the wrong list, the bank will refuse to transfer the money to you…

“Digital” money is not the same as physical cash.

And the world’s financial plumbing – payments systems, correspondent banking, SWIFT, … – is a direct consequence of this observation: physical cash really is fundamentally different to every other form of money: only physical cash is a bearer instrument. And only physical cash can be transferred without permission – censorship-resistant.

Or so we thought.

Because a curious email to an obscure cryptography mailing list at the end of 2008 said something quite audacious. The email, from the hitherto unknown Satoshi Nakamoto heralded the arrival of Bitcoin and the advent of “purely peer-to-peer electronic cash”.

Super202

“A purely peer-to-peer version of electronic cash”

We all know the story of what happened next.

Except… what many people have missed is that the choice of the word “cash” in that email was absolutely critical and absolutely deliberate. What this email announced was the arrival of a digital bearer asset that is censorship resistant.  Digital cash.  A digital asset that you can hold outright, with no risk of confiscation, and which you can transfer to anybody you choose with no permission from anybody else.

And the funny thing is: the architecture of Bitcoin flows almost trivially (almost…!) from this requirement.  Proof-of-work, the peer-to-peer gossip network, mining, the mining reward, the blockchain.  The lot.  It’s as if the genius of bitcoin was to ask the question.

But why am I saying this in the summer of 2015? This exact same thing could have been said at any point from 2009 until now.  There’s nothing new here.

Except…

Nobody asks the obvious question:

Who actually wants a censorship resistant digital bearer asset?!

 Well… some people do, of course.  But none of them are banks or corporates.  At least, I’ve not yet met a bank that wants this.

So why are so many banks, corporates, VCs and startups spending so much money in this space?!

I think there are two completely distinct reasons and that that the world of “blockchain technology” is actually two completely different worlds, with different opportunities and different likely winners.  And those who don’t realise this might be about to lose a great deal of money.

First, let’s look at Bitcoin.

We should probably be realistic here.  Bitcoin is not the solution to Greece’s crisis and it won’t bring finance to the world’s poor.  But it turns out that censorship resistance is extremely valuable, even for people who don’t think they need it.

Because censorship resistance implies openness.

Anybody or anything can connect to an open network like Bitcoin to own and transfer value.  And anything that is open, standardised, owned by nobody and useful smells very much like a platform.  And we’ve seen how those stories play out.

But notice something else:  Bitcoin is worse than existing solutions for all the use-cases that banks care about.  It’s expensive. It’s slow. And it’s “regulatorily difficult”.  And this is by design.

So this makes it doubly interesting.

Because it means Bitcoin is probably worse than existing solutions for all the things most people and firms care about but vastly better for one single use-case (open access to value transfer) that could be very useful for some people.

Isn’t that pretty much the definition of a disruptive innovation?   Something that’s worse for existing use-cases but solves a niche use-case very well?

So, if this is true, we should expect to see adoption of Bitcoin come from the margins, solving marginal problems for marginal users.

But disruptive innovations have a habit of learning fast and growing.  They don’t stop at the margins and they work their way in and up.

So this is why I think so many of the big-name VCs are so excited about it.

So the incumbents should be keeping a very close eye on what’s going on.    If anything in this space is going to disrupt them, it will probably come from this world.  But it’s perfectly understandable that vanishingly few of them are actually engaging deeply in this world.

So if Bitcoin isn’t why banks are looking at this space, what are they looking at?  

How have so many people convinced themselves that there is something of interest here that is “separate” to Bitcoin or systems like it?

At this point, it’s customary to observe sagely that “of course, the real genius of bitcoin was the blockchain; that’s where the value is”.

But I’ve discovered something rather amusing.  If you push the people who say this, and ask them what they actually mean, most of them can’t!  And yet…   whether they understand why or not, they are actually on to something.

It comes down to how bitcoin delivers on the design goal of “censorship resistant” cash.

Imagine Bitcoin didn’t already exist and you were asked to design a system of censorship-resistant digital cash.  How would you do i?

Well… you couldn’t build it around a central database: the government could shut it down.  That doesn’t sound very censorship resistant.

And you couldn’t rely on a network of trusted people around the globe since law enforcement could simply collaborate to shut them down too.  And in any case, who would control the identity system that helped you be sure these people were who you thought they were in any case?

It turns out that the answer is quite unexpected… and it’s something I’d bet almost all engineers would consider completely mad.

The answer is that you get everybody who fully participates in the system to maintain a full copy of the ledger.   And every time somebody, anywhere in the world, spends some bitcoin, we’re going to inform everybody who’s maintaining this ledger and they’re going to store a copy of that transaction too.

Bitcoin essentially runs on a MASSIVELY replicated, shared ledger.  (The trick is in keeping it consistent, of course…)

It sounds insanely inefficient and expensive… and perhaps it is. But we also have to ask ourselves:  inefficient and expensive as compared to what?

And this leads us to the other world

Just look at the state of banking IT today…  Payments, Securities, Derivatives… Pick any one.  They all follow the same pattern:  every bank has built or bought at least one, usually several, systems to track positions and manage the lifecycle of trades:  core banking systems, securities settlement systems, multiple derivatives systems and so on.

Each of these systems cost money to build and each of them costs even more to maintain.

And each bank uses these systems to build and maintain its view of the world.  And they have to be connected to each other and kept in sync, usually through reconciliation.

Take even the simplest OTC derivative contract:  it is recorded by both sides of the deal and those two systems have to agree on everything for years.  Very costly to operate.

But what if…  what if these firms – that don’t quite trust each other –used a shared system to record and manage their positions? Now we’d only need one system for an entire industry… not one per firm. It would be more expensive and complicated to run than any given bank-specific systems but the industry-level cost and complexity would be at least an order of magnitude less. One might argue that this is why industry utilities have been so successful.

But a centralised utility also brings issues:  who owns it? Who controls it  How do the users ensure it stays responsive to their needs and remains cost-effective?

The tantalising prospect of the blockchain revolution is that perhaps it offers a third way: a system with the benefits of a centralised, shared infrastructure but without the centralised point of control:  if the data and business logic is shared and replicated, no one firm can assert control, or so the argument goes.

Now, there are lots of unsolved problems: privacy, performance, scalability, does the technology actually work, might we be walking away from a redundant (antifragile?) existing model? Who will build these platforms if they can’t easily charge a fee because of their mutualised nature?  Difficult questions.

But see:  this has nothing to do with funny internet money, bitcoin or censorship-resistant digital cash.  It’s a completely different world

Two revolutions for the price of one

So… the blockchain revolution is so fascinating because it could actually be TWO completely different revolutions…   both profound in their implications:

  • Censorship-resistant digital cash providing a new platform for open, permissionless innovation driven from the margins
  • And industry-level systems of record driving efficiencies for incumbents.

Neither of these are “sure things”… they are both high risk speculative bets… but they’re also very DIFFERENT bets…

[EDIT 2015-07-23 Gideon Greenspan has written a great piece that comes at this argument from a very different angle]

As ever, the thoughts and comment on this blog are mine alone and don’t represent the view of my employer….

A Simple Explanation of Balance Sheets (Don’t run away… it’s interesting, really!)

Shared ledgers could be revolutionary but do we need to share a mental model for banking to make sense of it all?

What would be your first instinct if your friend were to tell you they had £1m in the bank? To congratulate them on their good fortune? To suppress a pang of jealousy?

Wrong, wrong, a million times WRONG!

The only acceptable first instinct is to shout loudly at them: “No! You fool! You don’t ‘have’ a million in the bank. You have lent a million to the bank. They owe it to you. How could you reveal so casually that your mental model of banking is so wrong?!”

If your first instinct was the correct one then you need read no further; there is nothing for you here.  But, for everybody else, you could be missing something really important.   And this could matter: as I’ve written repeatedly, we could be witnessing the emergence of shared ledger systems in finance – blockchains, if you prefer. And they will be used to record obligations of – and agreements between – firms and people of all sorts. A more complex (and larger) example of this, if you like:

BalanceSheet11

The four-column model of shared ledgers

To make this work, we’re going to have to get a lot more precise about how we think about financial relationships. And I’m pretty sure it all comes down to having a clear mental model for balance sheets.

What is a balance sheet?

Imagine you were starting a bank. You’d want to put a system in place to keep track of the finances: how much cash do you have in the vault? To whom do you owe money? How much have you lent out? And so on.

The basics are not rocket science and there are only two key reports at the heart of this: the balance sheet and the income statement (aka the P+L).

They exist to answer two important questions:

  • What do I own and how much do I owe? This is what the balance sheet tells you. Think of it as a point-in-time snapshot.
  • How did I do in the last period? That is what the income statement tells you. Think of it as the story for how you got from last year to this year.

In this piece, we’ll look at the balance sheet, because I think it’s the one you need to understand to make sense of where shared ledger technology could be going.

And the good news is: a balance sheet is simple… it’s just a two column table:

  • You write all the things you own – your assets – in one column
  • You write all the things you owe – your liabilities – in the other column.
  • If you own more than you owe, the difference belongs to your shareholders: their “equity” is what makes it “balance”.
  • If you owe more than you own, then you’re bankrupt (“insolvent”):

BalanceSheet1

A balance sheet only has two important columns: what you own and what you owe.

Let’s open a bank! 

So now let’s imagine you’re ready to start your small bank, “GendalBank”. Your friends think it looks like a good bet so they’ve agreed to contribute towards the £1m you need to get it up and running in return for shares.

£1m to start a bank?! As you can tell, my example is going to be very unrealistic indeed…

It may be obvious but I’ll say it anyway: they have no right to ask for this money back… it’s not a loan. But if you closed the company down, anything that was left after you’d paid off all your employees, suppliers and lenders, etc., would be returned to the shareholders.

So what they really have is a residual claim on the company. That’s what equity is.  And when you look at it this way, it’s obvious that equity is a liability of the company: GendalBank has an obligation to return what’s left over to the shareholders if it ever closes down.

So GendalBank has been set-up and the shareholders have handed over their £1m. How would we draw up a balance sheet to reflect all this?

BalanceSheet2

GendalBank’s balance sheet after the shareholders have paid for their shares. (Pedants: please forgive me… I omitted the trailing apostrophe on “Shareholders’ funds”. I don’t have time to update ten diagrams… but I can assure you the mistake pains me more than you)

It’s as exactly as we’d expect. Your new bank has £1m in cash – maybe you’re holding it in a vault or perhaps you’re holding it at the Bank of England.   But, either way, this cash is now GendalBank’s… it doesn’t belong to the shareholders any more; it belongs to the company. It’s the bank’s asset now. It can use that cash for whatever it likes. So we note it down in the assets column.

And remember what the shareholders have paid for: a residual claim on the company. Well, there are no other claims on the company right now, so we record a liability to the shareholders of £1m. If we closed down right now, they’d be entitled to be paid £1m.

It bears repeating: bank capital is a liability.   And this turns out to be a really useful thing to know. Because it allows you to spot charlatans at a thousand paces… any time you hear somebody talking about capital as if it were an asset of the bank (“holding more capital” is a great giveaway) then you know they don’t know what they’re talking about…

(I can’t help thinking making statements like that opens me up for all kinds of ridicule when the faults of this piece are identified…)

Great… so now we buy some IT equipment and an office with some of that cash. So perhaps the balance sheet looks like this at the end of the first week:

BalanceSheet3

We use some of the cash to buy some equipment and an office, etc

To keep things really simple, I’m going to assume the bank has no expenses. I did say this was a very unrealistic example! So we’ll assume we own the office and that there are no employees to pay. This is just to avoid having to look at the income statement for now.

And now we’re open for business… time to make some loans…

Bob walks in off the street and asks to borrow £100k because he’s planning on buying a very nice car at the weekend. He looks a trustworthy sort so we make the loan.

And now another really interesting happens: we create money out of thin air…

BalanceSheet4

Our loan to Bob has created money out of thin air!

Now Bob hasn’t withdrawn any money yet – he’s not buying the car until the weekend, remember. But look at how counterintuitive the balance sheet has become.

Look first at the asset side: we still have £500k cash, of course: he’s not drawn anything out yet. And we see the £100k loan to Bob. That’s our asset since Bob is obliged to pay us back £100k in the coming months and years.   That’s a valuable promise to hold – it’s an asset of the bank, for sure.

Aside: just as above, I’m making some massive simplifications here, not least that I’m completely ignoring interest rates and discount rates, etc.   Humour me :)  

And now look at the liability side: it records that we owe £100k to Bob.  That’s fair enough. If he looks at his account, he’ll see £100k there that he can withdraw whenever he likes. As far as he’s concerned he thinks “has £100k in the bank”.

So we have £500k of our own cash – either in the vault or at the Bank of England. And Bob thinks he has £100k “in the bank” as well.

Hang on… what’s going on? Did we just turn £500k into £600k by updating a spreadsheet?! Or does this mean that £100k of the £500k is now Bob’s? Or what?

The way to understand this of course is to observe that the £500k is our asset , whereas the £100k is Bob’s asset – and our liability. They’re not the same thing at all and it makes no sense to compare them in this way.

And so here’s another way to spot a charlatan: if you ever hear somebody talking about bank deposits as if they’re assets of the bank, you know you can safely ignore anything that person says…   As this example makes clear, bank deposits are liabilities… and you have to be careful around them… because customers have the annoying habit of asking you to give them the money so they can spend it on something.   And, to do that, you’d better have enough cash (on the asset side of your balance sheet, remember) to be able to honour that request.

This is what people mean in this context when they discuss “liquidity” – do you have enough cash or stuff you can quickly turn into cash to meet withdrawal requests from your customers?

Aside: in many ways, this conundrum is the absolute heart of banking: how to manage the problem of issuing short-dated liabilities (e.g. demand deposits) whilst holding longer-dated assets (e.g. one-year car loans). There’s even a name for it: maturity transformation.   It obviously relies on not all “depositors” wanting “their” money back at the same time and so is inherently unstable.

But it turns out we do have enough cash on hand. So we get to live another day.

And this could go much further…. We could make lots of loans. As long as not everybody wants to take out money at once, maybe we’ll be OK. Let’s imagine lots of other customers plan to make some big purchases in the future and borrow some money from us. This is what the balance sheet would look like immediately after we’d made those loans but before any of them had withdrawn any of the cash:

BalanceSheet5

We make lots of loans and make the balance sheet bigger and bigger…

What happens if the people who borrowed the money from us want to draw out the cash? They presumably borrowed the money for a reason, after all…

Well, that’s probably OK too, at least in “good times”. Let’s say they ask to withdraw £5m between them. There’s the minor problem that we don’t actually have £5m in cash… we only have £500k. But that’s OK…   provided we’re not bust – that we’re solvent – and people believe we’re solvent, perhaps we can borrow the cash temporarily from somebody else – maybe the central bank.

So that’s what we could do:

BalanceSheet6

We borrow £5m cash from somewhere else and use it to pay the depositors who want cash. Notice “deposits” have reduced by £5m and loans from other banks have increased by the same amount. The asset-side of the balance sheet is unchanged in this example.

Of course, another thing we could have done was sell some of the loans to somebody else for cash. And that would have also reduced the size of the balance sheet… since we’d only have £5m loans remaining on the asset side.

But it’s counterintuitive, isn’t it? We set up a bank that is making lots of loans and we’ve not yet taken a single deposit!

Indeed, it’s even weirder… we’ve created deposits seemingly out of thin air by the very act of making these loans. Where else did Bob’s “deposit” come from except from the fact that we made a loan to him?   And it turns out this is a really important point. The Bank of England, no less, argues that this mechanism is the primary way money is created in the modern economy. Everything you were taught at school about how banks need to take in deposits in order to make loans isn’t actually true…    But let’s leave that debate for another day…

“Deposits”

I once wrote a piece explaining how payment systems work. I was blown away by the response: hundreds of thousands of hits, huge numbers of them from people at banks. Clearly: this stuff isn’t as obvious as perhaps it should be.

One of the key points I made in that post was the one I was hinting at above: it makes no sense to say you’ve “paid money into the bank” or that you have “money at the bank”. There’s no jar in the back office containing your money, with your name on the front. Instead, when you “deposit” money with a bank, what you are actually doing is lending it to the bank. It ceases to be yours and that cash becomes an asset of the bank. It becomes theirs, to do with as they wish.   In exchange, they make a promise to you: to give you cash in the future if you ask for it. You acquire a claim on the bank.

So let’s see how that works. What happens if and when somebody finally does make a deposit?

Let’s imagine Alice has just sold her house for £500k and needs somewhere to park the cash for a few days:

BalanceSheet7

We have an extra £500k on hand as a result of a £500k deposit from Alice.

So this works as we’d expect: we record the fact that we owe £500k to Alice – our liability – and that we have an extra £500k in the vault (or with the Bank of England) – our asset.

OK, OK, Enough! What does this have to do with distributed ledgers?!

Well done for getting this far.    Why have I written so many words and laboured so many points? Because, and as I argued recently, we could be moving to a world where agreements and obligations between firms are recorded on a shared ledger at the level of an industry or market, rather than on private systems maintained separately by each of the players.

And, if this is true, we’re going to need to represent the idea that Alice has a £500k deposit at GendalBank or that Freddie has borrowed £500k from “OtherBank”.   And this is only going to work if everybody building this systems has a deep, intuitive sense that “deposits” should be modelled as “claims against an identifiable entity” and that £500k at GendalBank is fundamentally different to £500k at OtherBank and so on. I think we need to be thinking in terms of a “four-column model” of “issuer”, “holder”, “assetID” and “quantity”:

BalanceSheet11

Will the “four-column” model be the core data structure of the shared ledger world? (This is not an original idea to me: the concept is at the heart of systems like Ripple, Stellar and Hyperledger, amongst others)

Perhaps more importantly, once you start thinking about things in this way, it becomes possible to see the outlines of how the future state could work.

One can imagine a world where the bank still records that it owes some money to its customers but the shared ledger is the place that records precisely who those people are. This is fundamentally different to using the shared ledger as a mirror (or mirroring it to the bank’s own ledger) – it’s more akin to seeing the shared ledger as a partial subledger.

And it might perhaps be something that gets adopted to different degrees by different firms.

Perhaps GendalBank just uses the shared ledger to record some balances. So we update GendalBank’s system to say that it owes £5m to somebody but that it’s the distributed ledger that records to whom. And we see on the distributed ledger (above) that these people are Charlie and Debbie. So the total (£5m) is recorded in both places but only the shared ledger keeps track of the fine-grained detail. So it becomes a logical sub-ledger for some deposits (“DistLedger below) whilst the bank’s own ledger is used to record other facts.

BalanceSheet12

Perhaps GendalBank only uses a shared ledger to record details of some accounts (“DistLedger”) and continues to maintain others locally.

OtherBank, by contrast, might go further and move pretty much everything to the distributed ledger – both records of its liabilities and assets. So OtherBank’s internal ledger is extraordinarily simple: it just records the value of assets and liabilities managed externally on the shared ledger:

BalanceSheet13

OtherBank has “outsourced” or moved all processing to the shared ledger

So what?

Let’s look at the shared ledger again:

BalanceSheet11

Imagine you’re Charlie. If you have the ability to read/write to this shared ledger, you could pay away your claim against GendalBank to any other user of that ledger without having to go through any of GendalBank’s systems. We’d have decoupled the deposit-taking and lending functions from the record-keeping, accounting, payment and trading systems.

If you were OtherBank, you could sell your loan to Freddie to somebody else and the business logic might move with the loan (the “smart contract idea): previously illiquid assets might become tradeable under this model.  As I keep saying, this space is about more than just payments, after all.

Now, obviously: there is a lot of detail here that I’ve not even touched on. The reality is going to be so much more complex than this.

But hopefully this sketch shows some possibilities for where this could be going. And, like I said earlier, none of this will happen unless we get everybody to the same page with the right mental model for how banking works…

Appendix: Aside on Regulation… what stops us going completely mad with this?

I can’t write a piece on bank balance sheets without talking about risk.   And a legitimate question is: if my analysis above about how loans are made and deposits are created is correct, what’s to stop us going completely mad and taking in huge amounts of deposits or making huge numbers of loans? Don’t irresponsible banks tend to get into trouble and need to be bailed out? Well, yes they do.   And there are (at least) two very different things that can go wrong.

Illiquidity

The first problem banks can face is one of liquidity.   Imagine lots of customers want their money back at once and the bank doesn’t actually have enough cash on hand. What happens?

As discussed above, the bank might be able temporarily to borrow the cash from somebody else. But what if nobody wants to lend it to the bank? They’d be suffering from illiquidity: the value of their assets exceeds their liabilities, so they’re not bust… but they can’t meet their obligations to repay people. Oops!

In most countries, the central bank will step in in such scenarios and temporarily lend the money to the banks.   Indeed, we might say that the ECB’s “Emergency Liquidity Assistance” programme for Greek Banks was an example of this: on the assumption (pretence?) that the Greek banks weren’t bust, the ECB lent increasing amounts of Euros to the Greek banks to support deposit outflows.

From a regulatory perspective, rules such as the Basel Accord’s “Liquidity Coverage Ratio” is an attempt to force banks to hold enough cash (or cash-like instruments) on their balance sheet for forseeable withdrawals.

Insolvency

Another problem banks can run into is insolvency – being bust.   It’s easy to see how this could happen:

Imagine that some of the people to whom you’ve lent money lose their jobs or their companies go bust and you suddenly realize there is no way they will ever be able to repay their debts to you.

Let’s say £2m of the loans you’ve written become unrecoverable. So you “write down” the loan book from £10m to £8m… since you now know you’ll only ever recover £8m.

Now your assets are worth £9.6m.   But your liabilities haven’t changed.   You still owe £10.6m to your customers and the banks you’ve borrowed money from.

You owe more than you own. Game over. Good bye. You’re insolvent.

BalanceSheet8

Your losses on loans mean your assets are now smaller than your liabilities. You’re bust

But notice something really interesting…. If you’d only lost £500k on your loans, you’d have been OK because your assets (£11.1m) would have still been greater than your liabilities (£10.6m):

BalanceSheet9

… but if you only lost £500k on the loans you’d have been OK

So you can lose some money on your assets and be OK. But if you lose too much, you’re in trouble. What determines how much you can afford to lose? The answer is capital – shareholders’ funds.

You got away with the £500k loss but not the £2m loss because of your capital.   Your shareholders took the hit. Before the bad debts came along, their residual claim on the company was worth £1m. A £500k loss takes their claim down to £500k. But in the £2m bad case above, the loss was greater than the “loss-abosrbing” cushion of £1m provided by the capital and that’s why you went bust.

And so this is why regulators are so fixated on capital: the more the bank is funded by capital rather than deposits or debt, the more resilient the bank is when they make losses on their assets. Capital can be written down to absorb losses on assets in a way that debt can’t.   It’s why you hear so much talk about “capital ratios” and the like: what percentage of your assets should be financed by capital rather than debt?

But notice: the bank is in no sense “holding” capital. You hold assets and capital is not an asset… Instead, think in terms of capital being a mechanism through which the bank is funded.

And these phenomena can interact:  if you are illiquid, you might need to sell lots of assets a “firesale” prices, turning a liquidity problem into a solvency problem.

[Update 2015-07-05 My description of insolvency is *very* simplified, as Ken Tindell has noted here… https://twitter.com/kentindell/status/617719608875872256]

Quick notes on Sidechains “Elements”

I’ve written a lot recently about the potential of replicated, shared ledgers that are private/semi-private. For example, I suggested that industries with duplicated systems across firms might get benefit from adopting this technology.  But I also keep an eye on what’s happening in the Bitcoin world.  So the BlockstreamElements” launch caught my attention this week.

I wrote about the idea behind sidechains late last year and so it’s interesting to see parts of the vision turn into real code. Back then, I said that a way to think about this is as a system that lets you “move” bitcoins from the Bitcoin blockchain onto another bitcoin-like system and back again in a way that doesn’t harm the Bitcoin network and doesn’t require you to trust a central entity like a Bitcoin exchange.

Why would you want to do that?

  • First, it could be a good way to prototype proposed changes to the core Bitcoin protocol with lower risk: the change could first be implemented and tested on a sidechain, a relatively safe environment. And, should the new system work well, those who needed the feature could transfer their coins to that sidechain, knowing they could bring them back again in the future.
  • Secondly, and looking further ahead, this approach could also provide a migration path for existing bitcoin holders to a new version of the network – offering an alternative to a hard-fork.

It’s an attractive idea and one can intuitively sense why it could be valuable. Of course, the idea is not perfect. Developers such as Peter Todd, have argued that sidechains would be vulnerable to attack under various circumstances. But, leaving that to one side for now, what was announced this week and what does it mean?

Sidechains Announcement

What follows is deliberately brief in order to share thoughts quickly:

  • A sidechain is now up and running and accessible from the Bitcoin testnet.
  • The sidechain can be thought of as “just like Bitcoin” (or just like Bitcoin testnet) but with several additional features, or “elements”.
  • These elements include features such as “confidential transactions” and “relative locktime” (full details here and I explore two in a little more detail below)
  • A mechanism for moving coins to and from the sidechain is up and running… but this mechanism currently relies on a network of semi-trusted oracles, or “functionaries”, to validate the return of coins to testnet. This is because the necessary changes to enable this in a decentralized fashion do not yet exist in Bitcoin and one should remember there is no guarantee such a change would ever happen
  • The sidechain is also currently secured by this network of functionaries”. I understand this is a temporary situation but one could argue it means the distinction between permissioned and permissionless ledgers could be becoming somewhat blurred. Preston Byrne of Eris Industries has said something similar.
  • The code is open source so other people could set up their own sidechains and run their own functionaries.
  • In what I think could be a smart move for gaining mindshare, blockstream have signed up several universities with Bitcoin projects/programmes, such as MIT and Princeton to run these “functionaries”.

Elements

The individual features being explored initially have been called “Elements

Of particular interest to my readers might be Confidential Transactions and Issued Assets.

Issued Assets is an attempt to add support for Colored Coins-style assets to the core protocol. This is the one feature that is not yet deployed to the sidechain but it is also one of the most intriguing. I’ll be watching for comment from those projects in the coming days.

Confidential Transactions are a very clever application of cryptography to hide the value of transactions whilst still allowing them to be fully validated by the network. If this works well, it could be a partial solution to the confidentiality issue faced by Replicated, Shared Ledgers.

The fundamental characteristic of these systems – both permissioned and permissionless – is that multiple copies of the ledger are maintained and that these copies are widely distributed. Without features like Confidential Transactions (or related technology such as ZeroCoin or ZeroCash), these systems may be  unsuitable for those with confidentiality and privacy requirements. Do you want everybody in the network knowing your positions?

Based on what I’ve read so far, I’m not sure this is a full solution – financial firms care about more than just the value of transactions – but it’s a good start.

Next Steps

The test for me in coming weeks will be the extent to which non-Blockstream developers engage with this and other sidechains. I’ll also be paying particular attention to the Bitcoin Dev mailing list to see if any debate begins about making changes to the core protocol to allow decentralised pegging to work directly.   [Update 2015-06-11 to correct pegging terminology. Thanks to joeykrug for the correction]

Towards a Unified Model for Replicated, Shared Ledgers

Don’t Say The “B Word”!

I’ve come to the conclusion that saying “blockchain” has become unhelpful. It just confuses people. It means too many different things to different people and so it’s almost impossible to have a conversation in this space without talking past each other. So, as I argued in this piece on permissionless ledgers and this piece on permissioned ledgers, it can be useful to talk in terms of replicated shared ledgerssince I think this gets to the heart of what unifies – and separates – these two worlds.

  • Shared: because multiple actors can read or write to different parts of the ledger
  • Replicated: because everybody who needs a copy can have a copy, rather than relying on a powerful central entity

In this piece, I try to bring it all together – to explain why we should be thinking about permissionless ledgers as a classic example of disruptive innovation and how I think banks could think about permissioned ledgers in the interim.

In what follows, I build up the model below from its constituent parts:

RSL5

A unified model of permissioned and permissionless ledgers?

Permissionless Ledgers: Censorship Resistance

Let’s be clear: the breakthrough of Bitcoin was to create the closest system yet of “digital cash” – something that you can own outright and transfer to anybody else without permission. Its design flows naturally from that objective:

RSL1

Bitcoin’s design follows directly from its objectives. Its replicated, shared ledger is designed to enable the existence of a censorship-resistant digital bearer asset  

As I argued here, it’s little surprise that bankers and regulators look at it with deep suspicion! However, there’s a good reason why the smart observers aren’t dismissing it: censorship resistance implies an open, neutral platform that could be a driver of permissionless innovation:

RSL2

Censorship-resistance enables permissionless innovation in digital ownership  

So, it’s not a surprise that we’re seeing innovation and experimentation in the fields of value transfer – such as micro-micro payments (nanopayments?) for video content – and in the recording and execution of agreements.   This is, almost but not entirely, exclusively being driven by people from outside the traditional financial sector. They’re taking a platform that is, in most meaningful ways, slower and more expensive than today’s financial system and using it for novel purposes.

I think the smart firms are keeping an eye on this because they know how stories like this end:

“Disruptive innovations usually find their first customers at the bottom of the market: as unproved, often unpolished, products, they cannot command a high price. Incumbents are often complacent, slow to recognise the threat that their inferior competitors pose. But as successive refinements improve them to the point that they start to steal customers, they may end up reshaping entire industries” (The Economist)

Permissioned Ledgers: Industry-Level Systems of Record  

Notwithstanding the promise – or threat – of permissionless systems, I sense that many financial firms are looking closely at permissioned systems, by which I mean technologies that allow multiple firms to run a private, shared ledger of some sort.   What most people fail to ask is: why?! If you don’t have censorship-resistance as your business objective, why are you looking at this space at all?

The answer, I argued, in this piece is that replicated, shared ledgers can also solve a different problem:   if you’re in an industry where multiple firms all run similar systems to keep track of records (account balances? derivatives positions? orders?) then you’re probably carrying cost you don’t need: everybody is paying to maintain these duplicated, non-differentiating systems. And, because they’re all slightly different, you need to reconcile them with each other all the time to make sure they agree.

So the argument for applying replicated, shared ledger technology to this problem is that you could mutualise the cost of running and securing a single logical ledger, copied across your firms so you each have your own copy and so aren’t reliant on a powerful central entity for access. So nothing to do with censorship-resistance and nothing to do with cryptocurrencies.   The idea, instead, is to move from each firm having its own systems of record to having systems of record at the level of the industry:

RSL3

Is the promise of permissioned ledger the possibility of industry-level systems of record without a powerful central gatekeeper?

But we can take this thought-process further. Imagine such a platform existed: perhaps a replicated shared ledger that recorded all inter-bank balances or recorded all derivatives positions between firms.   What we would effectively have is a transaction processing system for that industry: if we all agree that this shared ledger is authoritative for records (e.g. who owes what to whom) then could we not also agree that this ledger is something to which we could deploy code that describes our agreements? Could this industry-level ledger also host inter-firm business logic? How much cost and complexity might that remove from firms?

RSL4

Is a common ledger between firms the enabler for a common transaction processing platform for an industry?

And this is where, I think, the two worlds – those of permissioned and permissionless ledgers – come back together:

Unifying the worlds of permissionless and permissioned ledgers

In the permissionless world, some of the most interesting developments are happening at the level of transaction scripting and smart contracts. The Ethereum project is the most obvious example, of course, but even projects like Streamium are showing how Bitcoin features can be used to create interaction models that simply aren’t possible on today’s financial platforms.

Similarly, and as I argued above, the driver of innovation on permissioned ledgers might be the migration of inter-firm business logic from individual firms to a shared ledger between firms: think of code that represents an agreement between two firms, that executes “on” a ledger, which can take custody of assets on that ledger and execute in response to external events: if both firms have signed it off in advance, suddenly they don’t need all the cost and expense of their own systems.  I wrote about this idea in my piece on smart contracts.

So we see that the two worlds of replicated, shard ledgers – permissioned and permissionless – might actually be leading us to the same place: a world where business logic for money – automated fiduciary code, if you like – is deployed to a shared ledger and run autonomously.    

RSL5

Perhaps the permissioned and permissionless worlds aren’t as different as they seem?    

Blockchain is where banks have the most obvious opportunity. But you ignore Bitcoin at your peril

Nasdaq’s recent announcement shows you need a strategy for both

I have argued for some time that the world of “blockchains” is actually two worlds: the permissionless world of “bitcoin-like systems” and the permissioned world of “ripple-like systems”. The reason we so often talk about them together is because they share a common architecture: the “replicated, shared ledger”.

But they solve very different problems. Tim Swanson has written about the permissioned-ledger world and my last post gave an argument for why banks, in particular, should be paying close attention to them.

But this observation can be dangerous if people believe they are building a “blockchain strategy” for their firms when they are actually focusing only on the permissioned world.

As this exchange between Jerry Brito of Coin Center and Michael Casey of the Wall Street Journal shows, Nasdaq’s recent announcement of a blockchain experiment is noteworthy because they are explicitly building on Bitcoin, using a colored coins protocol, not on one of the permissioned/closed ledgers:

I have no inside information into this project. But it should give pause to any who had dismissed bitcoin-based platforms as being irrelevant to finance use-cases.

Forget Bitcoin at your peril?

As I argued in my last post, the world of permissioned ledgers is pretty easy to think about: if you’re in a market where multiple firms in the industry are all building and maintaining undifferentiated systems that do pretty much the same thing – and they have to be reconciled with each other – then it can make sense to replace them with a single system that you all share. But if you’re concerned about having a single central operator then these new blockchain technologies give you an option that didn’t previously exist: you can implement the common infrastructure on a replicated, shared platform that you all help secure/maintain and so mutualise the effort of maintenance rather than delegating it to a separate entity.

But, all too often, the analysis starts and ends there and disregards the “bitcoin-like” world. To see why this could be dangerous, we need to go back to the beginning.

The first nine words of the abstract to the Bitcoin whitepaper tell you everything you need to know to understand its architecture:

Bitcoin 1

Everything you need to know to understand Bitcoin

“A purely peer-to-peer version of electronic cash”

Those nine words seem innocuous but they have profound implications and explain why so many people still steer quite clear of it. The key is “electronic cash”. What can you do with cash that you’d need to emulate in an electronic version?

  • First, cash is a bearer asset. The only way somebody can take away the money in my pocket is by confiscating it from me. Nobody in a central bank can “delete” my cash whilst leaving everybody else’s untouched.
  • Secondly, cash is a peer-to-peer instrument: I can pay you directly. There are no third parties we need to rely on, assuming we’re physically co-located

There’s a phrase for this set of requirements: censorship resistance. A true system of digital cash can only work if it is censorship resistant.  And Bitcoin’s architecture does a pretty good job of achieving this through a very novel architecture. I sketch out some of the details for interested readers at the end of this article.

There’s just one tiny problem…

Censorship resistance is not an objective that is shared by most governments, regulators, banks or most individuals! No wonder there is so much controversy around the system. Perhaps it’s just easier for respectable firms to steer well clear.

And it gets worse when one observes that Bitcoin is worse than existing digital money in pretty much every significant way! It’s slower, it’s more expensive to operate, its value jumps all over the place and it’s really hard for consumers to use safely. So ignoring it is perfectly understandable.

But it could also be a mistake.

Permissionless Innovation

Because it turns out that censorship-resistance implies an even more interesting property: permissionless innovation.

“Permissionless innovation”—the general freedom to experiment with new technologies and business models—has been the secret sauce that fueled the success of the Internet and the digital economy

Think back to the design goal for the bitcoin system: electronic cash. And how that implied a need for a censorship-resistant bearer asset. These scary properties from a regulatory and banking perspective imply some very interesting properties from a technical perspective: this is the world’s first asset that can be held by anybody or anything and transferred to anybody or anything without needing permission.

Why could that be interesting?  Let me sketch three simple scenarios:

The Internet of Things

How do you do KYC on a fridge? Do you really want your washing machine having your credit card details on file? Perhaps the future of machine-to-machine payments is one where the machines hold their own assets on an open system. Sure: you could build a permissioned payments system for device-to-device payments but the simplicity and open-access nature of Bitcoin could mean that it’s just easier to do it that way.

Firms for whom payments are a secondary concern

We often make the mistake of viewing this space through the eyes of incumbents. It can be useful to put ourselves in the shoes of others. For example, imagine you’re building a business for which getting a bank account and payment processing services would be difficult. Maybe you plan to operate in tens of countries. Or perhaps payments are a secondary concern for one of your use-cases… you just need a quick and easy way to make and receive payments. Sure… you could go through the process of getting a merchant account, signing up with a payment processor, proving compliance with various security standards. Or you could just use something with no barrier to adoption: bitcoin may have lots of problems but at least you can be up and running in seconds.

Second-order use-cases

Perhaps the most interesting future scenario is one where bitcoin isn’t used for payments at all. Instead, the security and censorship-resistance of its platform is seen as having value in and of itself – perhaps for notary services in the first instance – recording facts about the outside world – and so Bitcoin becomes nothing more than the token you need to own in order to purchase the services of the network.  It becomes an app-coin, if you like.

Why we need to keep an eye on the Bitcoin world

I accept that none of these use-cases is particularly compelling as I write this piece. There are lots of great counterarguments for all of them. But that’s partly the point: if any of these were obvious, nobody would be dismissing it.

And this is why I find the Nasdaq example so interesting.   Using the inherent security and open-access of the Bitcoin system to “carry” representations of real-world assets – “colored coins” – is an old idea*.  And it also fits into my “second-order use case” category above.

Now, Tim Swanson and others have written convincingly about many theoretical issues with the idea but we now have a brand-name firm experimenting for real and we’ll hopefully all learn from the exercise in time.

So, sure: bitcoin raises all kinds of conceptual, legal, technical and philosophical questions. But it would only take one of these scenarios to drive some adoption and, very quickly, bitcoin might cease to be a sideshow.  And, given that its core design goal of censorship-resistant digital cash has such disruptive potential – good and bad, this possibility alone is reason to keep an eye on it. Dismissing it entirely could be a big mistake.

Coda: How to build a system of digital cash

Note: you don’t need to read this section to understand the main argument of this piece.

Recall the implications of a true digital cash system: censorship resistance. This drives some very strong implications for anybody trying to design such a system:

First, you simply can’t have the concept of an issuer in such a system: the issuer could selectively choose to honour only certain claims.

So, if you can’t have an issuer of the currency on such a platform, it will have to be native to the platform. Hence Bitcoin as the currency unit and the interminable debates about why it has value and what that value should be, if anything.

Bitcoin 2

If you want true electronic cash, there can’t be an issuer. So the asset has to be native to the platform

Secondly, you can’t have an identifiable operator or processor for such a system, either: they could choose to block certain transactions and their central database would be an obvious target for those seeking to exert control. So this means you need to have lots of actors providing the processing services and they need to be able to join and leave. And they probably also all need their own copies of the ledger – we can’t have a single central one, after all:

Bitcoin 3

If you want true electronic cash, its ledger will have to be massively replicated and you’ll need a large pool of “processors”

Thirdly, you’ll need to pay the processors. You obviously can’t pay them with “real” money (since the issuer of that money could simply refuse to allow payments to be made to processors who refuse to co-operate with them). So you’ll need to pay the processors with the platform’s own asset:

Bitcoin 4

If you want true electronic cash, the processors will need to be paid in the currency of that platform.

The breakthrough of bitcoin was figuring out how to put these building blocks together: how to ensure sufficient scarcity of the currency unit? How to keep the multiple ledgers synchronized? How to ensure the processors’ incentives are aligned with those of the users of the system? And so on.

There’s more than one way to talk about it

Of course, this isn’t the only way to think about the system.  If you’re still interested, here’s my attempt to explain how it works by imagining how you could invent digital cash using an email system.

*Disclosure: I am an adviser to a colored coins firm (ChromaWay) in a personal capacity, albeit one that uses a different architecture to the one apparently being explored by Nasdaq