Bitcoin as a Smart Contract Platform

Distributed Ledger Platforms may be Getting All the Hype but the architecture of Bitcoin is more sophisticated than many people realise

I was a guest of the Financial Services Club Scotland last week. I presented an update on the world of cryptocurrencies to an engaged and well-informed audience in the library of the Royal College of Physicians.

I reprised my current theme that the world of “blockchains” is really two distinct worlds – the world of Ripple-like ledgers and the world of Bitcoin-like systems – that happen to be united by a common architecture, the Replicated, Shared Ledger. This unifying concept is based on the idea that each participant has their own copy of the entire ledger – and they trust the “system” – whatever system that is – to ensure their copy is kept in sync with everybody else’s.  The differences are about what the ledger records and how it is secured.

Bitcoin-like and Ripple-like systems

Broadly speaking, Ripple-like systems are focused on the representation of “off-system” assets and are secured by identifiable entities. Systems like Ripple, Hyperledger and Eris are broadly in this world, I think. The security model of these systems is based on knowing who the actors are: if somebody misbehaves, we can punish them because we know who they are!

Bitcoin-like systems are more focused on “on-system” assets and are secured by an anonymous pool of actors. Bitcoin and Ethereum are broadly in this space, I think. The security model here is based more on game-theoretic analyses of incentive structures: the goal is to make it overwhelmingly in the actors’ financial interests to do the “right” thing.

There is, of course, some ambiguity since all platforms have some notion of “smart contracts” – or otherwise recording real-world agreements, as well as asset ownership.  But this makes intuitive sense.  If your platform is concerned with real-world assets and agreements then you necessarily need some concept of identity (who are the issuers?). And if you’re reliant on the performance of real-world actors, why not also rely on them for the overall system security?   Likewise, if the whole purpose of your platform is to create and manage a new asset that can be controlled/subverted by nobody, then giving identifiable entities the power to control your security would seem to defeat the point!

Different design goals, different implementations.  And the value of such systems to banks, corporations or individuals is, ultimately, an empirical question. I imagine 2015 will be the year where we discover many of the answers.

Incrementalism versus “Disruption”

But I went further in my talk. I observed that these two worlds also differ in one other respect: the Bitcoin-like systems could be disruptive to existing institutions if they gained widespread adoption, whereas Ripple-like systems seem, to me, to be far more closely aligned to how things work today and are, perhaps, a source of incremental innovation.

If this observation is correct, then firms looking at this space probably need to assess the technologies through different lenses. The question for banks for Ripple-like systems is: “how could we use this to reduce cost or improve our operations” whereas the question for Bitcoin-like systems is: “how would we respond if this technology gained widespread adoption?”

And to answer the last question, one must be sure to really understand what the system under analysis really is!

Bitcoin as a currency might be to miss the point

For me, it is a mistake to think about Bitcoin solely as a currency. Because the Bitcoin currency system is a masterclass in mirage: underneath the hood, it’s a fascinating smart contract platform.

Or, as I said at the Financial Services Club, every time you make a Bitcoin payment, you’re actually asking over 6000 computers around the world to run a small computer program for you… and your only task is to make sure that the computer program returns “TRUE”.    Within the Bitcoin community, this is well-known, of course.  Indeed, the work done by Mike Hearn and others to document the platform’s capabilities has been around for years.  But I find most people in the broader debate are unaware that the platform is pretty much built on this capability – it’s not an add-on.

Bitcoin is a smart contract platform

I wrote a piece last year offering an intuition for how Bitcoin works, in terms of land. My point was that the fundamental building block of the system is the “unspent transaction output”, or UTXO.   The UTXO is what you get when somebody “pays” you some Bitcoin.  The “output” of their transaction is the money they paid to you. And whilst it sits in your “wallet”, it is, obviously, unspent. Hence “unspent transaction output”.

So you can think of the current state of the Bitcoin system as being a huge pool of UTXOs: all the payments that have been received by Bitcoin users that they have not yet spent:

BitcoinSmCon4

