Just when I think I understand the cryptocurrency/block chain space, I realize I didn’t understand anything at all

Four recent events have made me realize that I don’t understand this space anywhere near as well as I thought I did. But that’s good: it means I’ve been forced to come up with a new mental model to explain to myself how all these projects relate to each other.

TL;DR: the two questions to ask about a “fiduciary code” requirement are: who do I need to trust and what am I trusting them about?

A simple model to capture the essential differences between some consensus platforms

The rest of this article describes the four events that influenced me to draw it.

Event 1: Nick Szabo’s “The Dawn of Trustworthy Computing” Article

In his recent article, Nick Szabo introduces two really helpful terms to explain what makes systems like Bitcoin particularly noteworthy.

First, he talks about “block chain computers”. He defines these as the combination of the Bitcoin consensus protocol and strong cryptography to create the unforgeable chain of evidence for all data stored in the block chain data structure. I think this formulation is useful because it shines a bright light on an obvious, but often overlooked fact: a “block chain” is just a data structure, utterly useless on its own. What makes the Bitcoin blockchain remarkable is the network of computers – and protocol they follow – that makes it so hard for any single actor, no matter how determined, to subvert it.

Secondly, he talks about “fiduciary code”: the code in an application that needs to be the most reliable and secure. For example, in a banking application, this is likely to be the core ledger: who owns what. He points out that a secure block chain computer is an extremely expensive piece of kit: you should only use it to secure that information that really needs it.

In this piece, Albert Wenger makes a really obvious-in-hindsight point: Bitcoin-like block chains are organizationally-decentralised – no one organization can control it but the entire point of the system is to build and maintain a logically-centralised outcome: a single copy of the ledger, which everybody agrees is the true single copy.

ArthurB uses the term “decentralized mutable singleton” to capture the same idea, I think.

Repeat after me: if you don't need concurrent access to a decentralized, mutable, singleton, you don't need a #blockchain.

And he echoes one of Szabo’s implicit points: a “block chain” is not something of value in and of itself. This insight is also important because it edges us further away from the idea that “decentralization” is some sort of end-goal or absolute target. I made a similar point in this piece on the “unbundling of trust” but Albert and Arthur have captured the key point far more succinctly.

In essence: take the idea of a shared common state (Albert’s Arthur’s “mutable singleton”) but relax the constraint that the maintenance of it necessarily happens in a fully public, adversarial environment, for which something like a proof-of-work system may be required, and allow for the idea that the participants might be known. [EDIT wrong name!]

Fine… but I think the Eris insight is where they go next. They suggest that if you had such a system then you might also be able to distribute the processing of application logic more broadly, too. And I think it’s the application logic they’re most interested in. Their documentation is full of talk of “smart contracts” and it’s perhaps no surprise that their founders are lawyers. In fact, maybe that’s why I don’t understand it as well as I’d like: lawyers just seem to speak differently. Maybe I need a translator.

And to be clear, the part I don’t fully understand just yet is why you need a “block chain” as the underlying data structure in this model, rather than something based on more general-purpose replicated database technology. But this may turn out just to be an implementation detail: so let’s see how they get on over time. There seems to be a lot of content, reflective of a lot of thought, on the various Eris sites.

Event 4: I looked at HyperLedger in more detail

I had reason to look at HyperLedger this week and, combined with my study of Eris, it was this event that finally convinced me that my mental model of this space was far too simplistic.

Hyperledger calls itself an “open-source, decentralized protocol for the recording and transferring anything of value”. This is a bit like how I might have described Colored Coins or Ripple to people in the past.

But what makes Hyperledger different is that they allow the creation of multiple ledgers (one per asset per issuer) and each ledger can be configured to have different consensus rules – you don’t have to make the assumption of an adversarial open public environment… so some similar assumptions to Eris here, but with a ledger designed to track assets rather than business logic/contracts.

Where is this heading?

So I spent some time this evening trying to piece all of this together in my brain.

I’m pretty sure these projects all sit in Szabo’s “Fiduciary Code” space: they only really have value or make sense if the facts they’re recording are really important!

But they make different assumptions about the threat model they face – and some of these assumptions are very different to the ones against which Bitcoin was designed. And they’re different to the assumptions underpinning some other prominent platforms, such as Ripple, which, through its use of validators and “Unique Node Lists” has a model, whereby you trust a set of known entities who, in turn, trust some other entities, and so on.

In addition, the facts these systems are recording are very different: ownership of a real-world asset on Hyperledger is different to ownership of a bitcoin on the Bitcoin ledger; a ledger-native asset has no counterparty risk, whereas a real-world asset needs an identifiable issuer. And they’re both different to a platform that potentially executes legal contracts.

So I tried to think of dimensions along which you might be able to classify these projects… and I came up with too many.

But it’s almost Christmas and I’m not to be deterred! Is it really too much to ask for a model with just two dimensions, that doesn’t require a 3-D screen to render?! So I kept on going. And, finally, came up with something that looks so trivial, I worry it may be content free. But here it is anyway.

I think the two dimensions that help me think about these projects are:

“Who do I trust to maintain a truthful record?”; and

“What do I need the record to be about”?

Here is the model I came up with. It’s obviously not complete and you could put some projects in multiple boxes… but I think it captures the key distinctions.

Another way to think about the increasingly confusing cryptocurrency/Block Chain space

But this is just a view. I’d really value comments… especially if I’ve missed something really obvious.

[UPDATE 2015-01-08 DISCLOSURE: Since publishing this post, I have become an advisor to HyperLedger, in a personal capacity]

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 manypotential usesfor 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.

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

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.

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:

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:

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:

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:

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:

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.

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:

