The myth of The Right Stuff

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

This past week Joi Ito, director of MIT Media Lab, weighed in on the block size debate, stating:

The future of Bitcoin, decentralized ledgers and other Blockchain-like projects depends on this community. Many people call them “Bitcoin Core” as if they are some sort of company you can fire or a random set of developers with skills that you can just train others to acquire. They’re not. They’re more like artists, scientists and precision engineers who have built a shared culture and language. To look for another group of people to do what they do would be like asking web designers to launch a space shuttle. You can’t FIRE a community and, statistically speaking, the people working on the Bitcoin ARE the community.

The crux of his comment is that there is only a handful of people in the world who have the skills or as Tom Wolfe might call it, The Right Stuff.

the right stuff

Source: IMDB

Yet it’s unclear how many real blockchain engineers there are in the world.  Who are those capable of building from scratch a network with the features and characteristics of Ethereum, Zcash, Bitcoin or Ripple (among others)?

After all, there is no PhD in Blockchainology (yet) or Distributeledgerology (god help us) so how does one qualify?  By random lines of code in a github repo or hours spent in IRC chat rooms?

Maybe none of the above.

By all accounts, it is a hobbyist field in still — it is sufficiently esoteric that it’s not very accessible unless you have the time to decipher it on your own.  But there doesn’t appear to be anything magical about this technology either.

For instance, as a personal anecdote, last year I traveled as a guest lecturer with Blockchain University (which is on semi-permanent hiatus) to both India and Japan and gave several other guest presentations with BU throughout the year.  The primary goal of BU was to help educate developers — and some entrepreneurs — in the burgeoning artisan skill of block making.

While the learning curve was somewhat difficult (since Satoshi apparently uses every number format in the history of number formats), like all other technology, eventually developers got the hang of it.1

Similarly, many working groups at financial institutions exploring this technology are basically self-taught, autodidacts just like the rest of the community largely is.2

In other words, the problem with Ito’s comment is that it assumes that only the few dozen rocket scientists working in Peenemünde could possibly ever build rockets.  Whereas empirically, knowledge transfer occurred (via Operation Paperclip and Operation Osoaviakhim) and the ability to build rockets was disseminated worldwide, including the infamous shuttle he cites.

So too has the knowledge of building magic internet ledgers.

Groups such as Bitcoin Core may have some bright developers, but it certainly doesn’t have a monopoly on talent, especially when it comes to building and shipping commercial products for regulated financial institutions.  But the key take away is there are now tools and venues for IT team both small and large to learn and get up to speed on how this tech actual works, it is no longer siloed off in random IRC rooms or obscure crypto mailing lists.

  1. I would like to thank Ryan X. Charles for pointing that out; as an aside, I believe Ryan holds the distinction to have the first formal title of “blockchain engineer” at a non-Bitcoin company. []
  2. Actually there are quite a few financial engineers who have formal backgrounds involving elements of this technology as well as many bank architects who need to build and maintain stable, secure networks.  There are also various professors and cypherpunks who formally studied distributed computing/consensus in college involved too. []
Send to Kindle

Using just the “rails”

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

Yesterday the following question and comment was made to the previous blog post:

So just to be clear, you consider a company a “blockchain company” even if it runs its platform using Bitcoin’s blockchain as the rails ? For example, I believe Symbiont does this, but they certainly license out their software for a profit.

Yes, technically speaking using any blockchain as a “rail” (e.g., for storing or moving messages between parties) could effectively classify the startup as a “blockchain” company.  But I also think it’s worth looking at whether or not this is useful or even a wise decision.

In the short term, maybe: if a company only cares about distributing data to a geographically distributed third party, then using a blockchain as a “rail” could be a solution for a few problems.  For instance: Peernova, Chain, DigitalX (AirPocket) and others have built systems/platforms that are independent of a blockchain but then will store a “hash” of information onto a blockchain such as Bitcoin (typically via OP_RETURN).  This is a process called “anchoring.”