Every payment that has not itself been spent is modeled in the Bitcoin system as an “unspent transaction output”. In general, each UTXO can only be spent by the owner of the “address” to which it was sent (not always, and this is the point; see later).  And each UTXO has an identifier (the transaction it appeared in and its position in the list of outputs of that transaction) and a value: how many Bitcoins are represented by that UTXO.

But what people often miss is that these UTXOs are actually tiny little computer programs that live on the ledger, control access to bitcoins and run in response to specific incoming events. Smart Contracts, if you will. And the only way you get to spend the money controlled by that contract is if you can provide some input data that allows every node on the system to execute the program and check that it returns “TRUE”

If you can make the program return “TRUE”, you get to say what happens to the funds. If you can’t, then you don’t.

So, when you want to spend your money, here’s what you do:

Your wallet software writes a little computer program for you and then sends it into the bitcoin network. It effectively says to the network: “Please run this little program I’ve just given you.  Then please find a program (“smart contract”?) on the platform with this ID for me. When you’ve done that, feed the output from my program into program you just located”.   So this is a two step process:  you provide your own little program… and the output of that is fed to the UTXO program that you want to spend.

BitcoinSmCon2

The way you spend money in Bitcoin is to ask the platform to run a small computer program that you provide and feed the output of that program to the “smart contract” that is storing the funds you want to spend. If you can make this second program run successfully, you get to spend the money. In Bitcoin terminology, the program you provide is “scriptSig” and the UTXO program is “scriptPubKey”. Your goal is to provide a “scriptSig” whose output can be fed into “scriptPubKey” to make it return “TRUE”

So what are these little programs? In the common case, they’re really simple. The “UTXO program” simply says: “provide me with a digital signature that proves you own the key associated with the following Bitcoin address (and please also prove that you know the public key that corresponds to the bitcoin address)”. That’s why it’s called the “scriptPubKey”.

And the program you provide is just a way to ensure the bitcoin system sends this proof into the scriptPubKey program in the right way. It’s a way of providing a digital signature. Hence it’s called the “scriptSig”

If you don’t know the private key then you can’t generate the right signature and so you can’t create the input necessary to get the smart contract (scriptPubKey) to run successfully and you don’t get to spend the funds. So this, seemingly complex model, is just a way to ensure that the only person who can spend money at address 1abcde… is the person who knows the private key… exactly as we would want.

Why is it this complex?

But notice how powerful this is…   because the other thing you do is tell the system to replace the existing scriptPubKey program with one or more new programs. And this is how your payment is modelled in the system.  You pay somebody by creating a new program (a new scriptPubKey) that only they will be able to execute successfully.  In this way, you can pay different people or send change back to yourself.  The program that only you can run is replaced with ones that only the payees can run.  And, in this way, the value has been passed from you to them.

So the result is that the original program living on the ledger is replaced by one or more new programs. In the usual case, one or more of these new ones will be associated with somebody else’s bitcoin address so only they will be able to control it. You have, in effect, paid them that money since the funds are now under their control

BitcoinSmCon3

Paying somebody in Bitcoin is the same as replacing the program you control with ones they control. In this diagram, the funds you controlled have now been split between two new recipients. Only they can spend those funds.

Smart Contracts?

So what does this have to do with smart contracts?   The key is that the model I outlined above is quite generic.   The programming language is (just about) powerful enough to implement some interesting business logic that goes beyond “Richard paying money to Bob”.   For example, you can write a program that will only return “TRUE” if you provide proof that you know the private key to multiple bitcoin addresses.  This is a way to model “a majority of Board Directors must jointly sign before these funds can be spent”, perhaps. The Bitcoin “contracts” wiki page goes into far more depth.

However, the reality is that the capabilities of the platform are actually quite constrained – and I think this explains a lot of the interest in other platforms, such as Ethereum.  However, it should be noted that Gavin Andresen has argued that Bitcoin’s limitations need not be a constraint.

So what?

Some might argue that it’s not necessary to think about Bitcoin in this way. But I think that would be a mistake. Because, while lots of people are getting excited about the potential of smart contracts for business, we’ve had a sophisticated smart contract platform running quite successfully for over half a decade, in the form of the Bitcoin network.

Sure – it’s very limited (that’s why systems like Ethereum are getting built).   But it might be a mistake to bet that it won’t evolve.

