When you hear “The Blockchain,” grab your wallet

All the “thoughtful” executive types (VCs, C-levels, analysts) now seem to share the same low-risk opinion about crypto-currencies.  (“Superficial contrarianism,” perhaps)

It goes like this: “Well, Bitcoin itself is in a bit of a speculative frenzy [knowing chuckle, transitioning to sober contemplation] … however, we think there’s tremendous promise in The Blockchain”

A year or three ago, this seemed like a reasonable stance (give or take the adjective “tremendous”). In 2014, mail-order heroin and low-stakes gambling were basically the only uses for Bitcoin itself.

But 2017 has been the year of the ICO, and the major coins have pretty demonstrably become targets of Real Money by now. So, where are all these promising applications?

Here are some real live examples of the cockamamie schemes that are purporting to use “The Blockchain” as of January 2018. Names have been withheld to protect the fatuous:

  • Copyright (or other intellectual property) registration
  • Paying people to look at advertisements on the Internet
  • CARFAX (automobile history)
  • Employment resume / C.V. verification
  • Basically all of corporate finance (M&A, debt, equity)
  • Foreign Exchange

What do all these things have in common? They are real-world difficulties that are worth paying money to solve. What else do they have in common? They are all things that can be very acceptable solved with pencil and paper, or at most, 1990s Oracle RDBMS type technology.

Why would people change their behavior and pay good money to move these processes to The Blockchain? Surely these proponents have a logic: there must be some particularly compelling piece about The Blockchain, right?

  • “It’s decentralized!”
  • “It is totally immutable!”
  • “It’s totally automatic [‘smart contracts!’] with no way to cheat!”

If you hear this level of glib bullshittery being slung your way as rationale for using The Blockchain for some application, better hold onto your wallet.

Thinking about markets, not technology

In a parallel to the abuse of terminology around the word “disruption,” where people misappropriate Clay Christensen’s theory and talk about technologies themselves as “disruptive,” blockchain cheerleaders talk about technological features as if they were ipso facto benefits.

But “decentralized” or “immutable” or “automatic” or whatever – aren’t necessarily benefits, much less unique and transformative catalysts for market value.

Starting with The Blockchain and trying to shoehorn it in to various market needs is backwards-minded and almost always going to fail. Here’s why.

The Blockchain is not a fundamental technological capability on its own. Rather, it’s a clever combination of three particular features – each of which is a well-understood [if arcane] and widely-available capability. If you need these three particular capabilities for your market application, then The Blockchain is your huckleberry:

1. Path-dependent, unchanging history,
… that works decentralized with
2. untrusted nodes and counterparties,
…and wherein you need to have
3. cheating discouraged by math, not by secrets.

What do these three things mean?

Path-dependent, unchanging history – More or less, this is a “ledger,” where the final state is dependent upon all the changes that went before. One key difference, though, is that in ledgers, you can often go back and insert transactions you forgot to record. Another is that, with ledgers, the final state doesn’t really depend on whether you cashed check #101 before #102, as long as they both got cashed before the reporting date. If you need to keep a ledger that can never be changed (fixed; or, in fairness, cooked) and where it really matters what order everything happened, you need yourself one of these. Happily, we more or less have them and we call them “append-only databases.”

Untrusted nodes and counterparties – In other words, do you need to reliably transact while also expecting that each person you deal with is trying to screw you, possibly with the collusion of at least several others? If you do, my apologies, and you should seek better friends, but at least you have the benefit of decades of academic research on things like the “Byzantine Generals problem,” along with algorithms that can be proven to keep things on the level even when dealing with a network of partially treacherous counterparties.

Cheating discouraged by math, not by secrets – Most of the time when we want to discourage cheaters or thieves, we require some secret-ish piece of information, like a PIN number, a password, or even the pattern of notches carved into a physical metal key. As long as you can make sure the non-cheaters have the secrets (and none of the cheaters have the secrets) this works well. If you can’t be sure of this, though, you can make sure that would-be cheaters have to prove that they’ve done lots of long division and shown their work longhand on paper, which takes some amount of time no matter how clever they are. This is more or less the idea of “proof of work.”

[Note: After circulating a draft of this post privately, I realized that I almost certainly read Tim Bray’s “I Don’t Believe in Blockchain” at some point last year and unconsciously plagiarized much of the above.  But, even on a re-read this is still mostly true and definitely how I’ve been thinking about this stuff.  So, although I promise I wrote all the words in the section above, let’s consider most of the ideas, right down to the use of specific phrases, to have come from Tim.]

Here’s the obligatory Venn diagram:

http://rlucas.net/crypto_currency_venn.pdf