@gendal I find a good theoretical example to be airline points. today centralized issuer and centralized / clunky clearing/settlement/etc

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

If you’ve followed Bitcoin for any time, you’ll know this is aseriously eminent group of authors

It describes a way to build “pegged sidechains”. Sidechains themselves are not new – the idea, and how to build them, has been discussed for some time and the key breakthrough was outlined earlier in the year. But this paper gives more detail on the concept and has attracted a lot of comment.

But what are they? And why should anybody care?

A mental model for Bitcoin

The key to understanding most innovations in the Bitcoin space is to make sure you have the right mental model for how Bitcoin itself works. It turns out that most people I speak to don’t really understand how it works and, as a result, have a faulty mental model.

But in this piece, I’ll skip the analogy and net it down to the basics.

First, clear your head of anything related to money, currency or payments. And clear your head of the word ledger, too. The mind-bending secret of Bitcoin is that there actually isn’t a ledger! The only data structures that matter are transactions and blocks of transactions. And it’s important to get this clear in your head if sidechains are going to make sense.

When you “move” Bitcoins, what you’re saying is:

Hello everybody… I’d like to move these specific Bitcoins, please.

Here is the proof that I am entitled to move them

And here is how the recipient will, in turn, prove that they are entitled to move them.

The critical three parts of a Bitcoin transaction

There are several important points here:

Bitcoins are not perfectly fungible… when you move (or spend) them, you’re spending some specific bitcoins

In order to spend them, you have to prove you’re entitled to do so. And you do that by providing the solution to a challenge that was laid down when they were sent to you in the first place. This challenge is usually just: “prove to the world that you know the public key that corresponds to a particular Bitcoin address and are in possession of the corresponding private key”. But it can be more sophisticated than that.

When you send Bitcoins somewhere, you lay down the challenge for the next owner. Usually, you’ll simply specify that they need to know the public and private keypair that correspond to the Bitcoin address the coins were sent to. But it can be more complicated than that. In the general case, you don’t even know who the next owner is… it’s just whoever can satisfy the condition.

Keep saying the three steps to yourself until they’re etched on your memory!

Fine. So the “grammar” of a Bitcoin transaction is clear: “Here are the coins I want to move, here’s the proof I’m entitled to and here’s what the recipient must do, in turn, if they want to spend them”.

This transaction is published into the network, it will eventually find its way into a block and, after other blocks have been built on top, everybody can be pretty sure it won’t be reversed and the world moves on. What more do you need?

The core Bitcoin “grammar” works just fine, mostly…

This three-part structure to a Bitcoin transaction works well and it turns out that you can do some really interesting things with it. For example, you can use the “not-entirely fungible” feature to “tag” coins. This is the basis of the “Colored Coins” and “Smart Property” worlds.

But there are problems, such as:

Block interval

Bitcoin’s block interval is ten minutes so it takes about five ten minutes on average for a new transaction to find its way into a block, even if it pays a high fee. This is too slow for some people so they have experimented with alternative cryptocurrencies, based on the Bitcoin code-base, which employ quicker block intervals [UPDATED 2014-10-27 to correct my embarrassing misunderstanding of mathematics…]

Transaction Structure

The “three-part” transaction structure is very general but it only allows you to transfer ownership of Bitcoins. Some people would like to transmit richer forms of information across these sorts of systems. For example, a decentralized exchange needs a way for participants to place orders. Projects such as Mastercoin, Counterparty, NXT and others either build layers on top of Bitcoin or use entirely different codebases to achieve their goals.

Transaction Transfer Conditions

I said above that you can build sophisticated rules into Bitcoin transactions to specify how ownership is proved. However, the Bitcoin scripting language is deliberately limited and many ideas in the Smart Contracts space are difficult or impossible to implement. So projects such as Ethereum are building an entirely new infrastructure to explore these ideas

One-size-fits-all security model

It doesn’t matter if you’re moving $1bn or 0.01c across the Bitcoin network, you get the same security guarantees. And you pay for this in fees and time. What if you were prepared to trade safety for speed? Today, your only real option is to send the coins to a centralized wallet provider, whom you must trust not to lose or steal your coins. You can then do all the transactions you like on their books, with their other customers and you never need touch the Bitcoin blockchain. But now you lose all the benefits of a decentralized value-transfer network.

One-size fits all doesn’t help if the size doesn’t fit you!

Now, making experimental or rapid changes to Bitcoin is very risky and so change happens slowly. So if the one-size-fits-all architecture of Bitcoin doesn’t suit a particular use-case, you have a problem. You either have to use an entirely different cryptocurrency (or build one!). Or you have to use (or build) a centralized service, which brings new risks.

This is very inconvenient. It creates risk and fragmentation and slows the build-out of products, services and infrastructure.

Centralised Wallet Providers as a “poor-man’s sidechain”?

But there’s an interesting observation we can make. Think about what happens if you send Bitcoins to a centralized wallet such as circle.com for safekeeping.

You send your coins to a particular Bitcoin address

They appear inside your circle wallet and are out of your control on the blockchain.

At some point in the future, you might send your coins back out of your circle wallet to a Bitcoin address you own

You now have control of some coins on the Bitcoin blockchain again!

From the perspective of the Bitcoin network, Circle is a black box. You had some coins… you sent them to a specific address… some stuff happened that Bitcoin couldn’t see…. And at some point later, you had control of some coins again. It’s as if those coins had been moved from Bitcoin to somewhere else and then back again.

Here’s the Sidechains insight

The key idea behind the sidechains concept is:

What if you could send Bitcoins not only to individuals, addresses and centralized services but to other blockchains?

Imagine there is a Bitcoin-like system out there that you’d like to use. Perhaps it’s litecoin or ethereum or perhaps it’s something brand new. Maybe it has a faster block confirmation interval and a richer scripting language. It doesn’t matter. The point is: you’d like to use it but would rather not have to go through the risk and effort of buying the native tokens for that platform. You have Bitcoins already. Why can’t you use them?

The sidechains ideas is this:

Send your Bitcoins to a specially formed Bitcoin address. The address is specially designed so that the coins will now be out of your control… and out of the control of anybody else either. They’re completely immobilized and can only be unlocked if somebody can prove they’re no longer being used elsewhere (I’ll explain what I mean by this in a minute). In other words, you’ve used the core bitcoin transaction rules I described above to lay down a specific condition that the future owner – whoever it ends up being – needs to fulfil in order to take control

Once this immobilisation transaction is sufficiently confirmed, you send a message to the other blockchain – the one you were wanting to use. This message contains a proof that the coins were sent to that special address on the Bitcoin network, that they are therefore now immobilized and, crucially, that you were the one who did it

If the second blockchain has agreed to be a Bitcoin sidechain, it now does something really special… it creates the exact same number of tokens on its own network and gives you control of them.

So it’s as if your Bitcoins have been transferred to this second chain. And remember: they’re immobilized on the Bitcoin network… so we haven’t created or destroyed any…. Just “moved” them.

You can now transact with those coins on that second chain, under whatever rules that chain chooses to implement.

Perhaps blocks are created faster on that sidechain. Perhaps transaction scripts are “turing complete”. Perhaps you have to pay fees to incent those securing that sidechain. Who knows. The rules can be whatever those running that sidechain want them to be. The only rule that matters is that the sidechain agrees to follow the convention that if you can prove you put some Bitcoins out of reach on the Bitcoin network, the same number will pop into existence on the sidechain.

And now for the second clever part. The logic above is symmetric. So, at any point, whoever is holding these coins on the sidechain can send them back to the Bitcoin network by creating a special transaction on the sidechain that immobilises the bitcoins on the sidechain. They’ll disappear from the sidechain and become available again on the Bitcoin network, under the control of whoever last owned them on the sidechain.

So, to repeat, we’ve used standard Bitcoin transaction functionality to move coins out of reach and we then prove to a second, unrelated chain, that we’ve done this. And when we’re done, whoever owns them on the sidechain can do the same thing and send them back to the bitcoin network.

So developers get the opportunity to experiment with different types of cryptocurrency rules without needing to create their own currency.

And it now becomes possible to do some very interesting things in the Bitcoin space.

Step back from the details for moment and consider what’s been described. We now have a way to move coins from Bitcoin onto another platform (a sidechain) and move them back again. That’s pretty much what we do when we move them to a wallet platform or an exchange. The difference is that the “platform” they’ve been moved to is also a blockchain… so it has the possibility of decentralised security, visibility and to gain from other innovation in this space.

For example, one could imagine a sidechain that is “mined” only by one company. That would be identical to a single-company wallet, but with full visibility of transactions.

Going further, you could imagine a sidechain that is mined by 100 different companies in a loose federation. Not totally decentralized, but harder to censor or subvert than if it were just one.

And there are lots of other possibilities. The key is that you can build these experiments and products and services without also needing to create a new currency or fall back into the old centralised style.

So when I look at sidechains, I’m looking at them as an architecture for building semi-decentralised products and services for Bitcoin that were simply impossible before.

My argument to the audience was the one I usually give: they should simply ignore the currency use-case: it’s the least interesting thing about Bitcoin. They should, instead, look at it as a platform for decentralized value-exchange and focus on the opportunities this enables.

I then returned to the warm embrace of the Innotribe room and thought little more of it.

I thought little more, that is, until I returned home on Friday and went for a run. I took the opportunity to catch up with a few podcasts, one of which was Dave Birch’s interview with Jeffrey Robinson, author of BitCon. (Aside: everybody I know thinks I’m weird for listening to economics and FinTech podcasts when I run. I can’t be alone… surely?!)

It is fair to say that Jeffrey is not a fan of cryptocurrencies. And he makes some well-aimed shots at the heart of the “Bitcoin is a useful currency” argument in the podcast. For example, he points out that vanishingly few retailers actually accept it, despite the hype (they, instead, receive dollars from BitPay or Coinbase instead).

Now, one could take issue with Robinson’s arguments (he’s very confused on some technical aspects and the Boston Fed does see some evidence that consumers pay marginally less when using Bitcoin rather than payment cards).

But surely this is to miss the point. Whether or not cryptocurrencies are superior than today’s currencies for today’s payment problems isn’t really interesting.

It’s like saying that the automobile is a terrible way of pulling a plough.

Cryptocurrency technology will succeed only to the extent that it enables new products and services that were previously impossible or unimaginable.

And here’s the light-bulb moment: most of the really interesting use-cases turn out to need a payment mechanism – and having a currency and payment mechanism built into the platform turns out to be really, really useful.

Causation runs in the opposite direction to what everybody seems to think: it is new products and services that will drive adoption of the underlying currency. Not the other way around.

Two interesting viewpoints

Perhaps you think I’m setting up a strawman…? Happily, there have been two separate posts this weekend describing what some of these applications might be. So let’s check…

First, Chris Dixon offers some ideas for native Bitcoin apps. If I’m being critical, I thought they were somewhat pedestrian – they all seem to be answers to the question: “if Bitcoin the currency was widely deployed, what could you do with it?” – which I think is the wrong way to look at this. It has causation in the wrong direction.