Ultimately, my point is this: even if there’s a low probability of success for a potentially disruptive system, it surely makes sense to understand everything possible about what that system can actually do…

[Disclosure – I provide advice to Hyperledger in a personal capacity.]

[Update – 2015-03-30 Typos and replaced first diagram… I accidentally included an older version that used random IDs for UTXOs that looked like bitcoin addresses, which was very confusing…]

Advertisements

A Central Bank “cryptocurrency”? An interesting idea, but maybe not for the reason we think

The retail use-cases get all the press… but the killer-app for digital central bank money might be smart contracts

This post on a concept called “FedCoin” by David Andolfatto of the St Louis Fed raises the really interesting possibility of a world with central-bank-issued digital assets which can be held by a broad range of people.

FedCoin

Andolfatto’s FedCoin post

The core idea is essentially a variation on the digital cash theme: a digital bearer asset that is redeemable for dollars. So, on the surface, just like m-pesa but for dollars, right?

Not quite. Because Andolfatto’s FedCoin idea has two important differences.

  • First, FedCoin would be issued by the central bank. That contrasts with most other digital cash systems, where the holder has a claim against a telecoms firm or a commercial bank. In those systems, you have to trust the central bank not to inflate away the currency (as you do here) but you also have to trust the commercial issuer not to go bust – or any deposit insurance scheme to bail you out if they do. A central bank digital asset doesn’t have that second issue.
  • Secondly, Aldolfatto suggests this currency could be issued on a distributed ledger. As he writes in an update to that post, many people have questioned why that might be necessary. Surely if you trust the fed enough to hold its currency, you trust it to run an accounting system!   However, I wouldn’t dismiss this suggestion just yet, as I’ll argue below.

Robert Sams has an intelligent and thoughtful analysis of the overall idea.

So why am I writing about it now?

It’s not just the US: what about the Bank of England?

No sooner had the FedCoin idea been discussed and dissected, the Bank of England published its 2015 “Research Agenda”: a paper summarizing all the questions they plan to examine this year.

Turn to page 31 and guess what… there’s a section on Digital Currencies. If you haven’t read it, I urge you to do so. Because it doesn’t say what one might expect it to. Most official papers on “digital currencies” are influenced by Bitcoin and talk about volatility, monetary questions, the tedious question of whether cryptocurrencies pass the “money test”, regulation and so forth.

This paper doesn’t. Instead, it follows the same line of reasoning as Andolfatto and focuses directly on the question of what a central bank-issued digital currency might mean. And the paper does something really valuable: it lists a set of questions that anybody planning to do something in this space would have to answer.

Bank of England

The Bank of England’s Research Questions for a Central-Bank-issued digital currency

And these are important questions. Imagine something like FedCoin was built and you were able to hold a digital asset that represented a claim on the Bank of England or the Federal Reserve. The implications for commercial banks could be huge: why would you lend your money to (aka “deposit with”) a retail bank if you could hold the same money in a counterparty-risk-free form?

So the commercial banks would probably have to compete for your deposits with higher interest rates. But wouldn’t that make them more risky and more likely to fail?   So perhaps the central bank would have to charge you to hold their digital asset (a negative interest rate?) to encourage you not to hold too much of it and lend the rest to the commercial banks. But now the digital “cash” isn’t the same as physical cash…

And there’s another question. If everybody has access to central bank money, then why do we need payment systems? I wrote a simplified explanation of how money moves around the banking system a while back – and the noteworthy thing about it is that pretty much all of the payment infrastructure in the world exists because most money isn’t central bank money. If you imagine a world where everybody holds central bank money, suddenly the picture begins to look a lot simpler…

Central Bank Money for all

Do you need need most payment systems in a world with only FedCoin…?

There’s more… Do we really want people having access to unlimited amounts of digital bearer assets denominated in GBP or USD? Do central banks have the culture, systems and experience to oversee such a scheme and spot misuse, fraud and crime?

So perhaps a hybrid implementation, would emerge where consumers have to nominate a “sponsoring” commercial bank, which provides safekeeping services, has oversight responsibilities and, perhaps, has the ability to block suspicious transactions?