Now, what kind of ice-cream sundae do you make with these three particular scoops? Bitcoin, of course. But what is it really useful for? Well, I would say, a medium-sized economy among participants who expect many of the others to be thieves, who are afraid of getting cheated by welchers yet need to trade with these snakes, and who have no way outside of their interaction to share secrets between themselves.

In other words, you have a technological mélange purpose-built for mail-order heroin. That’s basically it.

OK, snarky guy, are you saying there are absolutely no apps for The Blockchain?

Let’s try to be fair-minded here. What are some use cases that really could leverage (or perhaps even require) all of these core capabilities?

The Domain Name System et al. For example, Namecoin. You can imagine that the DNS might one day be (or is already) too big or unwieldy for ICANN to administer through its ICANN/Registry/Registrar/Registrant system. You might then imagine that it becomes much more practical to allow a blockchain-based system where a node can lay claim to a particular unused name after a proof of work, even if others upon seeing it would like to steal it away. This checks the boxes as being a good fit. However, for DNS (and for ARIN and BGP tables and many other things) simply having a means to definitively establish the truth isn’t enough; there’s also the operational side of giving up to date answers very quickly to billions or trillions of queries, for which the actual blockchain piece is useless.

Voting. If you want to have an actually fair election, being able to prove all the votes in an immutable and universally verifiable way, even with the vote-counters as adversaries, this could be a really good app. (Unfortunately it’s a dismal business.) Consider that here you expect everyone else to be a thief/welcher/vote-rigger, and the scale of the problem begs decentralization, plus, there are real practical issues with handing out secrets ahead of time.

Distributed Computation 1: Storage. For example, Filecoin. If you want censorship-proof storage of information, but you need to incentivize participants, Filecoin seems well thought-through. In order to serve both privacy and censor-resistance needs, you need to treat everyone as a thief, and you need to prevent anyone from changing history to be truly censorship-proof. Finally, in order to be sure someone has earned their incentive you need a proof of work. Very clever. Unfortunately, this is also a dismal business, mainly because the cost of storage keeps dropping, and the sorts of things that you really need to keep in a censor-resistant data store, at least in a rule-of-law Western society, are either truly nasty (kiddie porn, nuclear weapons secrets) or simply not that lucrative (proof of governmental wrongdoing / whistleblower leaks).

Distributed Computation 2: CPU. This isn’t built yet. But you could imagine a Filecoin-type system meant to incentivize participants to conduct computation on their own devices and send the results home – sort of a SETI@Home for the blockchain. The problem here is that to really reach venture scale, you will need to allow not just specialized processing of SETI signals, or protein folding, or various of the other specialized decomposed computation problems that are well known, but truly general computing that allows customers to reliably and securely get ad hoc compute jobs of all sorts done. This is much harder than storage; in storage, I can encrypt files or blocks and have a reasonable certainty that the actual storage nodes will never be able to read or tamper with them. In compute, this gets a lot trickier. Imagine doing, say, massively distributed OCR or video rendering. The algorithms to do the heavy lifting will require the input data in an unencrypted, unobscured form – the OCR will need to actually “see” the image in order to read the words. If you are running a malicious node, you can “see” the page I’m sending to you and you could likewise interfere with the results, without me ever knowing. It seems technologically plausible to be able to transform at least some subset of compute tasks in a way that effectively encrypts or obscures both the computation and the I/O – but to do so in a way that is efficient seems quite tricky. If this nut gets cracked, you could see something truly transformative, as it would have the functional properties of Filecoin but with potentially far more attractive unit economics.

What about applications that are partial fits, using at least 2/3 of these core capabilities?

Title plants (land ownership). In the U.S., thanks to some ancient English traditions we’ve inherited, nobody definitively knows who owns what piece of land. The way we solve for this is the quiet but giant title insurance industry, who guarantees the ownership interest. They in turn underwrite the ownership by accumulating “title plants,” which are basically databases from individual jurisdictions (counties, parishes, states, etc.) going back as far as they possibly can, showing all of the valid changes in title. A title plant is an immutable historical append-only record. It’s presently centralized (and this makes for quite a lot of jobs in county recorders’ offices around the country). But it also means that for transactions that “touch” the title to real estate, there’s a small but significant delay and hassle in recording all such transactions with the centralized keeper of the record. If title plants were maintained on blockchains, you could imagine that real estate transactions – not only sales, but mortgages, liens, etc. – could close in seconds at the swipe of a finger or the call of an API. Is this a venture scale opportunity? Certainly if you controlled it all, you could charge a handsome fee and displace the entire title insurance industry. However, it’s unclear that there is any market pressure to do this: most sales, mortgages, and liens involve many other moving parts and changing the turnaround time from one business day to a few seconds on the recordation is of questionable standalone value.