But you can actually “anchor” in multiple mediums, it just happens that this medium is what they have currently chosen to do in the short run (e.g., could also tweet it, post it on a public mailing list, broadcast it on TV, or if you are paranoid use a numbers station).  I wrote about the anchoring idea last month and previously elaborated why users such as banks do not need to use a public blockchain for anchoring.

There is another company called GuardTime that is pitching a “trust anchoring” service as well (called KSI).  Their product is similar to Surety which publishes hashes of data into newspapers.  If you are interested in this general idea, be sure to look into linked timestamping and “How to time-stamp a digital document” by Haber and Stornetta (and again, this is not an endorsement).

Regarding Symbiont, my understanding is that they are still using “embedded consensus” (based on their blog post) because their core team created Counterparty, which also uses an “embedded consensus mechanism” tied to Bitcoin.  Currently I do not think that it is a particularly elegant solution for post-trade but it may have its uses.  However that is a topic for another day (see this paper starting at page 5).

Source: Surety

Long term, no: I don’t think it is necessarily wise for Bob to rely or depend on Alice’s chain for the security of Bob’s chain.  It may be a short term stop-gap occurrence, but network designers should ultimately have to assume that other networks can become compromised and/or are unsustainable.  The network needs to be as self-reliant as possible.  And it is currently not possible to accurately forecast the security of Bitcoin (or other public blockchains) as it is economically driven – directly proportional to the market price of the tokens.

I think the drama around OP_RETURN size (40 versus 80 bytes) two years ago (see pages 29-30) and even the current block size debate should also serve as a cautionary tale to any organization looking at using a public blockchain.  Because of the way “decentralized governance” works (an oxymoron?), the end-users are at the mercy of nebulous governance structure that can arbitrarily nerf or take away a feature (like OP_RETURN) just as much as they gave it without direct feedback or recourse from the users themselves.

As an aside, there are also cross border/remittance companies like Align Commerce  that attempt to send bitcoins back and forth between liquidity providers/exchanges and do not rely on the appreciation or depreciation as part of their business model — in fact, they dislike any volatility as it harms their margins (e.g., they lock in a price for their customers for a short window of time).  But since they do not rely on bitcoins qua bitcoins, they could just as easily create and use their own proprietary ledger (it doesn’t even need to be decentralized).  Whether or not the “rebittance” business model makes sense is also another topic for another day (I recommend this post from Save On Send for starters).

Recall 15-20 years ago people used to attend “Internet conferences” and tell their friends that they were building an “Internet company.”  That sounds anachronistic two decades later.

Today a small business owner, Bob, would simply say he operates a small business that happens to have a website, but that doesn’t mean he is operating a website company.  Or if Bob accepted payments via Stripe, he wouldn’t say his company is an ACH or Stripe company – Bob is just using these “rails” as a means to an end.  Hopefully when all the hype and noise lowers over time we will begin to see the companies that are actually trying to create real commercial businesses that just happen to integrate with DLT, rather than everyone positioning themselves as a DLT company that might also have a commercial product.

Send to Kindle

Five frequently asked questions about permissioned chains

I was recently asked by someone: what are short arguments as to why permissioned blockchains are preferable than public ones for regulated financial services companies?