Who knows.   And I should stress that I don’t think anybody is proposing a system like this in any case…. These are research questions.   But it suggests that the BOE questions are a very good starting point for thinking about these issues.

A solution looking for a problem?

But there’s a small issue: this intellectual exercise is fascinating but is a central bank digital currency actually needed?   With a few notable exceptions, depositors don’t tend to lose their deposits when commercial banks fail. (But businesses and other large depositors often do…) And aren’t capital rules and prudential supervision designed to solve that problem in any case?

Remember I said the “distributed ledger” aspect of FedCoin was interesting…

Think back to the Andolfatto piece. He mused about building “FedCoin” on a distributed ledger.   On its face, that doesn’t seem to make much sense.

But if we open the topic of distributed ledgers, it also brings Smart Contracts into play. In my recent piece on the topic, I suggested a definition for a smart contract as follows:

“A smart-contract is an event-driven program, with state, which runs on a replicated, shared ledger and which can take custody over assets on that ledger.”

Implicit in my definition was that these “assets” could be native assets to the ledger (e.g. Bitcoin). But , more likely, they would be representations of real-world assets: GBP tokens issued by Barclays or HSBC or Coop, say.

For example, you could imagine consumers paying £50 a month into a “mobile phone insurance smart contract” and, if they can provide proof that they’ve lost their mobile phone, the smart contract will pay out enough money to replace the phone, using the funds that have been paid in by all the policyholders.

Perhaps the “proof” would be in the form of a “proof of purchase”, signed by a retailer and an “attestation of loss”, cosigned by the policy holder and a police officer. The details here don’t matter too much.

But what does matter is the payment.

How would you write a contract like this so that it could be sold to as many consumers as possible?  They probably have accounts with different banks and, if we imagine a world of distributed ledgers, they’d all be holding different tokens: GBP-Barclays, GBP-Coop and so on.

Which tokens should an insurance contract accept from its customers?   Only tokens issued by “safe” banks? Which ones? Who controls the list?   What about a £1000 IOU from me? Would the smart contract accept that?   What about a £1000 IOU from a billionaire?

What happens when the contract pays out?  If you had paid in GBP-Barclays, how would you feel about receiving an arbitrary mix of GBP assets when you made a claim, based on whatever happened to be in the pool at the time?

Too many issuers

Writing a smart contract that deals with GBP issued by multiple issuers gets complicated very quickly…

Systems like Ripple solve this problem by explicitly modeling the idea of an asset and its issuer. 50 GBP-Barclays is different to 50 GBP-HSBC and Ripple is built on that insight.   So you could certainly configure the contract to trust some issuers but not others.

But it gets complicated. What happens if one of those issuers gets taken over? Goes bust? Who updates the list of “trusted” issuers in the smart contract?

And now, scale the problem up to the institutional side of the world, where the sums involved in derivatives contracts are enormous. Suddenly the identity of the issuer really matters.

And this is where I think a central bank digital currency could make sense on a distributed ledger. It would clear away all that complexity.

You could simply write the contract to demand payment in the central bank token.   Policyholders would have the responsibility of converting other GBP assets into the central bank issued asset.

Now, perhaps this wouldn’t be a problem in real life – maybe you could just write the smart contract to only accept GBP-Barclays, say, and insist customers of other banks convert into Barclays tokens in order to use the contract.   But having a counterparty-risk-free representation of fiat currencies on these smart contract systems feels like it could be extremely useful.

But time will tell, as always.

The “Unbundling of Trust”: how to identify good cryptocurrency opportunities?

Decentralization and centralization are two ends of a continuum. Look for opportunities to disaggregate “bundles of trust” to identify good opportunities in the cryptocurrency space

There are so many potential uses for cryptocurrency technology. But how do you know if any of them are good ideas? Blockchain-mediated financial exchange? I have a good feeling about that one. A bank-sponsored local currency system for small businesses? My sense is that it’s probably a terrible idea. But short of going out and building it, how would you know?

So are there any test you can apply beforehand to figure out if a blockchain is a good technical solution for a given problem?   And can you turn a bad idea into a good idea?