Anti-spam (and robocalls, etc.). It could be that a mix of the proof-of-work and byzantine generals capabilities might be a great recipe for collaborative approaches to stopping or reducing spam and robocalls, by imposing costs on nodes and sub-networks for bad behavior. There are lots of approaches to this problem, though, and it’s not clear that even 2/3 of the blockchain is important – proof-of-work alone might be enough (or you could also just impose tiny charges on each message without fancy crypto math).

That’s it. I’m sure there are more to be found, but not vast greenfields of more applications.

The Blockchain is more like XML than like the Web.

The Web exposed a way to connect mostly-already-existing information and transactions to millions, and shortly thereafter, billions, of people. Subsequently, and building upon that network, new kinds of interactions that were now possible became commonplace (i.e. “Web 2.0” or “social” and “collaborative” technologies).

But The Blockchain isn’t like that. The Blockchain is a technological mishmash of capabilities or features that, in the right spot, can help solve some tricky coordination problems. It doesn’t, on its own, connect people to things they largely couldn’t do before.

In this way, The Blockchain is more like XML. Does anyone remember the 1998-2003 timeframe and the hoopla about XML? At the time, a very valid point was made that markup languages (well, really just HTML) were part of a huge important wave (Web 1.0), and the thought was that this could be extended to all parts of the information economy. XML, as the sort of generalized version of HTML (pace, markup language nerds, I know “Generalized” has a special meaning to you but work with me here), was going to be transformative! After all, it was:

– Vendor agnostic! (hah)
– Text-based and human readable! (hah)
– Stream or Document parseable with off-the-shelf tools! (hah)

Well, it turns out that those things, even when they were all true, were just capabilities that were well suited for some real-world problems and not so much for others. In fact, it was mainly suited for data interchange in a B2B context, or for certain kinds of document transformations. Not particularly compelling for much else.

What was actually important then was the particular flavor of XML called HTML, and the absurd gold rush around that time surrounding it. HTML seemed approachable and it was El Dorado. Everyone and her brother were “coding” HTML and learning how to FTP GIFs to their servers. Eventually, most of those people and companies failed, but in the midst of that gold rush they created a ton of real value.

[One commenter who was early in the promulgation of XML objected a bit here.  I think this is fair.  I’m not saying HTML came from XML; rather, I’m saying that attempts to generalize the basic underpinnings of HTML/HTTP — the human-readable-ish markup for wide interop — fell short, because the tech underpinnings were less important than the entrepreneurial and speculative frenzy.]

What the real story of Bitcoin is.

The real story here is quite the opposite of the new sober conventional wisdom. It’s not the underlying blockchain technology that’s fundamental, transformative, or even particularly interesting.

What’s interesting is precisely the speculative bubble: the specific crypto-coin(s), or more importantly, the frenzy of activity by fortune-seekers drawn to this El Dorado.

The actual underlying technology happens to be a bunch of particular features and capabilities, some of which have been around decades, that happen to be very useful for the main original Bitcoin use-case (mailing around LSD blotter paper with the “B$” logo, or whatever).

The Blockchain of the dilettante investor’s imagination is some kind of brave new philosopher’s stone that can upend any business process. Bullshit.

The real opportunities here are going to be generated by lots of aggressive and more or less smart people feverishly trying new, heretofore “unfundable” things, financed by their own crypto-currency gains or more likely by the wild gambling of the pilers-on who missed the first wave. Some of these gold-rushers are going to create things of real value and of venture scale, if only by a stochastic process.

Tags: , , , , , , ,

2 Responses to “When you hear “The Blockchain,” grab your wallet”

  1. Ryan Harvey says:

    All your points are well taken, but aren’t you leaving out one reasonable (and potentially huge) use case for blockchain technology — that of, say, big banks with loads of derivative contracts between them? It seems to me that a ledger for all these transactions is best kept by either a third party or a shared ledger because neither bank will trust the other to maintain it, but they both need good, immutable, verifiable data on their exposures to one another.

    I confess that I don’t know how this essential task is performed today. My guess is that each bank keeps its own separate ledger and a copy of the “dumb contract.” Hopefully, those two things stay in sync between the two parties but I would bet that they don’t, 100% of the time, introducing cost and friction to the process.

    Maybe there are third-party services that perform this task but it seems to me an ideal use case for a private distributed ledger.

  2. rlucas says:

    Good point — certainly true for bilateral bespoke contracts.

    But shouldn’t we be hoping for clearinghouse-based netted derivatives to be the big bulk of the notional volume?

    If you do have a clearinghouse, that’s your third party right there.

    A step further that seems plausible with crypto wizardry would be to allow those distributed ledgers in fact to be public, but the contents encrypted except to the participants in a given contract — except in a winddown or insolvency situation, where a key escrow could permit others to make a given participant’s puts and takes transparent, so as to perform contingent netting of contracts…

Leave a Reply