When the audience takes photos and makes notes, you know they’re excited by the topic…

I hosted five startup CEOs on the Innotribe stage at Sibos on Monday and it’s interesting to me that the demo that created the most excitement was Yoni Assia’s demo of colored coins. He showed the (fake!) example of a large US bank issuing IBM stock on the blockchain so that it could be traded and transferred without the need for the plumbing we take for granted in the securities processing world. I think he used the CoinPrism platform. And it’s worth also checking out ChromaWallet.

Using the Colored Coins concept to issue, track and transfer securities on a blockchain.

I spoke to various attendees over the following days and this topic clearly excited them. The demo had helped them move from an intellectual, but shallow, understanding of the concept to one that helped them envision a future where custodians, clearing houses, exchanges and brokers work in a completely different way. I’ve written about decentralized securities processing here and seeing it in a live demo made it real for people.

Now the interesting thing is: this use-case has nothing to do with currency. The Bitcoins are just being used as a transport layer. All the intelligence and disruptive power is at higher layers of the stack.

The key insight: what is the best payment mechanism for colored coins?

But now… ask yourself a question: imagine this platform gained adoption. In what currency – and using what mechanism – would participants pay each other?

Sure – you could use whatever you like. But the interesting thing is: if you paid in the native currency of the platform – Bitcoin in this case – some very special possibilities arise. For example, you can use the Bitcoin scripting system to make binding bids and offers without needing a central exchange. And you can achieve atomic swaps of currency for securities – delivery versus payment – without needing a custodian.

So suddenly, a “currency” which may indeed have limited utility for today’s developed markets for today’s problems suddenly becomes utterly superior for this new use-case of decentralized asset exchange.

Now, I should point out that not all of this infrastructure yet exists so I’d advise readers to read an interesting paper by Mark Friedenbach and Jorge Timón on how to modify the underlying Bitcoin system to support it. (My thanks to Ian Grigg for the pointer). In passing, I think these systems also need two other critical pieces of infrastructure:

An identity and reputation system: how do I know an issuer of IBM “stock” really is who they say they are? And how do I know they are authorized to make the statement? The complexity here goes beyond narrow concepts of corporate identity

What rules are needed to underpin this? Which legal precedents?

But I think it’s examples such as this will lead us to a world of 1) unanticipatable products and services, for which 2) the optimum payment mechanism is the native token of the platform.

To repeat: new apps will drive cryptocurrency usage… not the other way round.

So what are some other potential use-cases?

I’d classify the example above as Smart Property. I think there are at least two others:

The Economy of Things

I wrote recently about the work we at IBM are doing around the economic model of the Internet of Things. The work is focused on the underlying architecture through which trillions of devices can discover, connect and collaborate. But what would happen if these “things” needed to transact with each other? Wouldn’t the most obvious payment vehicle to use be the native token for the platform? (Usual disclaimer: I raise this as an open question… it’s not a statement of direction or intent by IBM)

Indeed, one potential example of this has already been studied in Switzerland. A recent paper by Dominic Worner and Thomas von Bomhard examines “Exchanging Data for Cash with Bitcoin” – one could easily imagine “things” paying each other for access to trusted data feeds in other scenarios too.

Smart Contracts

Vitalik Buterin’s presentation on Ethereum was a highlight of the first day at Innotribe this week. And I thought his host, Dan Marovitz, showed excellent judgement in allowing him to talk at length and in significant technical depth about his vision. The audience of senior bankers seemed to be completely rapt.

At the core of the Ethereum concept is the idea that real-world relationships and contracts can often be reduced to deterministic rules that can be executed by a neutral, unimpeachable platform. And these contracts often (not always) involve the exchange of economic value, usually in the form of the native currency of the platform.

It’s still early days, of course. But the lesson I learned this week was that we need to get away from the sterile “Bitcoin the currency” versus “Bitcoin the platform” debate. Instead, we should consider how one drives the other… and how it’s the platform that is likely to drive the currency, not the other way round.

The IBM “Device Democracy” paper is another example of how blockchain technologies could have impacts well beyond currency

I recorded an interview for Finextra last year, where I argued that we should view Bitcoin and cryptocurrencies as far more than just currency and payment systems: they’re enablers for whole new classes of innovation.

One of the example I gave was how they could provide an economic underpinning for the Internet of Things (IoT) and pointed out that if devices in your home each had their own Bitcoin wallet, the Internet of Things could rapidly become the Economy of Things

So I have been enormously privileged to contribute, in a very small way, to a fascinating project being led by Paul Brody, IBM’s Vice President for our Mobile and Internet of Things consulting team. It has been well-covered by CoinDesk, GigaOm and “Two Bit Idiot” but, as Two Bit Idiot observes, I think its true significance has yet to be understood.

Here’s my simplified take on what this project is all about:

Imagine the predictions of the futurists come true and the Internet of Things becomes a reality: wireless locks controlling our houses, wifi-enabled lightbulbs and internet toasters, all that stuff.

Think about the economics from the manufacturer’s perspective.

My elderly iPhone 4 has finally reached end-of-life: it’s getting slow, iOS 8 will not run on it and I can expect apps to start failing one-by-one as their developers stop updating them for iOS 7. And yet the phone is only four years old. Most other phone manufacturers abandon their customers far more quickly, which means Apple’s four-year support for my phone is industry-leading.

My iPhone 4 served me well – even serving as a prototype for Apple Pay (Not really). But, after four years, it is obsolete and the latest version of iOS won’t run on it