It’s a topic that comes up regularly when I present to audiences on Bitcoin and cryptocurrencies. Here are some slides I often use in these discussions. Slide 15 is where I discuss this topic.

Slides I sometimes show when presenting on cryptocurrencies. These represent my views, not IBM’s. But they are Copyright IBM. Please do not reproduce without asking permission first.

For me, the key to deciding if an idea is good enough is the one I’ve summarized on page 15 of the deck: this space is all about decentralization and if your problem isn’t about centralization then this technology may not be for you.

That may sound obvious. But internalizing this point is the key to understanding what a good cryptocurrency use-case looks like. And how to turn a bad one into a good one. Because even if your problem looks centralised, there may be portions that don’t need centralised trust and unbundling those components could be the key to doing something valuable. Here’s what I mean…

Go back to the beginning: what problem was Bitcoin designed to solve?

Bitcoin was invented as an answer to a decades-old question:

How do you come to consensus about some facts with a large group of people when you don’t know each other and some of you are cheating?

In Bitcoin’s case, the “facts” are “who owns what?”

And one answer to that question is, of course: “we all agree to trust somebody (e.g. a bank) and now we don’t need to trust each other”. But the obvious problem is: you have to trust the bank and that’s a potential point of failure. The breakthrough of Bitcoin was in showing us how to answer this question in a way that doesn’t require us to trust any single third parties.

We say the system is “decentralized”, as a shorthand for this concept.

(As an aside, I explained Bitcoin from first principles in this post on how the counter-intuitive genius of Bitcoin is that it works by going slow! For those who want to go even deeper, I share a way to think about the confusing “Unspent Transaction Output” concept in Bitcoin through an analogy of land.)

This is why Bitcoin is often positioned as being a decentralized equivalent to the centralized banking system:

decent1

Bitcoin allows us to agree who owns what without having to know each other or trust anybody else. This is the opposite of the traditional system where everybody has to trust their bank

Bitcoin-as-envisaged isn’t what we have

But there’s a problem: Bitcoin-as-envisaged isn’t what we have today. Phenomena such as mining centralization and the use of SPV Wallets mean that Bitcoin isn’t completely decentralized. It’s not currently a problem but one can already see its effects. For example, some miners refuse to mine certain types of transactions. The effect on average confirmation time for these transaction types might be marginal but it exists, nevertheless.

So Bitcoin-today is somewhere in between. It’s not 100% decentralised yet nor is it centralized.

decent2

Bitcoin today is neither fully decentralized nor is it centralised

So it seems reasonable to consider that centralization may actually be a continuum rather than an either/or phenomenon:

decent3

Are centralization and decentralization actually two ends of a continuum?

This way of thinking can be helpful because it allows us to think about other innovations in this space, such as Smart Property.

Smart Property

I’ve written in the past about a decentralized securities systems being built “hidden in plain sight”. The key idea here is that you can use blockchain platforms (like colored coins or counterparty, etc) to track the ownership and transfer of real-world assets. What distinguishes these platforms from Bitcoin itself is that they have to bridge to the real world: the asset could be a bond with a corporate issuer, being kept safe by a custodian bank, for example.  So there are several real-world entities on whom you depend.

I’ve written about how smart property allows these two roles to be merged (the issuing company could do both) but somebody has to do it – let’s just call them issuers.

So this system has points of centralization (the issuers) and points of decentralization (the ownership tracking and exchange). So perhaps it sits somewhere here on the continuum:

decent4

Perhaps there is value in different “degrees” of decentralization for different business problems

You can have more than one type of decentralization in a single service

But it’s actually more interesting than that. Because not only do smart property systems sit somewhere on the decentralization continuum, the key point is that different parts of the systems sit in different places:

  • the ledger, exchange and transfer system use the underlying Bitcoin consensus system – so they’re all pretty decentralized. No need to depend on any trusted third parties.
  • But you do, of course, have to trust the issuer.  That part of the proposition is centralised

So the important thing about smart property systems is that the all-or-nothing “trust bundle” is unbundled: you need to trust a specific issuer but the ledger, exchange and transfer functions are decentralized in their operation.

The unubundling of trust