There are multiple reasons why permissioned blockchain are currently more appropriate than public ones specifically for regulated financial companies:
  1. Governance: public blockchains are designed around being censorship-resistant which makes the ability to change, enhance or upgrade the network difficult to do (e.g., as shown by the current block size debate).  “An Act of Congress” is the inside joke on how difficult it is supposed to be to make major changes to fully decentralized blockchains.  In contrast, permissioned chains are usually built with a known, agreed upon governance structure with explicit decision making processes.  One trade-off comes with reduced censorship-resistance.  See Appendix A for more.
  2. Most public blockchains were intentionally not designed around the needs of regulated financial institutions, quite the contrary: many were designed with the goal of circumventing institutions and regulatory bodies.  As a consequence, they likely cannot in their current form fulfill the functional and non-functional requirements that large regulated financial institutions need in order to operate.  And in order to modify an existing public blockchain to do so, you typically end up breaking their core utility (censorship resistance)
  3. Financial institutions need to know who they are dealing with, who their counterparties, customers and staff members are.  As a result, architects building systems for financial institutions have a different set of design assumptions than those programmers designing public blockchains.  In short: participation and validation on a permissioned blockchain involves known, trusted parties that are legally obligated to perform certain tasks.  In contrast, participation and validation on public blockchains is assumed to involve, unknown and untrusted parties hence the reason for proof-of-work.  If financial institutions are already working with trusted parties, then design features found in public blockchains — like proof-of-work — effectively are very expensive dice rolling machines, they provide no real utility other than to generate random numbers.  And to compound this issue, due to AML / KYC / KYCC regulations for financial institutions in many countries, payment service providers (which effectively what “mining pools” are) potentially requires KYC of the mining pool.  If you know the identities of all the pools then you are no longer operating an unknown network, the design assumptions change.
  4. Who are you going to call when something goes wrong with a transaction?  For instance, in the traditional financial world, institutions and organization create and sign service-level agreements with service providers: contracts with specific guarantees and conditions — along with clauses for when something goes wrong (e.g., customer service reqs).  In a permissioned blockchain ecosystem, this tradition will continue because mistakes will be made and will need to be fixed.  In contrast, when something goes wrong or is broken on a public blockchain, you are probably out of luck unless you know some mining pool operators.
  5. Sustainability.  Because public blockchains are effectively unowned, then you end up recreating a ‘tragedy of the commons’ in which no one wants to pay but everyone wants to use.  We see this with the Bitcoin network, where no one wants to pay (higher) fees to use the network and no one wants to pay developers to enhance the network.  As a consequence, there are now over 100 dead altcoins because their was no incentive to maintain the network — the commons collapsed as it was no long sustainable to operate via charity and altruism.  In contrast, permissioned blockchains are closer to owning private property: a set of stakeholders have a direct incentive to maintain the network through business and commercial incentives.  This is not to say that either Bitcoin or Ethereum will collapse tomorrow, but the longevity of a public blockchain is an open question.
Send to Kindle

The Cool Kid at School

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

Earlier this week a piece appeared on Yahoo with a number of quotes from individuals who are trying to create a new narrative for why “Blockchain” is the cool kid at school right now.

Stating:

“I can see why banks are interested in using permissioned ledgers, and maybe it will make their back office more efficient,” says Jerry Brito, executive director of digital currency nonprofit Coin Center. “But at the end of the day, it’s not a very exciting innovation. The real innovation is a completely open and global ledger that is permission-less. Having a closed, permissioned ledger run by banks, that might allow for better auditing, but there’s no innovation there, you still have to go through a consortium to use the ledger.” That is, what banks seem to want to do is incongruous to the purpose of the blockchain.

The claim in here is false.  In fact, this line of reasoning is literally the No True Scotsman fallacy (or in this case, no true ledger fallacy).

There is a lot of real innovation going on behind the scenes (and a lot of non-innovation going on too) by several dozen companies building new types of applications that couldn’t really work on public blockchains (due to the lack of definitive legal settlement finality, governance, scalability and capacity — among other reasons).

Innovation and ideation are occurring, it just isn’t happening with Bitcoin or with some Bitcoin companies beyond trying to ignore state, federal and international laws (slightly kidding).

Furthermore, not all ledgers are alike.  To claim that technology is “incongruous” because it isn’t fixed to the original project is a non sequitur.

Bitcoin visualized how and what one application of distributed ledger technology could look like.  It showed, much like the Wright Flyer and the Benz Patent Motor Car previously did, how cobbling together existing pieces could provide a new form of utility.  But for something important like regulated capital markets you wouldn’t continue reusing experimental tech just because it already exists. That’s a sunk cost fallacy.

The original Mercedes

Continuing:

But Brito also believes the interest will subside once banks actually learn more about blockchain technology. “I think right now investors are kind of waiting for Wall Street to get through this blockchain phase,” he says. “They have blockchain fever and they need to just get over it. Because if they develop their own closed blockchains, soon they’ll all realize they want to talk to each other, and they’ll be back to square one, doing banking.”