But, for the internet of things, a four-year old device is barely a child! These devices could last for far longer than anybody expects. How often do you change the locks on your door? When did you last replace your toaster? Some observers claim LED lightbulbs could last for twenty years.

Now imagine what the world would be like if Apple had to support the iPhone 4 for twenty years. That is a long time to support, maintain and upgrade an internet-connected device. As Paul and the team write in their very readable whitepaper, we can’t assume that the data produced by these devices will somehow create enough value to fund the ongoing costs. Consumers seem to be in no mood to give away ever more data in exchange for “free” services… and it’s entirely unclear that this data has as much value as people think, in any case.

Technology Principles for internet-connected devices that could run for decades

So we need to make it as easy as possible for manufacturers and others to support these devices in the field. And part of the answer is surely that we need to make it as easy, cheap and sustainable as possible for manufacturers to do the “right” thing. And the argument that Paul’s paper makes is that the key to doing this is to decentralize as much logic as possible – so that what’s left at the centre is as small as possible. They capture this intuition in the form of three key “technology principles”:

think “peer-to-peer” wherever possible… if two devices can find each other and communicate directly, why route it through a central point?

assume you’re operating in a “trustless” world: if you can’t be sure that everything is running perfectly all the time (because it won’t be), then choose a design that needs as little trust as possible

decentralize autonomy to the greatest extent possible – if something doesn’t need to be decided at the centre, decide it at the edges. Build on the insight that those with the greatest ongoing incentive to keep these systems running are those closest to them and who depend on them the most.

Device Democracy

This concept inspires the title of the paper: “Device Democracy”. They call the resulting architecture an “Internet of Decentralized, Autonomous Things”. The project’s IBM landing page explains more.

The paper explains the reasoning in more depth but the intriguing result is that the principles above are well-matched to concepts well-understood by the crypto and cryptocurrency worlds. A secure point-to-point messaging system like Telehash is a good candidate for direct device-to-device messaging, for example. Similarly, a trustless decentralized contract platform like Ethereum (a second-generation blockchain technology) could be a way to encode agreements between devices and to enforce rules.

Indeed, the team’s prototype (which has real locks opening and closing – I so wish I had been in the room when they demonstrated it) is based on Ethereum, Telehash and BitTorrent (you need something to distribute billions of firmware updates, after all)

But it’s important to realize that this isn’t a break from the past; it’s incremental. Existing protocols will still be needed and manufacturers will still need a way of communicating with their devices. This is all about making it as easy and secure as possible and to give end-users as much control as possible – hence “Device democracy”.

It’s perhaps likely that we’ll see hybrid models emerge where these peer-to-peer technologies are coupled with centralized services (cloud-based to hit cost objectives).

This is why I say Bitcoin and Cryptocurrencies are about so much more than currency…

For me, this project gives me further reason to believe that the impact of blockchain technologies and cryptocurrencies will be far greater than anybody expects: their applications go beyond the imaginations of any one of us.

We first saw this with Bitcoin. You needed good knowledge of economics, finance, cryptography and computer science to understand the Bitcoin concept in its full breadth. Indeed, I think this is why may academic economists, central bankers and computer scientists were amongst the slowest to grasp its importance: they were, in general, just too specialised and narrow.

So it is with this project: it has taken a team with knowledge of electronics, engineering, manufacturing, decentralized protocols and economics to devise this prototype platform.

The future belongs to the versatilists?

I wonder if this could be further evidence that the future will be owned not by the specialists or the generalists – but by the versatilists?

Disclaimer and Notes

1) I know there’s a lot of interest about this project so a quick reminder that this blog contains my views and analyses… not IBM’s. I am not an official spokesman on IoT or anything else.

2) I have lost the contact details of the clever person who created the excellent t-shirt design above. Please do get back in touch so I can credit you

Regular readers will know that I am extremely optimistic about the long-term potential of Bitcoin and cryptocurrency technology to revolutionise the financial system. But that doesn’t mean I think they will overturn all aspects of the system.

In particular, I am skeptical of claims that Bitcoin will have a meaningful impact on retail payments and break the stranglehold of the payment card companies.

Of course, many people disagree with me. Articles such as this one from last year are typical of the genre: “credit card companies” are accused of charging obscenely high fees, hindering innovation and being ripe for disruption.

Payment Cards fees might seem expensive but does it mean they are vulnerable to disruption?

But the main reason I think the incumbents are in such a strong position is because the industry has extremely strong network effects, which leads to formidable barriers to entry. Would-be Bitcoin entrepreneurs need to understand this structure if they are to succeed.

The Payment Card Industry is marvellous and weird at the same time

When you step back and think about it, the modern payment card industry is a marvel – an underappreciated, underrated miracle of contemporary commerce: you can travel to any corner of the earth, armed only with a piece of plastic bearing the Visa or Mastercard logo. It’s a minor miracle.

But when you look at the businesses of the major card brands, they turn out to be really, really strange companies. They simply don’t do what most of us think they do.

Take a card out of your pocket… chances are, it will be a Visa or Mastercard, or maybe UnionPay if you’re one of my Chinese readers. Let’s assume it’s a Visa card for now. And we’ll worry about American Express later, because they’re different to all the rest.

Here’s one of my Visa cards again:

A Visa debit card, issued by first direct bank.

Notice something strange. There are two brands on the card. There is the Visa logo and there is one for first direct, the division of HSBC with whom I hold my current account. Most other consumer products don’t have two firms’ logos on them. Something strange is going on.

Now, it it was first direct that issued the card to me, not Visa.

It is first direct’s website I visit to see my balance, not Visa’s

And it’s first direct I would call if something went wrong, not Visa.