And I think that’s what gives decentralised consensus systems some of their power: you can now break down products and services into their constituent elements of trust and implement each one with the most appropriate degree of centralization. For smart property, perhaps the picture looks something like this:

decent5

Different degrees of decentralization can exist within the same service: trust is being unbundled

So what?

Of course, none of this tells us whether smart property or cryptofinance is a good idea. But it is a way to think about whether a particular service is doing anything particularly novel.   Think about it the other way: if somebody proposes a cryptocurrency business idea that doesn’t meaningfully unbundle any trust in an existing service, is it actually doing anything valuable?  Likewise, take any real-world centralised service and ask yourself: what are all the things I need to trust for this to work? Which components have to be centralised? Which could be decentralised? Does that lead to lower risk? Lower cost? More opportunities for competition? Reduced friction for consumers? If the answer is “yes” to those questions then you could have an interesting proposition on your hands.

Unbundling trust in payments

A similar analysis works for systems like Ripple. Ripple’s architecture is more distributed than the traditional payments systems but less so than Bitcoin (at least as envisaged) so perhaps we may place it somewhere like this on the scale:

decent6

Ripple is another example of a “trust unbundling”

But, just like in the Smart Property example above, in the Ripple system there is a “trust unbundling” going on: the ledger is fairly decentralized in its operation whilst you necessarily need to trust a specific gateway.  So it actually looks like this:

 decent7

Different degrees of decentralization can exist within the same service: trust is being unbundled

To see why this is important, recall how current payment systems work. I wrote a simple explanation of it here. As the article shows, you have to trust a lot of moving actors and the point is that you have to take this as a bundle… it’s all or nothing. You trust all those parts of the system or you can’t achieve your objective.  With a Ripple-like system, you only trust the minimal set of actors you have to – namely, the banks who issued liabilities.  Everything else can be decentralised to some degree.

Unbundling trust in contract execution

One last example: a similar argument applies to financial contracts. Projects like Ethereum (and Counterparty!) are exploring the decentralized modeling and execution of law. Gavin Andresen has written about how something similar could be achieved on the base Bitcoin platform.

You can think of this in terms of “trust unbundling” too: the decentralized platform ensures the integrity of contract execution and you can use n-of-m oracles to provide reliable external data. You only trust who you have to, to the minimal degree possible.

Using “trust unbundling” to turn bad ideas into good ideas..?

So now we can put this model to the test. Does it help us spot the silly ideas? Even better, does it help us turn the silly ideas into good ideas?  [UPDATE 2014-11-15 this section was heavily reworked)

Antonis Polemitis commented on an earlier version of this article:

Here’s what I think he means:

A better airline miles system?

As Antonis points out, airline miles systems are highly centralised: the airline is the issuer, redeemer, owner of the ledger, setter of the rules and controls everything else too.

So imagine an airline were to announce that their new airmiles programme was to be based on a fork of Bitcoin. Perhaps they would create their own Blockchain, issue the miles on top, secure it themselves and distribute wallets to all their customers. Brilliant…  an airline miles programme with all the benefits of Bitcoin!

Really? From a consumer perspective, surely this system would be indistinguishable from a traditional system and what is the argument that says it would be better in any meaningful way?

But take a step back and think about airline miles again and think about the trust bundle. Which parts of the system require you to trust the airline?  Issuance and redemption of the miles, for sure.  And setting of the scheme rules.  But storage, exchange and trade doesn’t need to be done by them.

And perhaps there’s a cost saving for airlines if they offload that work to a decentralised network and a benefit for customers if it gives them additional utility – perhaps new ways of swapping miles between competing programmes to accumulate enough points to book a flight?  Some very interesting possibilities emerge if multiple airlines base their systems on the same platform or if third parties can build new services on top of a platform like this.

Suddenly you might have something interesting: an interoperable, multi-provider airline miles storage, transfer and redemption platform. Now it could be a terrible idea – these schemes only work because most miles are never redeemed, after all! But the thought process is important: who are users expected to trust to use your service?  And what are they trusting them for?  What if a component was decentralised? What new possibilities would that enable? What risk could it mitigate?

Now the real world is more complicated than this. But the key insight remains:

  • if your cryptocurrency idea requires users to trust only you, you’re missing the point
  • but if there’s something in the value proposition that can be usefully decentralized or shared with others, you could be on to something