This is also untrue.  There have been between 150-200 pilots and proof-of-concepts for banks that utilize some type of cryptocurrency (or fork thereof), nearly all of which have been rejected.  Not because the banks are “anti-bitcoin” or “don’t get the blockchain” but because Bitcoin doesn’t solve the actual problems banks actually have — it wasn’t designed to.

Furthermore, as I have repeatedly explained — as early as September — in both public and private venues that:

1) the ledger/network/fabric will be open sourced
2) that recreating lots of silos probably isn’t very productive

There has been a lot of backlash from some members of the cryptocurrency because their bet hasn’t paid off but it’s disingenuous to create a narrative that is factually untrue.

I certainly cannot speak on behalf of banks, but if the goal is to get banks and other financial institutions to actually use a product then the product needs to actually provide a solution for them; cryptocurrencies as they currently exist weren’t built with their needs or requirements in mind, so why would they use them?

Send to Kindle

What is the difference between a Bitcoin company and a Blockchain company?

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

Let’s be clear: to do anything on the Bitcoin blockchain (the data structure) a user must use bitcoins.  There is no other native currency/commodity/receipt built into the ledger that enables users to do something on the Bitcoin network.

So when Bob says: “My company uses Blockchain” — what does that mean?  Does that mean he is using the Bitcoin blockchain to do something?  Does that mean he’s using another distributed ledger altogether?  Does that mean he hates definite and indefinite articles (a, an, the)?

Where is the line between a Bitcoin company and a Blockchain company?

First off, I dislike the term “blockchain” because it is so vacuous and vague.  At fintech conferences, when presenters say “blockchain” most people in the audience probably think of a database run by air-gapped computers in missile silos or something else from a sci-fi movie.  When panelists at Davos say “blockchain” it is probably just short hand for all of the warm and fuzzy bits of moon math invented at MIT which we think protects our bank accounts.

In December I mentioned it was a bit like gluten, everyone is talking about it but no one knows what it is in great detail.

Last week, a PwC article on LinkedIn stated that:

“So, to help make sense of the market for ourselves and others, we invested approximately 10,000 hours to evaluate what is now more than 1,000 blockchain companies.”

In the ensuing Twitter thread, I pointed out that there are not 1,000 blockchain companies.

In response, a team member from PwC tweeted the following screenshot of the PwC library:

My point regarding Bitcoin companies not being blockchain companies has to do with what venture firms like Nyca Partners categorize activity by.  They have five characteristics including: does your platform/product depend on a cryptocurrency appreciating in value or not?

In contrast, “Blockchain” platforms, of which there are probably less than 50 (certainly not 1000) are not setting out to build convertible virtual currency systems.  They do not need to burn mountains of coal to secure their network because they operate in a different environment where the platform or application is the actual utility.

Put it on a sticky note: the appreciation of a token (or whatever it might be called) is not the business model for blockchain companies — the uptake and adoption of the platform and application are.

Bitpay is a bitcoin company because its business model depends exclusively on the uptake in usage of the token (bitcoins) and the value of the token appreciating — the token is the business model.  In contrast, Chain is no longer a bitcoin company — the token is not their business model, uptake of their platform is.

Conflating the two worlds, like some investors do, creates confusion in an already noisy marketplace.

For perspective, since September I have been pitched or spoken to ~125 companies that claim they are building or relying on some type of distributed ledger.

This also includes  various repurposed altcoins and Bitcoin companies that are reliant on bitcoin, the token, to appreciate in value in order for the company to profit.  In other industries that type of bet is called “a hedge fund” except many of these forget to do the hedging part.

If you’re interested, I gave a presentation in December explaining the diverging ecosystems.  One is not better than the other.  The two can and will coexist.  But the two are not the same thing.

Send to Kindle

AT&T is the only tested and secure telecommunication system, the rest are altscams

[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 FidoNetMojoNation & BitTorrentNapsterGnutellaeDonkey,Freeneti2p 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]

Send to Kindle