I don’t have any relationship with Visa at all.

There’s no Visa call centre I can call if I have a problem with my card and there’s no Visa app on my phone. This is strange: a hugely powerful global brand and yet the billions of consumers who use it don’t have a relationship with them.

It gets stranger. Another little-known fact is that no retailer anywhere in the world has a relationship with Visa either! So we have one of the world’s most recognizable brands and nobody who uses their “product” has any relationship with them.

It’s worth thinking through why this might be and why it is such a powerful model.

How would you build a credit card system if you were doing it from scratch?

Imagine you run a bank in a world before credit cards. Wouldn’t it be great if your customers could go to local shops and “charge” their purchases to an account that you hold for them? You could make money offering credit to the customers and make some more money charging the merchants for providing this service.

This is what Bank of America did in California in the 1950s. They issued credit cards to lots of their customers in various cities and signed up local retailers to accept them. Great – the payment card industry was born! You could think of the model looking something like this:

A simple card scheme: a bank issues cards to its customers and reimburses local merchants who accept those cards

But this model has two really unfortunate problems:

Your competitors are going to copy this and you’ll soon have schemes like this popping up all over the country, all run by different banks, on different systems, racing to sign up consumers and merchants onto their product

Your customers will travel. And they will be very upset when they discover they can’t use your card in a merchant who only takes a different bank’s cards

You would end up with the situation in the diagram below: a merchant who banked with Bank B wouldn’t accept cards issued by Bank A. Why would they? They had no relationship with Bank A and who’s to say cards from Bank A would even work with their machines?!

Why would cards issued by Bank A be accepted by a merchant who uses Bank B if Bank A and Bank B operate competing schemes?

If you were running one of the banks, how might you respond to this problem?

One answer might be to view this as an arms race: perhaps the best strategy is for banks to enter an all-out war… sign up as many merchants as they can… sign up as many customers as they can and bet that you’ll be the last firm standing when the industry shakes out. Obvious problem: it would be ruinously expensive and what happens if it ends in stalemate? You still have the same problem.

But there’s another option… what if you cut deals with other banks: agree for them to accept your cards at their merchants in exchange for you accepting their cards at your merchants. This sounds quite promising but… obvious problem: how on earth would the merchant handle this? They’d need a huge book by every till that listed precisely which banks they could accept card payments from and which ones weren’t allowed. It would be chaos… But perhaps it points the way

A flash of insight – who are you really competing with?

Let’s recap: you’re a bank executive trying to build a payment card business. But your competitors are all trying to do the same and it’s going to end in tears: you’ll confuse the merchants with hundreds of different card types or you’ll go bankrupt trying to be “last man standing”.

It feels like having other banks accept your cards at their merchants would be good… but how to make it work?

And this is where a flash of insight changed the world.

Somebody realized that the cards “business” was actually two businesses.

The first business is all about offering credit to your customers, managing their accounts and processing their payments. We could call this card issuing.

And the second business is all about enabling merchants to accept card payments and get reimbursed. We could call this merchant acquiring.

Aside: we call it “acquiring” because it’s helpful to model the card payment as a receivable that the processor purchases (acquires) from the merchant at a small discount, which you can think of as the processing fee.

This is the key point: issuing and acquiring are totally different businesses which don’t compete with each other.

Sure… all the issuers compete with each other.

And all the acquirers compete with each other.

But the issuers don’t compete with the acquirers.

Indeed, they have a really strong incentive to co-operate… the issuers want all the acquirers to accept their cards… and the acquirers want to offer their merchants the ability to accept as many cards as possible.

So let’s imagine a group of issuers teamed up with a group of acquirers. And imagine they agreed that the acquirers would all process the cards of all the issuers in the group: every issuer’s card would be accepted by every acquirer. They could use this forum to hammer out some standards: they would agree a common way to process cards, timescales for reimbursement, rules for what happens if something goes wrong… they’d define a “scheme”.

Now… this scheme would need two things: consumer recognition and merchant recognition. Consumers would need to know their card would be accepted at a participating merchant. And participating merchants would need to know a given card was part of the scheme.

So we need a brand. This brand would be something you could put on the cards and place in the shop window. It is how a merchant would know an issuer’s card was part of this scheme and it is how card holders would know a merchant was able to accept cards from that scheme.

One of these schemes is, of course, Visa. Another is Mastercard. And so on. And this is why cards carry two brands…. One to identify the issuer and one to identify the scheme.

In this way, the card schemes have created a system that allows merchants, who only have a relationship with their own bank, to accept payment cards issued by hundreds of other banks, without having to have any relationship with those banks at all. The only thing that matters to them is that the issuer’s card is issued on the relevant scheme.

And this model has really strong network effects… the more issuers and acquirers in the scheme, the more useful the scheme is to card holders and merchants. It’s self-reinforcing.

Talk is cheap… how does it work in practice?

OK. So we have a paper agreement that says an acquiring bank will accept any valid transaction made with a Visa-badged card. But how? How do they get approval from the issuer for the transaction? How do they get reimbursed? How does it work in reality?

Do all members of a scheme have to have a relationship with every other member so they can route the transaction to them for payment? That would be expensive and error-prone.

So this is where the scheme re-enters the picture. In addition to maintaining a powerful brand and setting the rules, they also run a switch: the merchant acquirers send all their Visa transactions to Visa itself… and Visa then forwards them on to the appropriate issuer. Similarly for Mastercard and the other schemes.

So we end up with a hub-and-spoke model… with Visa at the centre. (And Mastercard and Union Pay and so forth).