Ripple is hard to understand, but it’s worth making the effort: there’s a deep insight at its core

Ten dollars in your pocket is not the same as ten dollars in the bank and neither are the same as a ten dollar credit on your electric bill or the ten dollars your friend owes you. Ripple is simply a manifestation of this insight.

I spent a couple of hours at the Startupbootcamp Fintechathon last weekend. I was there to share ideas on what types of finance problem are a good fit for block chain solutions – and which ones might be best solved using other techniques.

When I arrived, the audience were deep in videoconference with Ryan Terribilini of Ripple Labs. I thought he did a great job of answering their questions about Ripple and I decided it was time I finally tried to get my head around it.

The conclusion I have come to is that Ripple is built on a really deep insight:

Not all dollar, euro and sterling liabilities are the same.

And Ripple is nothing more than a platform that makes this insight explicit.

Here’s how I finally wrapped my head around Ripple

I wrote a piece last year about how money moves around the banking system. I wrote:

Perhaps the most important thing we need to realise about bank deposits is that they are liabilities. When you pay money into a bank, you don’t really have a deposit… you have lent that money to the bank. They owe it to you.  It becomes one of their liabilities. That’s why we say our accounts are in credit: we have extended credit to the bank.  Similarly, if you are overdrawn and owe money to the bank, that becomes your liability and their asset.

I then explained how the payment system is really little more than a bunch of systems for transferring these obligations around.  Where Ripple encourages us to think more deeply is about whose obligations they are.

Imagine I owe my friend Bob £50 and that we are both customers of Barclays bank. When it’s time for me to pay him back, I instruct a “transfer” online. I tell the bank to reduce what they owe me by £50 and increase what they owe to Bob by £50. The bank remains flat… the only difference is to whom they owe the money.

This is the same story I told in my piece about the payments system.

Setup1

Richard and Bob both trust Barclays as an issuer of pounds. So Richard can pay Bob by transferring the money inside Barclays

But think about just happened:

  • Before the transfer, I owed £50 to Bob.
  • After the transfer, the bank owes £50 to Bob.

Bob still doesn’t have the £50 in his hand… all that’s happened is that somebody else now owes him the money.   But this is just fine for Bob…. He trusted me to owe him the money and he also trusts his bank to owe it to him.

Setup2

Bob previously had a £50 “asset” issued by Richard. Now he has a £50 asset issued by Barclays. Richard’s debt to Bob is settled and Bob is happy.

OK – so that’s obvious, perhaps.

But notice how it only worked because Bob trusted both me and the bank.

And also notice that he doesn’t trust us in the same way.   He’d probably be quite happy to have thousands of pounds in his bank account. I suspect he’d be very uncomfortable lending me more than £50.

Not all dollar, euro or sterling asset deposits are the same!  It matters who issues them.

It is highly likely that Bob prefers to be owed money by his bank than by me. £50 owed by me is not the same as £50 owed by the bank.

And this is the Ripple insight.

This is a really powerful observation

Imagine now that the situation is a little more complicated.  Bob and I are sitting in a café. I don’t have any cash and Bob can’t remember his account details. How am I going to pay him?  A Barclays transfer isn’t going to work.

Out of the corner of my eye, I see that the café sells prepaid debit cards. Excellent! I use my own debit card to buy a £50 prepaid debit card and hand it to Bob.   My debt is settled, right?

Not so fast….

What makes me think Bob would be happy to accept a prepaid debit card from an issuer he’s never heard of? Are they insured? What happens if they go bust before he can spend the cash?

£50 on a prepaid debit card is not the same as £50 in cash or a £50 IOU from a friend or £50 owed by Barclays bank.   And it is Bob’s choice whether to trust that card.

It turns out that Bob doesn’t trust this card… So we have a problem. I don’t have his bank account details and he won’t accept a prepaid debit card. How am I going to pay him?

Conveniently for my story, it just so happens that my friend Carol is sitting at the table next to us. Bob doesn’t know Carol so I introduce them to each other.

