[Note: opinions expressed below are solely my own and do not represent the views of my employer or any company I advise.]

Over the past several weeks there has been a concerted marketing push by several Bitcoin investors and enthusiasts to promote the view that banks do not want new(er) technology.  That bitcoind (one Bitcoin implementation maintained by a group called “Core”) can satiate the needs of organizations big and small and that other distributed ledger efforts are vain, insecure and snake oil.

This anti-competitive line of reasoning is reminiscent to the early-80s when AT&T was broken up into Baby Bells and had to compete with new market participants.  Sure there were several ne’er-do-well fly-by-night telecom startups that popped up, but this downplaying of new distributed ledger efforts is basically Luddism against new techniques and competitors.

So what actually do regulated financial institutions want?

I have flown almost 50,000 miles the past 6 weeks and personally speak to about 4-5 banks face to face each week.  Many of them have forked, poked and prodded a handful of platforms, including variants of Bitcoin itself.  Yet I don’t think they have ever said, “you know what Tim, we want to reuse bitcoind because it’s been around for longer than Alice’s solution.”  Banks want solutions to their problems and bitcoind is not necessarily one of them; it wasn’t designed to be a solution to their problems.

While I cannot speak on behalf of banks or the roughly two dozen distributed ledger efforts (slide 21) out there, many of the elements within their proposals actually have some of the same elements reused in Bitcoin, Ethereum, Ripple and Open-Transactions.

It bears mentioning that all of the key elements of Bitcoin itself are more than 15 years old now and that no company unilaterally invented or wrote the Core code commonly used by mining pools today.

According to Gwern Branwen this includes:

1. 2001: SHA-256 finalized
2. 1999-present: Byzantine fault tolerance (PBFT etc.)
3. 1999-present: P2P networks (excluding early networks like Usenet or FidoNet; MojoNation & BitTorrent, Napster, Gnutella, eDonkey,Freenet, i2p etc.)
4. 1998: Wei Dai, B-money
5. 1997: HashCash; 1998: Nick Szabo, Bit Gold; ~2000: MojoNation/BitTorrent; ~2001-2003, Karma, etc
6. 1992-1993: Proof-of-work for spam
7. 1991: cryptographic timestamps
8. 1980: public key cryptography
9. 1979: Hash tree

And as I have mentioned previously: if Satoshi had wanted to design a network for regulated financial institutions, it would look different than what Bitcoin does today.  Why?  Because the problems financial institutions are different than the problems cypherpunks have.  So some of those elements above, like proof-of-work, are entirely unnecessary in a different environment.

If you had a chance to start from scratch, what would that network architecture look like?  Would it even be a chain of blocks containing hashes in them?  Maybe not.  And if not, then reusing bitcoind because you have already put millions into development behind bitcoind is a sunk costs fallacy.

What about the view that bitcoind is the most battle-tested distributed ledger code base?  Aren’t all the new efforts just closed source Excel sheets filled with backdoors?

This is factually untrue. Some Bitcoin enthusiasts make it sounds like all of the other two dozen ledger projects in this space are not going to be open sourced, or peer reviewed or publicly tested.  As far as I know, most of the new efforts are genuinely interested in making most if not all of the lower layers of their tech open.  Some of them are already contributing to the new Linux Foundation effort.

This is also a false dilemma, to make it sound like the only two choices in the world are the “tested” sacrosanct Bitcoin code base versus “untested” hill billy code.

If by “tested” proponents mean it has been running for a while and some of its faults are plainly evident then there’s some merit in that, but you could use the same logic to argue that SWIFT is the only tested and secure financial network therefore don’t create new rails.

Yet even if it were true it is irrelevant: security is only as good as its weakest link. The security of systems in this space will depend on the properties of the overall system, not just one component.  So all the stuff Bob builds on to and around it has to be secure too.  And if that is compromised and over complicated because Bob is contorting himself to fit into the Bitcoin model, what has Bob gained?

A non-starter

The basic vision of several Bitcoin marketers is to push the narrative in which non-Bitcoin ledgers are fully dependent on the security of the Bitcoin network itself.  Several proposals involve some type of sidechain, a dubious technique that purportedly involves merged mining, which itself is unsustainable (see pgs. 20-22).  That in this scenario, regulated financial institutions with trillions of dollars under management operating on trusted networks would for some reason want to rely on an unsustainable public good.  That Bitcoin becomes the ultimate trust anchor in the world.

This ignores the requirements that enterprises have.  Not only do regulated financial institutions have a lot of real concerns surrounding probabilistic settlement finality and untrusted validators — none of which goes away with wider adoption of Bitcoin — but there are many different ways to “anchor” data that does not involve burning mountains of coal in China or subsidized hydroelectricity in Washington.

The “bitcoin codebase is the only tested/secure code” also relates to the meme of “everyone should use bitcoind as otherwise we’re in danger of hard forks.”

This is short sighted engineering; a more appropriate motto would be because of the danger of hard forks, we want everyone to diversify the code base.  This then ties back in to Dan Geer’s infamous monoculture jibe.

It is also strategic marketing on the part of Bitcoin maximalists: if they can convince everyone of the meme “everyone use the bitcoin codebase” while at the same time capturing the power of Bitcoin Core into one small group of companies that handles the hard code then they will have convinced the market that their solutions are irreplaceable, which, while of no particular technical merit, has the benefit to the few of being a self-fulfilling prophecy.

And what about all those “unnecessary” customized bells and whistles new distributed ledgers provide to financial institutions?  Can’t plain old vanilla Bitcoin provide everything a customer could want?

Dispelling myths could be a full time job in this space, but this comment has also become part of the bitcoind zeitgeist: that financial institutions are wasting their time looking at customized ledgers when Bitcoin startups and its ecosystem are a one-stop shopping center capable of satiating the wants and needs of financial institutions.

The reason why Bitcoin is not being used by financial institutions is simple: it does not and cannot meet their needs because it wasn’t designed to do so.  And in order to “fix” the perceived issues you end up removing the core utility of public blockchains, such as censorship-resistance.

Based on what we have seen and heard, banks have done by now hundreds of pilots and proofs of concept and in almost all cases those PoCs have been rejected.  The reasons are almost always the same – they don’t meet the banks’ needs – but where’s the credible debate on what those needs are?  Surely some of the banks must have told some of those providers some hint, even if by accident.  If nobody’s listening to the feedback being handed out, it’s no wonder Bitcoin is stuck in an echo chamber.

There will likely not be one codebase or one ledger to rule them all and it is important for regulated organizations to continue doing due diligence not just on the functional abilities of proposed ledger solutions, but also the veracity of the claims of the proponents.

[Special thanks to the architecture working group for their constructive feedback]