Issuers and Acquirers are members of a “scheme”, which sets the rules and acts as a central “switch” to route transactions. It means merchants with one bank can accept payments from customers of another bank, without having to maintain bilateral relationships

So now we can see why card schemes are so successful: their globally-recognised brands create networks that anybody aspiring to issue or process cards need to be part of. It’s a self-reinforcing virtuous circle that is extremely hard to disrupt

And this is why Visa’s “customers” are the issuing and acquiring banks… not end-consumers… Visa exists so that issuers can receive broad acceptance of their cards… and so that merchants can, in turn, offer broad acceptance.

But the schemes depend on consumer recognition – hence why they spend so much money advertising to consumers, even though the consumers are not their customers.

What does this have to do with Bitcoin? Push versus Pull

Notice something really important: this is a pull system… the reason you need all this infrastructure is because your card information has to get all the way from the terminal in the merchant back to the issuer so the issuer can pull the money from your account and send it back to the merchant.

By contrast, Bitcoin is a push system: once you know the merchant’s “account” details, you can just push the payment to them. So why do you need all these intermediaries?

If you were a Bitcoin payment firm trying to break into the retail market, perhaps that’s where you’d start? After all, it’s true that most of the payment card infrastructure simply isn’t needed in the Bitcoin world.

But notice how I set up this story. The infrastructure was the last thing I talked about. For me, the two most important things are:

1) Global acceptance.

2) The rulebook

Think about what Visa and Mastercard have achieved: they offer global acceptance and predictable behavior. Wherever you are in the world, you can be pretty sure somebody will accept your card and you know how it will work and that there is a well-understood process when things go wrong. This offer is powerful. Ask yourself: if you could only take one payment instrument with you on a round-the-world trip, what would it be? If you couldn’t stake a stack of dollar bills, I suspect you’d opt for a credit card.

And this predictability – a consequence of the rulebook – is important: consumers enjoy considerable protections when they use a major payment card. They can dispute transactions and, in some countries, their (credit) card issuer is jointly liable for failures of a merchant. Consumers like to be nannied… even if they have to pay for the privilege!

So for those who aspire to overturn the incumbents, you need a strategy for how you will become the consumer’s “default” or preferred payment mechanism.

American Express has achieved this through a joint strategy of having large corporates mandate its use for business expenses and offering generous loyalty benefits to consumers… they effectively pay their customers to use their cards.

PayPal has achieved it through making the payment experience easier – but note, even here, many PayPal payments are fulfilled by a credit card account!

And this is why I harbor doubts about whether Bitcoin will become a mainstream retail payments mechanism, at least in the major markets… why would a consumer prefer it over their card? Perhaps the openness and possible resistance to card suspension/censorship will attract sufficient users. But it’s not obvious.

For me, the opportunity lies elsewhere: high-value payments, smart property and so forth. But I could, of course, be wrong. It wouldn’t be the first time…

An aside on history and factual accuracy

I know this account would scandalize a historian but that’s OK: It’s not intended to be historically accurate… the idea is to share intuition on why things are the way they are.

Some of the more important topics I’ve ignored or deliberately simplified include:

I’ve not explored the difference between Visa Inc (public company) and Visa Europe (owned by its members)

I’ve ignored the “three-party” schemes like American Express.

I’ve also ignored fee structures and the importance of interchange.

I’ve also not discussed the role of processors… specialist firms who effectively outsource the work of issuers and acquirers

We’re now seeing serious projects work on this problem. Perhaps revisiting the fundamentals will help us predict which of these projects will prevail?

Why do we have exchanges in the mainstream world? There are lots of valid answers (liquidity, fairness, …) but none of this matters if you can’t be sure a trade you make will be settled. After all, what’s the point of agreeing a trade with somebody if they can just change their mind afterwards if it suits them?

Rule G5000 sums captures the critical function of the exchange for me:

“Obligation to settle: A member firm shall ensure that every on Exchange trade effected by it is duly settled.” Obvious, perhaps… but it needs to be said!

So the exchange helps ensure an orderly market by vetting and monitoring its members. This gives participants confidence: they don’t need to worry about who is on the other side of their trade. They know the trade they agree to will get settled. But other exchanges employ different models:

Prefund: Mt. Gox asked everybody to deposit their Bitcoins or fiat with them before they could trade. It guaranteed that trades executed on Gox would settle. Unfortunately, it only guaranteed they would settle on the books of Mt.Gox. As many people discovered to their cost, a settled trade on Gox was not the same as cash the bank or Bitcoins in their wallet

Escrow: The model I outlined in my piece earlier this year was essentially an escrow scheme. You place your Bitcoins beyond reach and they are either delivered back to you when your bid/offer expires or are delivered to the buyer. The trick here is in choosing the escrow “agent” (or agents…) carefully.

Clearing: This is how the The London Stock Exchange does it. In certain situations, members don’t even need to own the securities they’re selling at the time they trade them; they just need to make sure they deliver them as promised on the day of settlement. This model works because there is a closed group of trusted and well-known entities. However, there is clearly a risk: what happens if one of the participants goes bust between trade and settlement? That’s what a clearing house is there to solve, amongst other things. It keeps a close eye on its members, requires them to contribute to a “default fund” and steps in to make the other members whole if one of them fails.

Now, when we look at some of the most vibrant projects in the Bitcoin and cryptocurrency world, we see something interesting: a large number of them are working on representing non-crypto assets – such as securities – on the blockchain – They’re building out the vision of a decentralized general-purpose asset ledger.

There are two concepts we need to understand:

A token – something that represents an asset. Perhaps 100 shares of IBM Common Stock or ownership of a particular car.