It turns out that Carol is trying to buy some goods online and has forgotten to bring her credit card. The goods cost £50 and she just happens to have £50 in cash in her purse. (It really is a most amazing coincidence…)

So the situation is something like the diagram below. We see that I have nothing that Bob will accept as payment but that Carol might be able to help us bridge the gap. (I’ve added some detail to show that each person might trust each issuer to different extents – it’s not a yes or no question)

Setup3

How can Richard pay Bob when there are no issuers of pound sterling that Bob trusts that Richard is able to use?

Here’s what we could do: I could give Carol the prepaid debit card (she needs something she can use online and the £50 balance is well below the £1000 limit that she is willing to trust the card company for) and she can then give the £50 in cash to Bob. Bob is happy to take the cash: he also trusts the Bank of England, the issuer of the notes.

Great: Bob now has £50 issued by somebody he trusts. I’ve managed to pay Bob what I owe him by enlisting the help of a prepaid debit card provider and Carol… even though Bob didn’t trust the prepaid debit card and he doesn’t even know Carol.

Setup4

Richard can pay Bob by “rippling” his transaction through multiple issuers and intermediaries, finding a route of trust that wouldn’t have been possible otherwise.

Yes, yes, I know…. It’s an utterly contrived example.  But it makes the point: not all pounds, dollars and euros are the same. It all depends on the issuer: when we open a bank account in the UK, we’re saying we trust that bank to issue GBP liabilities to us.     When we lend £50 to a friend, we’re saying we trust that friend to issue GBP IOUs. And we all trust different groups of issuers and to different extents.

So how does this relate to Ripple?

The answer is that Ripple is a general purpose ledger and payment network based on the key insight that when you try to pay somebody, it’s only going to work if they end up with an asset that was issued by an issuer they trust.

In our case, Bob trusted me, he trusted Barclays and he trusted the Bank of England. But he didn’t trust the prepaid debit provider and he doesn’t trust Carol – so a £50 balance issued by the prepaid debit card provider was never going to satisfy Bob.

But, because Carol and I both trusted the prepaid debit provider and both Carol and Bob trusted the Bank of England – and Carol actually had some notes issued by the Bank of England in her purse – I was able to settle my debt to Bob by routing it through the prepaid debit card provider and through Carol.

The lesson of all this is that if you’re going to build a system that represents real-world currency balances and make payments between them, you really need to think about who issues those balances.

And once you get this point, the point of Ripple becomes clear:  it’s a way for one person to hold funds issued by issuers he or she trusts – and to pay anybody else by transforming those funds into balances issued by issuers that the recipient trusts.

Sure – there’s more to it than that…. But once you get the idea that any individual participant will only trust balances issued by certain issuers, the whole point and design of the network becomes clear.

But this isn’t really about Richard, Bob and Carol: think about the banks themselves and major corporations

The example in this post feels contrived, because it is.  But imagine you’re a major bank.  You have precisely this problem: you have correspondent banking arrangements around the world.  You have separately capitalised and regulated subsidiaries around the world.  And you need to make payments to people and firms all over the world on behalf of yourself and on behalf of your customers.

You need to keep track of balances issued by hundreds of legal entities around the world and need to instruct transfers and exchanges thousands of times per day.

Today, you do this through correspondent banking arrangements, the SWIFT network and multiple other intermediaries and communication platforms.

If I understand the vision correctly, Ripple sees itself as a universal, distributed ledger for simplifying and rationalising this complicated landscape.

Will it work? Will the banks and major firms adopt it? Who knows. But the underlying insight is deep and it feels like they’ve figured out something that is important.

Postscript: What about Bitcoin?

It amuses me when I see Bitcoin and Ripple discussed in the same context because, for me, they’re completely different.   The core of Bitcoin is all about building a trust-free decentralized transaction ledger for tracking the ownership and transfer of scarce tokens – Bitcoins. And the whole point of Bitcoins is that they are counterparty-risk-free assets: my Bitcoin is not somebody else’s liability.

By contrast, Ripple is all about dealing with assets that are somebody else’s liability. So the focus in Ripple is on representing liabilities issued by identifiable issuers and enabling them to be transferred between individuals on a network.

They share some similarities but they’re not the same thing at all.