An issuer – somebody that makes a promise to confer the rights and benefits associated with that asset to whomever holds it at any given point.

A concrete example: imagine I owned 10000 IBM shares (I wish…). I could issue them onto one of these platforms and publish the definition so others could see it and could see it was from me. I would, in effect, be making a promise:

“I will convey whatever benefits I enjoy through my ownership of these shares to whomever holds the token”.

So if I receive a dividend cheque, I pay it to the holder of the token. If you trust me to be good for this promise, you might be willing to purchase the token from me for $2m or so… the price of the IBM shares… owning the token would be just as good as owning the shares… and you could store it in your Bitcoin wallet and not have to deal with your broker any more!

Now, it is unlikely that you’d trust such a promise from me. But if was made by a major custodian bank you might. But note: you do have to trust the issuer.

So why bother? Why bother going to the trouble of building a decentralized asset ledger if you have to trust somebody at the end of the process?

For me, the answer is that this approach might allow increased competition between issuers. Furthermore, moving disparate asset registers (custody records, vehicle registration databases, etc) onto a common architecture might enable innovations we haven’t yet considered. It’s too early to tell so we can all be grateful to the pioneers who are experimenting so we don’t have to.

I think there are three broad camps:

Coloring Bitcoins. Projects such as chromawallet and coinprism are working on systems to “tag” Bitcoins so that they can be tracked across transactions

New Protocols Running Over Bitcoin. mastercoin and counterparty piggy-back on Bitcoin’s peer-to-peer network, double-spend protection and consensus system but their tokens are essentially independent of Bitcoins. A counterparty token is not simply a “tagged” Bitcoin.

I have no particular insight into the structure of any of these projects so let’s assume they’re all run by capable, honest people and further assume that we’ll see a future where assets of all types, including securities, will be represented on a blockchain-like decentralized platform.

Then what? Presumably people will want to buy and sell…. To exchange.

And that’s where things get interesting… because we have to solve the performance problem. We’re now in a decentralized, pseudonymous world… how do we ensure somebody who offers to buy an asset for a given price actually goes through with it and pays up?

What is the crypto-ledger rule G5000?

Is it possible to build a decentralized exchange on any of these platforms that has the strong performance guarantees we need? Can we build a decentralized exchange where a matched bid and offer inevitably lead to a settled trade?

It we look at our three models from previously, “clearing” isn’t going to work (it is, by definition, centralized and reliant on trusted identities). “Prefunding” is also problematic – what happens if the entity you sent your assets to disappears? So it looks like “escrow” is the only game in town.

Now, part of the solution already exists: we can construct “atomic” asset transfers using the Bitcoin protocol today. So I will assume exchanging payment and asset in a single transaction (“Delivery versus payment”) is achievable today on any of the platforms discussed above. But we need to get to a point where creating a valid transaction like this is inevitable once a bid and offer are matched.

Here’s where I think the state of the art is with the three approaches and it’s surprisingly different:

Coloring Bitcoins. The systems I’ve looked at don’t route bids/offers over the Bitcoin system so any matching will be done external to the platform. So it seems to me that “decentralized exchanges” on this model will have to require those posting bids or offers to demonstrate that they have placed the corresponding colored coins/Bitcoins in escrow with one or more acceptable third parties. There’s nothing that will do this automatically. So, it’s worth watchin firms like Xapo in the US and Elliptic in the UK. Professionally-run Bitcoin “cold storage vaults” such as these feel like “proto custodian banks” that could perform this function. The question is: can they devise a service that is sufficiently decentralized yet which still allows them to earn an income?

New Protocols Running Over Bitcoin. My understanding of these systems is that they embed bids/offers in the blockchain and have a protocol definition that means matches can be determined unambiguously. Furthermore, the act of making a bid or offer locks the associated assets until the trade is resolved or a bid/offer expires… automatic escrow, if you like. Assuming I am right, then this does appear to offer the “inevitability” promise that I think is so important. But it is at the expense of polluting the blockchain with bids/offers. It seems inelegant to me that one would store transient data (time-limited bids/offers) in such a permanent form of storage. But perhaps there’s no other way?

Entirely Separate Protocols. My working assumption is that NXT, too, works on the basis of bids/offers encumbering the associated assets until the outcome of the trade is resolved. With Ethereum, the answer to every question is, of course, “it’s Turing Complete so of course you can do it” but I need to dig a little deeper to be sure….

Where is this going?

I think we’re going to see a market test: the colored coin approach is, in many ways, the most elegant as it uses the blockchain solely for storing/transferring the asset. It means a range of exchange types can be trialled (escrow, pre-funding, reputation-based?)… but none of them will deliver full “inevitability” of settlement. Perhaps consumers will care. Perhaps they won’t.

Projects like mastercoin and counterparty look able to deliver on the “inevitability” promise but will it be at the cost of blockchain bloat?

It will be an interesting few months ahead.

A final thought… What if we simply don’t worry about it and price it instead?!

The other approach is completely radical… instead of trying to force performance, why not model it as an option? We can think of somebody who posts a bid/offer but who then reneges as exercising an option to renege. This option clearly has value – if they would lose money by completing the trade as agreed, the option payoff is at least as much as they stood to lose! So is it possible to model the value of the option to renege and force participants to pay the option value up-front in order to post a bid/offer?

Unanswered questions: to whom would the price be paid? Is there any precedent for modeling the “option to renege” in this way? What would be the liquidity implications?

Conclusion

I said at the start of this piece that a new financial infrastructure is being built “hidden in plain sight”. For the reasons outlined above, I think the “exchange” aspect of this infrastructure still has a long way to go but we’re about to witness a fascinating experiment.