I am frequently asked this question because there is some confusion related to the legacy name and the current branding of certain technology. The two are distinct. And how we got there involves a little history.
Hyper, the parent company of Hyperledger, was founded by Dan O’Prey and Daniel Feichtinger in the spring of 2014. Fun fact: one of the alternative names they considered using was “Mintette.com” — after the term coined by Ben Laurie in his 2011 paper.
The simplest way to describe Hyperledger, the technology platform from Hyper, during its formative year in 2014 was: Ripple without the XRP. Consensus was achieved via PBFT.1 There were no blocks, transactions were individually validated one by one.
Hyperledger, the technology platform from Hyper, was one of the first platforms that was pitched as, what is now termed a permissioned distributed ledger: validators could be white listed and black listed. It was designed to be first and foremost a scalable ledger and looked to integrate projects like Codius, as a means of enabling contract execution.
Most importantly, Hyperledger in 2014 was not based off of the Bitcoin codebase.
Note: in the fall of 2014 Richard Brown and I both became the first two advisors to Hyper, the parent company of Hyperledger. Our formal relationship ended with its acquisition by DAH.2
In June 2015, DAH acquired Hyper (the parent company of Hyperledger) which included the kit and caboodle: the name brand, IP and team (the two Dans). During the same news release, it was announced that DAH had acquired Bits of Proof, a Hungary-based Bitcoin startup that had designed a Java-based reimplementation of Bitcoin (which previously had been acquired by CoinTerra).3
It was proposed at that time that Hyperledger, the Hyper product, would become the permissioned ledger project from DAH. It’s product landing page (courtesy of the Internet Archive) uses roughly the same terminology as the team had previously pitched it (see also the October homepage older homepage for DAH as well).
Source: Digital Asset / Internet Archive
On November 9, 2015, on a public blog post DAH announced that it was “Retiring Hyperledger Beta, Re-Open Sourcing Soon, and Other Changes.”
The two most notable changes were:
(1) development would change from the languages of Erlang and Elixir to Java and Scala;
(2) switch to the UTXO transaction model
The team noted on its blog in the same post:
We are also switching from our simplistic notion of accounts and balances to adopt to de facto standard of the Bitcoin UTXO model, lightly modified. While Hyperledger does not use Bitcoin in any way, the Bitcoin system is still extremely large and innovative, with hundreds of millions of dollars invested. By adopting the Bitcoin transaction model as standard, users of Hyperledger will benefit from innovation in Bitcoin and vice versa, as well as making Hyperledger more interoperable.
During this same time frame, IBM was working on a project called OpenChain, which for trademark reasons was later renamed (now internally referred to as OpenBlockchain).4
IBM’s first public foray into distributed ledgers involved Ethereum vis-a-vis the ADEPT project with Samsung (first announced in January 2015). Over the subsequent months, IBM continued designing its own blockchain (see its current white paper here).
In December 2015, the Linux Foundation publicly announced it was creating a new forum for discussion and development of blockchain technology. Multiple names were proposed for the project including Open Ledger (which was the name originally used in the first press release). However, in the end, the name “Hyperledger” was used.
How did that occur?
DAH, one of the founding members of the project, donated two things to the Linux Foundation: (1) the brand name “Hyperledger” and (2) the codebase from Bits of Proof.
Recall that Bits of Proof was the name of a Bitcoin startup that was acquired by DAH in the fall of 2014 (the Chief Ledger Architect at DAH was the co-founder of Bits of Proof). 5 Architecturally, Bits of Proof is a Java-implementation of Bitcoin. 6
In other words: today the term “Hyperledger” represents an entirely different architectural design and codebase than the original Hyperledger built by Hyper.7
The major architectural switch occurred in November 2015, which as noted above involved adopting the UTXO transaction set and Java language that Bits of Proof was built with. Therefore, Hyperledger circa 2016 is not the same thing as Hyperledger circa 2014.
Over the past two months there have been multiple different codebases donated to the Linux Foundation all of which is collectively called “Hyperledger” including the IBM codebase (partly inspired by Ethereum) as well as the DAH and Blockstream codebase (one is a clone of Bitcoin and the other is a set of extensions to Bitcoin). The technical discussions surrounding this can be found on both the public Linux Foundation mailing list and its Slack channel.
How do different, incompatible codebases work as one?
This technical question is being discussed in the Linux Foundation. It bears mentioning that as of now, the codebases are incompatible largely due to the fact that Bitcoin uses the UTXO transaction set and OpenBlockchain uses an “accounts” based method for handling balances. There are other reasons for incompatibility as well, including that they are written in completely different languages: Java/Scala versus Go versus C++ (Blockstream).
How extensive is the reuse of the Bits of Proof Bitcoin codebase donated to the Linux Foundation from the DAH team? According to a quick scan of their GitHub repo:
So when someone asks “what is Hyperledger technology?” the short answer is: it is currently the name of a collective set of different codebases managed by the Linux Foundation and is not related to the original distributed ledger product called Hyperledger created by Hyper. The only tenuous connection is the name.
Timeline in brief: Hyperledger was originally created in Spring 2014 by Hyper; Hyper was acquired in June 2015 by DAH; the original Hyperledger architecture was entirely replaced with Bits of Proof in November 2015; the Hyperledger brand name and Bits of Proof code was donated to the Linux Foundation in December 2015.
Interestingly enough, the current OpenBlockchain project from IBM also uses PBFT for its consensus mechanism and uses an “accounts” based method; two characteristics that the original Hyperledger platform from Hyper had too. [↩]
Following the bankruptcy of CoinTerra, the Bits of Proof team became independent once again. [↩]
CoinPrism launched a project called OpenChain, before IBM did. [↩]
Sometimes there is a confusion between Bits of Proof and Bits of Gold. Bits of Proof was the independent Java-implementation of Bitcoin (which is not the same thing as bitcoinj). Bits of Gold is an Israeli-based Bitcoin exchange. A co-founder of Bits of Gold also works at DAH and is their current CTO. [↩]
In the future it may contain some modifications including Elements from Blockstream. [↩]
What was once the original Hyperledger GitHub repo has been handed over to the Linux Foundation but some of the original code base and documentation from the 2014 project canstill beviewed elsewhere. [↩]
[Note: I neither own nor have any trading position on any cryptocurrency. The views expressed below are solely my own and do not necessarily represent the views of my employer or any organization I advise.]
Below are several questions I recently received from the CFA Institute along with my responses.
Q1. In your book you make a convincing case that Bitcoin has a number of significant structural design flaws that will likely prevent it from ever develop into something of economically meaningful scale. Could you briefly outline the main reasons for your view?
A1. The two fundamental challenges that do not appear surmountable in the short-run are:
(1) An endogenous money-like informational commodity (such as bitcoin or litecoin) that lacks purchasing power stability relative to goods and services which live external to the system. This is a characteristic that is common to contemporary cryptocurrencies that are divorced from external information: how to securely provide information of the exogenous outside world back into the internal network in a trust-minimized manner? There have been multiple proposals over the past 2 years but no production systems in large part because solving this is solving a public goods problem, so where does the funding come from to R&D it?
(2) The second main challenge is sustainable decentralized security. Empirically all proof-of-work based cryptocurrencies have trended towards some form of centralization. Looking at CoinGecko, all of the top PoW cryptocurrencies are currently dominated by a handful of pools. The reason why has to do with the inhomogeneous Poisson process used by these systems which creates variance in payouts. And as we see in the world of traditional finance, one way to reduce risks is to pool capital. Thus, with the origination of the first mining pools in late 2010, we see miners – the security force – acting rationally by pooling hashrate to smooth out the variance in payouts.
Ernie Teo and Dave Hudson are just a handful of researchers who have looked into the long-term implications this has and have shown via simulations that as block rewards decline over time, the labor force declines as fewer participants can profitably compete in the mining process. Thus there is an open question as to whether or not any PoW cryptocurrency can remain robustly decentralized and secure or if they just “self-destruct.” Note: that there are over 100 dead altcoins, so empirically these networks are not automatically self-healing or anti-fragile.
Solving both of these issues – if they are indeed solvable – so far has remained in the realm of posturing on social media: very little real research and statistical modelling has taken place which is very surprising considering many companies have raised funds with the assumption (and promise) that these two issues will be solved.
I remain skeptical that the first is solvable without compromising the integrity of the network: how do you rebase the purchasing power of an endogenous unit of account without needing to trust the external data source? Vitalik Buterin, Robert Sams and a few others have proposed solutions dubbed “stablecoins” but most of the community, especially early adopters of popular cryptocurrencies are against purchasing power stability, preferring volatility with the belief that external market forces will somehow coordinate and permanently smooth it out, usually in a trajectory towards the moon.
Similarly I have yet to see any modelling that shows how POW mining becomes more decentralized over time. There have been companies that claim and market that they will “redecentralize” with embedded ASICs, but when you drill down deeper it is merely decentralizing hashing, not block making (the key part).
Q2. There seems to be a new consensus developing in fintech circles and among incumbents of ‘Bitcoin bad, blockchain good’. Do you agree with this or is it too simplistic – can you truly have one without the other?
A2. I think it is too simplistic and a little unfair to Bitcoin. Satoshi, from his written accounts, did not appear interested in developing software for financial institutions. He had a problem-set in his mind: how to build a censorship resistant payments system without introducing some kind of trusted third party to prevent double spending. In 2007, when he began the project (or so he stated on a mailing list) if he had thought about how to build a distributed ledger for regulated financial institutions, the deliverable would look different than Bitcoin does. We only have the benefit of hindsight to make that “Blockchain good, Bitcoin bad” claim today.
Why? Because quite frankly, Bitcoin itself does not really solve anything for banks.
Banks have seen probably 100-200 proof-of-concept/pilot projects over the last 18 months and have rejected nearly all of them. Not because it involved a cryptocurrency but because the tech didn’t solve their actual problems. I have yet to be in a meeting where someone says “I hate bitcoin because it is bitcoin” — perhaps some banks do, but all of the people I interact with at banks want solutions to their problems and cryptocurrencies in their current form, were not designed to solve problems banks have. So why should they use them?
For instance, if I built some typewriters and then claimed that banks weren’t buying them because they’re anti-typewriter. It’s not because they are anti-typewriter it is because they don’t have a use for typewriters in 2016. Yet the useful parts of typewriters are of course the keyboard which can be repurposed and used with laptops. Similarly, the useful bits of cryptocurrencies are the cryptographic signing and shared data structure elements.
Q3. Incumbent organisations experimenting with blockchain technology seem to be mostly designing permissioned blockchains. Could you elaborate on how these differ from, for example, the Bitcoin blockchain, and some of its advantages and disadvantages?
A3. Since September 2015, R3 has been pitched by over 100 software companies ranging from pre-seed startups to large enterprises. Among them are about 30 different distributed ledger proposals. Some are very much half-baked altcoins. A large number are highly modified derivatives of existing platforms (e.g., Bitcoin, Ethereum, Ripple) and a few others were customized and built from the ground up or with elements of existing systems. Universally they all involve some kind of permissioning: in which the validators on the network are gated and vetted and the users of the network are KYC’ed.
Why are they building these? There are a number of different motives but by and large this has to do with the operating environment their customers exist in: trusted, known relationships. Those relationships, market structures and laws, much to the chagrin of cypherpunk prophecies, are not going to disappear. So if you are building a commercial business and want to actually generate revenue and not permanently live off of venture funding, you will need to deliver products customers want and not just work on public goods problems.
Another advantage of designing these types of permissioned systems is that the validation model – the creation of contracts and service level agreements around who or what validates transactions – typically removes the probabilistic settlement issues found in public blockchains like Bitcoin. Public blockchains cannot provide legal settlement finality of exogenous financial instruments. And introducing new risks into the financial system via probabilistic finality is absurd. Regulated financial institutions cannot and do not want to be in a position in which assets on their balance sheet only have a 95% possibility that they own them or that a block reorganization from a pool in a sanctioned country mines it.
Incidentally there are now Bitcoin mining companies that are pitching themselves as “trusted miners” – which is an oxymoron. In fact, if the validation process (mining) of public blockchains becomes fully trusted, gated and permissioned then users lose the benefit of censorship resistance while they simultaneously have to pay the large operating costs that proof-of-work requires. Or in other words, a permissioned-on-permissionless system that provides more kabuki theater than it does commercial utility.
Q4. Increasingly, financial institutions are trying to figure out whether they can benefit from integrating blockchain technology into their operations, including your organisation R3CEV. What do you see as the main barriers of integrating blockchain into existing financial services?
A4. There are multiple challenges each financial institution has and technology alone probably only solves a fraction of them. For instance, what are the problems a blockchain actually solves for an organization? Maybe there are only a handful if any. What are the switching costs? What are the total costs of operation? How does it plug into their existing legacy systems?
Most startups lack the subject matter expertise or the relationships into the financial services industry to be able to answer those questions, so they end up building tech for tech sake. Science fair projects that remain underutilized and even unused. No amount of marketing can ultimately salvage a platform that does not solve a problem that customers do not have.
[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.
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.
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. [↩]
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. [↩]
[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).
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.
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:
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.
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)
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.
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.
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.
[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.
“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
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?
[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.
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?
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]
[Note: opinions expressed below are solely my own and do not represent the views of my employer or any company I advise. Today is the 7th anniversary of the Genesis block.]
With over $900 million invested in cryptocurrency startups over the past couple of years, what does adoption and usage numbers look like?
Unfortunately very few of the companies that have received funding have publicly divulged actual numbers, primarily because consumer uptake has been lower than expected (or promised).
For instance, Coinbase recently published five charts it says reflect growth.
The first chart they show is transactions per day.
However, since we know that most transactions are “long-chain” transactions (comprised of spam, wallet shuffling, coin mixing, mining payouts, faucets, etc.), this is a poor indicator of actual on-chain trade and commerce or adoption.
As illustrated in the chart above, once long-chains are removed, growth (as highlighted in the pink region) is roughly linear since 2014, at ~0.5x per year.
What about Coinbase itself?
Coinbase doesn’t typically divulge much about specifics, however it’s older pitch deck (from September 2014) does give a few details about its users, such as 40% of all Coinbase users are from three states: California, New York and Texas; as well as the amount of deposits that Coinbase holds for each customer.
While this number likely has changed in the past 15 months, ignoring the fluctuation in token prices it may be the case that the average deposit per customer has not increased significantly. Why might that be?
Above is a 1-year chart produced by Coinbase showing the daily amount of off-chain transactions. Or rather, transactions that take place on their own internal system. As we can see, the volume is roughly the same across all of 2015. If usage actually was increasing or user numbers were growing substantially, then we should be able to see some visible changes upward. This has not occurred.
P2SH, or pay to script hash, is probably the most common method for securing bitcoins (or UTXOs) via multisig. As shown in the two charts above, over the course of 2015 the percentage of existing bitcoins held in P2SH addresses increased from 6% to around 10% today. Though over the past 5 months the amount has effectively plateaued.
According to marketing material, BitGo processes more than 50% of all P2SH transactions (more than all other service providers combined). So this may also be an upward bound indicator of people who are savvy enough to secure their bitcoins via multisig (note: many custodial wallets such as Coinbase and Xapo purportedly secure certain layers of “cold wallets” via multisig and P2SH is just one method of doing so).
The chart above visualizes the percent of bitcoins owned by each address balance range.
As of block height 390,000 approximately 98.16% of all bitcoins reside on 513,648 addresses. This is not to say there are only half a million bitcoin users on the planet, as some of the addresses are owned or controlled by multiple people (such as a custodial wallet or exchange). But it is probably a pretty good proxy of on-chain users — users who actually control the private key and do not use an intermediary.
This is roughly twice as many on-chain users as twenty-one months ago (in April 2014) — at block height 295,000 — when I first started looking at this source.1
One interesting trend that ties in with the multisig window above is that at one point as recently as April 2014, none of the Top 500 addresses were using multisig. But over the past year, as seen by the “3” prefix at the start of addresses, we can visibly see several dozen Top 500 addresses that now use multisig (note: some of the other addresses may use hardware wallets such as Trezor, Ledger or Case and not use multisig).
I once heard a Bitcoin reporter tell me in the August 2014 that BitAccess was on track to be the first billion dollar Bitcoin company. Whoops!
As we know empirically, the ATM industry in general is very low margin; companies make it up on volume which none of these startups have been able to thus far. Despite the hype, over the past a grand total of 536 Bitcoin ATMs have been installed, roughly 275 per year.
For comparison, according to the ATM Association there are roughly 3 million ATMs globally.
Can’t this change in the future? Perhaps, but recall that the average two-way (roundtrip) Bitcoin ATM fee is ~11% and there are only a handful located in emerging markets. Why is the fee relatively high? Because ATM owners are not operating charities and want to turn a profit. If Bitcoin adoption truly was going gang busters you would expect this number to be growing exponentially and not linearly.
Admittedly this chart doesn’t have to deal with adoption. There is no scientific correlation between the amount of usage or users of cryptocurrencies and the volatility of its trading pairs.
The reason I have included this is because in the Coinbase post above they state that bitcoin volatility is decreasing… relative to the Russian ruble and Brazilian real. Yet from the volatility chart above, it is clear that volatility has not really decreased. The BTC/USD volatility may be less than what it was in 2012, but on any given day it is still 10x more volatile than CNY/USD and 6x more volatile than USD/EUR — trading pairs that represent the real lionshare of global economic activity.
What it shows is that VC investment in cryptocurrency-related startups peaked in Q1 2015. Yet, the bulk of the Q1 investments came from the 21inc announcement which itself was an aggregation of its previous rounds that had taken place over the previous 18 months. So funding may have actually peaked in Q4 2014.2
What this probably illustrates is that aside from a couple of permabull investors (such as Boost and Pantera), most serious venture capital has decided to wait and see how the dust settles before investing anything in this space. Why? Basically there has been no product market fit and few viable business models.3 Sure there has been a lot of publicity, but as Kevin Collier recently explored, there does not appear to be any permanent impact of say: Bitpay sponsoring a college bowl game last year.4
The two charts above both come from Bitwage, a startup that converts payrolls into bitcoins. Ignoring the drop-off in January 2016 (it is the beginning of a new month), for most of 2015 there were roughly 200-300 new user signups each month and about $250,000 in salaries converted as well.
Again, this is not to say that Bitwage’s service is not useful, rather that if there was increased bitcoin growth and adoption, then one proxy could be through payroll conversion. However, as shown above, growth is linear not exponential.
Above is a 2-year, nearly linear line chart from Blockchain.info depicting the “My Wallet” Number of Users. It bears mentioning that many people still use Blockchain.info wallets like a “temporary” wallet (or burner wallet) for coin mixing, yet despite the rapid creation rate for this purpose even if we look just at the last 6 months, it is not close to being exponential.
But what about hash rate? It has continually gone up and to the right the last few months, surely this is an indicator of mass adoption?
All hash rate is measuring is the amount of work being generated by an unknown amount of computers (typically ASICs) somewhere on the planet. Hash rate typically rises when the price of bitcoins rise and falls when the price of bitcoins fall (see Appendix B). Since prices have nearly doubled over the past four months then it stands to reason that hash rate would correspondingly increase as hashing farms deploy new capital.5
Unless each site is inspected, it’s difficult to tell if there are more hashing farms and equipment and therefore “more users.” However, what we do know is that there are roughly the same amount of pools today (~20) as there were three years ago.6
Counterparty is an embedded consensus system (see section 1): an asset issuance platform that effectively staples itself onto the Bitcoin blockchain.
As shown above, on a given day roughly 500-1000 transactions take place through the platform. According to Laurent MT, the spikes may be related to the weekly distribution of LTBCoins. And again, despite turnkey services and vending machines such as Tokenly and CoinDaddy (and CounterpartyChain), overall growth on the ECS has effectively plateaued over the past year.
Bitcoin is a solution and service provider for those who hold bitcoins. Despite the fanfare, the conferences and the perpetual feel-good op-eds in Techcrunch, the only people who seem to use it regularly seven years later are a niche demographic group: young, white, tech-savvy men in North America and Western Europe. Many of whom have access to multiple other payment networks and asset classes for investment.
As a result, it is probably not a surprise that instead of using bitcoins to pay for coffee on-chain each day, most private key owners prefer to “hodl” or use intermediaries. This may make sense for those with low time preferences, but it shouldn’t then come as a surprise that there are few, if any metrics that show wide-scale adoption beyond this core demographic. Will this change in 2016 or will the “great pivot” continue?
Spam and dust (such as “tips”) likely represents the remaining 1.84% of all bitcoins (located on 99% of all addresses). [↩]
Funding has instead switched over to the fledgling non-cryptocurrency distributed ledger industry. [↩]
Anecdotally, it appears that Coins.ph, BitX and Align Commerce have each gained actual traction in their respective regions. [↩]
Stephen Pair provided a new chart for Forbes which purportedly shows a large uptick in transactions processed. This “surge” occurred during the same month as Bitcoin Black Friday and should be looked at again in the following months to see if it was a one-off event. [↩]
There are also stories of new chips supposedly being deployed. In practice hashing farms do the Red Queen race: replace a machine… with another machine that uses the same amount of energy. [↩]
The claim that 21inc or other mining chip manufacturers will “redecentralize mining” is a misnomer. Mining and hashing are not the same thing. Unless a hashing operator also runs a fully validating node, then they are part of the outsourcing process. More people may be hashing as part of the 21inc botnet, but not mining (mining is defined as selecting transactions to include in blocks; hashers do not do this activity, pools do). [↩]
One comment I have noticed continually re-appear on social media over the last couple months is roughly the following:
If you’re building a new blockchain you should regularly take a hash of the network state and “anchor” it (write it) into another blockchain, for redundancy purposes.
This “anchor” idea has appeared in public material from BitFury, Factom, Tierion, Gil Luria and now 21inc (a VC-backed botnet operator).
Part of the current popularity in the anchoring meme is that some cryptocurrency enthusiasts and Bitcoin maximalists in particular want other non-cryptocurrency distributed ledgers to rely on existing cryptocurrency networks — networks that some enthusiasts own tokens to and hope that price appreciation will take place in the event that the network is used.
Ignoring the hypothetical monetary incentives, let’s assume that writing/storing network states externally is useful and it is the goal of every blockchain designers such as Bob and Alice. Are other blockchains the only relevantly secure places that all blockchain designers should look at using?
For instance, if the goal is to publish a hash of a state in a media that is difficult to censor and widespread enough to retrieve over time, then there are several “old school” newspapers and magazines that can be used for such purposes (which is what Guardtime does).
In the UK, both The Sun and Daily Mirror have a circulation of over 1.5 million
Similarly, in the US, there are three companies: USA Today, The New York Times and The Wall Street Journal that also have a circulation of over 1.5 million
The question for the paranoid is, what is more likely: someone deliberately destroying and/or replacing 1.5 million newspapers which contain the hash of the network state, or someone knocking out 5,728 network nodes?
While “anchoring” the hash of state into other media may be useful, leaving it in just one blockchain — such as the Bitcoin blockchain — does not fully reduce the risk of a well-funded attacker trying to revise history. Safety in this case comes in numbers and if it is redundancy Bob and Alice are looking for (and paranoid about), it may be worth it to publish hashes in multiple venues and media.
Similarly, if sustainability is a key concern then public goods such as cryptocurrencies have a question mark on them as well. Why? Because there are over 100 dead altcoins now. Convincing users — and more importantly miners — to maintain a network when it is no longer profitable to do so is an uphill challenge.1
Lastly, a well designed network (or distributed ledger in this case) that is robust and mature should not necessarily rely on “anchoring” at all. But this dovetails into a different conversation about how to design a secure network, a topic for another post. Either way, hash-storage-as-service, is probably not the next big trillion dollar idea for 2016.
It’s a challenge for any public good, not just Bitcoin, that eventually relies solely on altruism and charity. [↩]
Slide 15: Field of Dreams image in reference to the model that you build it first with the hope that customers come
Slide 19: One example of this euphemism is from Adam Draper (and a similar reference point on Twitter). Each of these five companies has a couple product lines, one of which focuses on cryptocurrencies in a non-marginal manner.
Slide 21: This list could include a number of others including Tezos (DLS) and a handful of other startups including a couple in Japan
Slide 23: Collective head count for these companies is just under 100 and total funding raised (that is publicly announced) is around $10 million. There are still more companies trying to build foundational layers (some proprietary, others open) than teams building applications on top. Legend in parenthesis: E=Ethereum, R=Ripple, CP=Counterparty, OA=OpenAssets, TM=Tendermint
Slide 24: Most of the large non-bank financial institutions such as clearing houses and exchanges all have working groups focused on distributed ledger technology (e.g., CLS, SWIFT, LSEG, CME, Nasdaq, Deutsche Borse, DTCC). The Linux Foundation project is in its formative stage.
In a nutshell: despite recent efforts to modify public blockchains such as Bitcoin to secure off-chain registered assets via colored coins and metacoins, due how they are designed, public blockchains are unable to provide secure legal settlement finality of off-chain assets for regulated institutions trading in global financial markets.
The initial idea behind this topic started about 18 months ago with conversations from Robert Sams, Jonathan Levin and several others that culminated into an article.
The issue surrounding top-heaviness (as described in the original article) is of particular importance today as watermarked token platforms — if widely adopted — may create new systemic risks due to a distortion of block reorg / double-spending incentives. And because of how increasingly popular watermarked projects have recently become it seemed useful to revisit the topic in depth.
What is the takeaway for organizations looking to use watermarked tokens?
The security specifications and transaction validation process on networks such as the Bitcoin blockchain, via proof-of-work, were devised to protect unknown and untrusted participants that trade and interact in a specific environment.
Banks and other institutions trading financial products do so with known and trusted entities and operate within the existing settlement framework of global financial markets, with highly complex and rigorous regulations and obligations. This environment has different security assumptions, goals and tradeoffs that are in some cases opposite to the designs assumptions of public blockchains.
Due to their probabilistic nature, platforms built on top of public blockchains cannot provide definitive settlement finality of off-chain assets. By design they are not able to control products other than the endogenous cryptocurrencies they were designed to support. There may be other types of solutions, such as newer shared ledger technology that could provide legal settlement finality, but that is a topic for another paper.
This is a very important issue that has been seemingly glossed over despite millions of VC funding into companies attempting to (re)leverage public blockchains. Hopefully this paper will help spur additional research into the security of watermarking-related initiatives.
I would like to thank Christian Decker, at ETH Zurich, for providing helpful feedback — I believe he is the only academic to actually mention that there may be challenges related to colored coins in a peer-reviewed paper. I would like to thank Ernie Teo, at SKBI, for creating the game theory model related to the hold-up problem. I would like to thank Arthur Breitman and his wife Kathleen for providing clarity to this topic. Many thanks to Ayoub Naciri, Antony Lewis, Vitalik Buterin, Mike Hearn, Ian Grigg and Dave Hudson for also taking the time to discuss some of the top-heavy challenges that watermarking creates. Thanks to the attorneys that looked over portions of the paper including (but not limited to) Jacob Farber, Ryan Straus, Amor Sexton and Peter Jensen-Haxel; as well as additional legal advice from Juan Llanos and Jared Marx. Lastly, many thanks for the team at R3 including Jo Lang, Todd McDonald, Raja Ramachandran and Richard Brown for providing constructive feedback.
[Note: the following views were originally included in a new paper but needed to be removed for space and flow considerations]
While most academic literature has thus far narrowly focused under the assumption that proof-of-work miners such as those used in Bitcoin will behave according to a “goodwill” expectation, as explored in this paper, there may be incentives that creative attackers could look to exploit.
Is there another way of framing this issue as it relates to watermarked tokens such as colored coins and metacoins?
Below are comments from several thought-leaders working within the industry.
When it comes to cryptocurrency, as with any other situation, an attacker has to balance the cost of attacking the network with the benefit of doing so. If an attacker spends the minimum amount required to 51% attack bitcoin, say $500 million, then the attacker needs to either be able to short $500 million or more worth of BTC for the attack to be worth it, or needs to double spend $500 million or more worth of BTC and receive some irreversible benefit and not get caught (or not have consequences for getting caught), all while taking into consideration the loss of future revenues from mining honestly. When you bring meta-coins into the equation, things get even murkier; the cost is less dependent on the price of bitcoin or future mining revenues, and depends more on the asset being attacked, whether it’s a stock sale or company merger that’s being prevented, or USD tokens being double-spent.
There’s no easy answer, but based on the economics of the situation, and depending on the asset in question, it doesn’t seem wise to put more value on chain than the market cap of BTC itself (as a rough benchmark – probably not that exact number, but something close to it).
Not a single study has been publicly published looking at this disproportionalism yet it is regularly touted at conferences and social media as a realistic, secure, legal possibility.
According to Vitalik Buterin, creator of Ethereum:2
There are actually two important points here from an economics perspective. The first is that when you are securing $1 billion on value on a system with a cryptoeconomic security margin that is very small, that opens the door to a number of financial attacks:
Short the underlying asset on another exchange, then break the system
Short or long some asset at ultrahigh leverage, essentially making a coin-flip bet with a huge amount of money that it will go 0.1% in one direction before the other. If the bet pays off, great. If it does not pay off, double spend.
Join in and take up 60%+ of the hashrate without anyone noticing. Then, front-run everyone. Suppose that person A sends an order “I am willing to buy one unit of X for at most $31”, and person B sends an order “I am willing to sell one unit of X for at least $30”. As a front-runner, you would create an order “I am willing to sell one unit of X for at least $30.999” and “I am willing to buy one unit of X for at most $30.001”, get each order matched with the corresponding order, and earn $0.998 risk-free profit. There are also of course more exotic attacks.
In fact, I could see miners even without any attacks taking place front-running as many markets as they can; the ability to do this may well change the equilibrium market price of mining to the point where the system will, quite ironically, be “secure” without needing to pay high transaction fees or have an expensive underlying currency.
The second is that assets on a chain are in “competition” with each other: network security is a public good, and if that public good is paid for by inflation of one currency (which in my opinion, in a single-currency-chain environment, is economically optimal) then the other currencies will gain market share; if the protocol tries to tax all currencies, then someone will create a funky meta-protocol that “evades taxes by definition”: think colored coins where all demurrage is ignored by definition of the colored coin protocol. Hence, we’ll see chains secured by the combination of transaction fee revenue and miner front running.
Unsolved economics question: would it be a good thing or a bad thing if markets could secure themselves against miner frontruns? May be good because it makes exchanges more efficient, or bad because it removes a source of revenue and reduces chain security.
Cryptoeconomics is a nascent academic field studying the confluence of economics, cryptography, game theory and finance.3
Piotr Piasecki, a software developer and independent analyst explained:4
If a malicious miner sees a big buy order coming into the market that would move the price significantly, they can engage in front running – the buy order could be pushed to the back of the queue or even left out until the next block, while the miner buys up all of the current stock and re-lists it at a higher price to turn a profit. Alternatively, when they see there is a high market pressure coming in, especially in systems that are inefficient by design, they can buy the orders up one by one by using their power to include any number of their own transactions into a block for free, and similarly re-list them for people to buy up.
Or in other words, because miners have the ability to order transactions in a block this creates an opportunity to front run. If publicly traded equities are tracked as a type of colored coin on a public blockchain, miners could order transaction in such a way as to put certain on-chain transactions, or trades in this case, to execute before others.
Robert Sams, co-founder of Clearmatics, previously looked at the bearer versus registered asset challenge:5
One of the arguments against the double-spend and 51% attacks is that it needs to incorporate the effect a successful attack would have on the exchange rate. As coloured coins represent claims to assets whose value will often have no connection to the exchange rate, it potentially strengthens the attack vector of focusing a double spend on some large-value colour. But then, I’ve always thought the whole double-spend thing could be reduced significantly if both legs of the exchange were represented on a single tx (buyer’s bitcoin and seller’s coloured coin).
The other issue concerns what colour really represents. The idea is that colour acts like a bearer asset, whoever possesses it owns it, just like bitcoin. But this raises the whole blacklisted coin question that you refer to in the paper. Is the issuer of colour (say, a company floating its equity on the blockchain) going to pay dividends to the holder of a coloured coin widely believed to have been acquired through a double-spend? With services like Coin Validation, you ruin fungibility of coins that way, so all coins need to be treated the same (easy to accomplish if, say, the zerocoin protocol were incorporated). But colour? The expectations are different here, I believe.
On a practical level, I just don’t see how pseudo-anonymous colour would ever represent anything more than fringe assets. A registry of real identities mapping to the public keys would need to be kept by someone. This is certainly the case if you ever wanted these assets to be recognised by current law.
But in a purely binary world where this is not the case, I would expect that colour issuers would “de-colour” coins it believed were acquired through double-spend, or maybe a single bitcoin-vs-colour tx would make that whole attack vector irrelevant anyway. In which case, we’re back to the question of what happens when the colour value of the blockchain greatly exceeds that of the bitcoin monetary base? Who knows, really depends on the details of the colour infrastructure. Could someone sell short the crypto equity market and launch a 51% attack? I guess, but then the attacker is left with a bunch of bitcoin whose value is…
The more interesting question for me is this: what happens to colour “ownership” when the network comes under 51% control? Without a registry mapping real identities to public keys, a pseudo-anonymous network of coloured assets on a network controlled by one guy is just junk, no longer represents anything (unless the 51% hasher is benevolent of course). Nobody can make a claim on the colour issuer’s assets. So perhaps this is the real attack vector: a bunch of issuers get together (say, they’re issuers of coloured coin bonds) to launch a 51% attack to extinguish their debts. If the value of that colour is much greater than cost of hashing 51% of the network, that attack vector seems to work.
On this point, Jonathan Levin, co-founder of Chainalysis previously explained that:6
We don’t know how much proof of work is enough for the existing system and building financially valuable layers on top does not contribute any economic incentives to secure the network further. These incentives are fixed in terms of Bitcoin – which may lead to an interesting result where people who are dependent on coloured coin implementations hoard bitcoins to attempt to and increase the price of Bitcoin and thus provide incentives to miners.
It should also be noted that the engineers and those promoting extensibility such as colored coins do not see the technology as being limited in this way. If all colored coins can represent is ‘fringe assets’ then the level of interest in them would be minimal.
Time will tell whether this is the case. Yet if Bob could decolor assets, in this scenario, an issuer of a colored coin has (inadvertently) granted itself the ability to delegitimize the bearer assets as easily as it created them. And arguably, decoloring does not offer Bob any added insurance that the coin has been fully redeemed, it is just an extra transaction at the end of the round trip to the issuer.
Personal correspondence, August 10, 2015. Bitseed is a startup that builds plug-and-play full nodes for the Bitcoin network. [↩]
The underlying motivations for writing them was that Bitfury is trying to assure the world that public blockchains can still be used in “proprietary contexts.” While they provide a good frame for the issue, there are several leaps in logic, or direct contradictions to established theory that necessarily weaken their argument.
Below is my discussion of them. Note: as usual, this only represents my opinion and does not necessarily represent the views of the organizations that I advise or work for.
Overall I thought the two papers did not seem to have been reviewed by a wider audience including lawyers: specifically they should have sent them to commercial and securities lawyers to see if any legal issues should be considered. Much of their pitch basically amounts to mining for the sake of mining.
One final note: for additional commentary I also reached out to Dave Hudson who is proprietor of HashingIt and an expert as it relates to Bitcoin mining analysis. He is unaffiliated with Bitfury.
Notes for Part 1:
On p. 2, Bitfury wrote the following statement:
The key design element of blockchains – embedded security – makes them different from ordinary horizontally scalable distributed databases such as MySQL Cluster, MongoDB and Apache HBase. Blockchain security makes it practically impossible to modify or delete entries from the database; furthermore, this kind of security is enforced not through the central authority (as it is possible with the aforementioned distributed databases), but rather through the blockchain protocol itself.
Is this a problematic summary?
According to Dave Hudson:
As a network protocol engineer of many years I tend to find the concept of a “blockchain protocol” somewhat odd. Here’s a link to definitions of “protocol.”
What do we mean by protocol here? It’s not actually a network protocol because there is no “blockchain protocol”, there are many different ones (each altcoin has its own and there are many more besides). At best the idea of a “blockchain protocol” is more a meta-protocol, in that we say there are some things that must be done in order for our data to have blockchain-like characteristics. It’s those characteristics that provide for non-repudiation.
Also on p. 2, Bitfury uses the term “blockchain-based ledger.” I like that because, as several developers have pointed out in the past, the two concepts are not the same — distributed ledgers are not necessarily blockchains and vice versa.
On p. 4 and 5 they list several objections for why financial institutions are hesitant to use a public blockchain yet leave a couple noticeable ones off including the lack of a service level agreement / terms of service between end users and miners. That is to say, in the event of a block reorg or 51% attack, who calls who?
On p. 7, I don’t think that censorship resistance can be generalized as a characteristic for “all blockchains.”
In Dave Hudson’s view:
Moreover, censorship resistance makes absolutely no sense in many instances. Who would be censoring what?
I’m actually not convinced that censorship resistance is actually a “thing” in Bitcoin either. Plenty of well-formed transactions can be censored by virtue of them being dust or having non-standard scripts. If anything the only thing that Bitcoin does is provide a set of conditions in which a transaction is probabilistically going to be mined into blocks in the network.
If a blockchain database is completely opaque for clients (i.e., they have no access to blockchain data), the security aspect of blockchain technology is diminished. While such system is still protected from attacks on the database itself, interaction with clients becomes vulnerable, e.g. to man-in-the middle attacks. As a built-in protocol for transaction authorization is one of core aspects of blockchain technology, its potential subversion in favor of centralized solutions could negatively influence the security aspect of the system. Additionally, as transactions are accessible to a limited set of computers, there exists a risk of human factor intervening into the operation of the blockchain with no way for clients to detect such interference. Thus, the opaque blockchain design essentially undermines the core aspects of blockchain technology:
• decentralization (absence of a single point of failure in the system)
• trustlessness (reliance on algorithmically enforced rules to process transactions with no human interaction required).
I think trustlessness is a red herring that cypherpunks and Bitcoiners have been perpetually distracted by. It may be an end-goal that many would like to strive for but trust-minimization is a more realistic intermediate characteristic for those operating within the physical, real world.
Why? Because existing institutions and legal infrastructure are not going to disappear tomorrow just because a vocal group of cryptocurrency enthusiasts dislikes them.
According to Dave Hudson:
As with so many things-Bitcoin, I think this is an implementation necessity being seen as a innately desirable characteristic. Bitcoin requires “trustlessness” because it’s non-permissioned, yet in truth it totally relies on trust to work. We trust that Sybil attacks aren’t happening and that network service providers are not colluding to support such attacks. We trust that a large body of miners are not colluding to distort the system. We trust that changes to the software (or updates to compilers and operating systems) have not rendered old, non-recently-used keys are still able to support signing of transactions. We trust that Satoshi (and other large holders) will not drop 1M, or worse 10M coins onto exchanges crashing the price to a few cents per coin! There’s no “too big to fail” here!
In truth real-world people actually like to trust things. They want to trust that their national governments will ensure services work and that invaders are kept out. They want to trust that law enforcement, fire and medical services will keep them safe. I’m not sure that I like the idea of a trustless Police force?
What people do like is the ability to verify that the entities that they actually do trust are in fact doing what they should. Blockchain designs allow us to do just this.
That last statement in particular succinctly summarizes some of the motivations for financial institutions looking to use a shared ledger that is not the Bitcoin blockchain.
On p. 12, I disagree with this statement:
While the permissioned nature of blockchains for proprietary applications may be a necessary compromise in the medium term because of compliance and other factors, read access to blockchain data together with the publicly available blockchain protocol would remove most of vulnerabilities associated with opaque blockchain designs and would be more appealing to the clients of the institution(s) operating the blockchain. As evidenced by Bitcoin, simplified payment verification softwarecan be used to provide a direct interface to blockchain data that would be both secure and not resource intensive.
The reason I disagree with this statement is because the term “opaque” is loaded and ill-defined.
For instance, several groups within the Bitcoin ecosystem have spent the last several years trying to delink or obfuscate transaction history via zk-SNARKs, stealth addresses, mixing via Coinjoin and Coinshuffle and other methods. This type of activity is not addressed by Bitfury — will they process Bitcoin transactions that are obfuscated?
Granular permissions — who is allowed to see, read or write to a ledger — is a characteristic some of these same Bitcoin groups are not fans of but is a needed feature for financial institutions. Why? Because financial institutions cannot leak or expose personal identifiable information (PII) or trading patterns to the public.
Securely creating granular permissions is doable and would not necessarily reduce safety or transparency for compliance and regulatory bodies. Operating a non-public ledger is not the same thing as being “opaque.” While hobbyists on social media may not be able to look at nodes run by financial institutions, regulators and compliance teams can still have access to the data.
It also bears mentioning that another potential reason some public blockchains have and/or use a token is as an anti-spam mechanism (e.g., in Ripple and Stellar a minute amount is burnt).1
On p. 13, I disagree with this statement:
The problem is somewhat mitigated if the access to block headers of the chain is public and unrestricted; however, convincing tech-savvy clients and regulators that the network would be impervious to attacks could still be a difficult task, as colluding operators have the ability to effortlessly reorganize the arbitrary parts of the blockchain at any given moment. Thus, the above consensus protocol is secure only if there is no chance of collusion among blockchain operators (e.g., operators represent ideal parties with conflicting interests). Proof of work provides a means to ensure absence of collusion algorithmically, aligning with the overall spirit of blockchain technology.
This is untrue. People run pools, people run farms. Earlier this year Steve Waldman gave a whole presentation aptly named “Soylent Blockchains” because people are involved in them.
As we have seen empirically, pool and farm operators may have conflicting incentives and this could potentially lead to collusion. Bitcoin’s “algorithms” cannot prevent exogenous interactions.
On p. 14 I disagree with this statement:
There is still a fixed number of miners with known identities proved by digital signatures in block headers. Note that miners and transaction processors are not necessarily the same entities; in the case that mining is outsourced to trusted companies, block headers should include digital signatures both from a miner and one or more processing institutions.
Having a “trusted company” run a proof-of-work mining farm is self-defeating with respect to maintaining pseudonymity on an untrusted network (which were the assumptions of Bitcoin circa 2009). If all miners are “trusted” then you are now operating a very expensive trusted network. This also directly conflicts with the D in DMMS (dynamic-membership multi-party signature).
According to Dave Hudson:
If the signing is actually the important thing then we may as well say there’s a KYC requirement to play in the network and we can scale it all the way back to one modest x86 server at each (with the 1M x reduction in power consumption). Of course this would kill mining as a business.
On p. 14 I think the Bitfury proposal is also self-defeating:
The proposed protocol solves the problem with the potentially unlimited number of alternative chains. Maintaining multiple versions of a blockchain with proof of work costs resources: electricity and hashing equipment. The hashing power spent to create a blockchain and the hashing power of every miner can be reliably estimated based on difficulty target and period between created blocks; an auditor could compare these numbers with the amount of hashing equipment available to operators and make corresponding conclusions.
The authors go into detail later on but basically they explain what we can already do today: an outside observer can look at the block headers to see the difficulty and guess how much hashrate and therefore capital is being expended on the hash.
On p. 15 they present their proposal:
Consequently, $10 million yearly expenses on proof of work security (which is quite low compared to potential gains from utilizing blockchain technology, estimated at several billion dollars per year ) correspond to the hash rate of approximately 38 PHash / s, or a little less than 10% of the total hash rate of the Bitcoin network.
This is entirely unneeded. Banks do not need to spend $10 million to operate hardware or outsource operation of that hardware to some of its $100 million Georgia-based hydro-powered facilities.
According to Dave Hudson:
Precisely; banks can use a permissioned system that doesn’t need PoW. I think this also misses something else that’s really important: PoW is necessary in the single Bitcoin blockchain because the immutability characteristics are derived from the system itself, but if we change those starting assumptions then there are other approaches that can be taken.
In section 3.1 the authors spend some time discussing merged mining and colored coins but do not discuss the security challenges of operating in a public environment. In fact, they assume that issuing colored coins on a public blockchain is not only secure (it is not) but that it is legal (probably not either).2
On p. 16 they mention “transaction processors” which is a euphemism that Bitfury has been using for over a year now. They dislike being called a mining company preferring the phrase “transaction processors” yet their closed pool does not process any kind of transactions beyond the Bitcoin variety.
On page 17 they wrote:
[M]aintenance of the metachain could be outsourced to a trusted security provider without compromising confidential transaction details.
If taken to the logical extreme and all of the maintenance was “outsourced” to trusted security providers they would have created a very expensive trusted network. Yet in their scenario, financial institutions would have to trust a Republic of Georgia-based company that is not fully transparent.
Also on page 17 they start talking about “blockchain anchors.” This is not a new or novel idea. As other developers have spoken about the past and Guardtime puts anchors into newspapers like The New York Times (e.g., publishes the actual hashes in a newspaper). And, again, this could easily be done in other ways too. Why restrict anchoring to one location? This is Bitcoin maximalism at work again.
On p. 20 they wrote:
Bitcoin in particular could be appropriate for use in blockchain innovations as a supporting blockchain in merged mining or anchoring due to the following factors: • relatively small number of mining pools with established identities, which allows them to act as known transaction validators by cooperating with institutions
This is self-defeating for pseudonymous interactions (e.g., Bitcoin circa 2008). Proof-of-work was integrated to fight Sybil attacks. If there are only a few mining pools with established identities then there are no Sybil’s and you effectively have an extremely expensive trusted network.
Notes on Part 2:
On p. 3 they wrote:
If an institution wants to ensure that related Bitcoin transactions are mined by accredited miners, it may send transactions over a secure channel directly to these miners rather than broadcasting them over the network; accepting non-broadcast transactions into blocks is a valid behavior according to the Bitcoin protocol.
An “accredited miner” is a contradiction.
On p. 4 the first paragraph under section 1.3 was well written and seems accurate. But then it falls apart as they did not consult lawyers and financial service experts to find out how the current plumbing in the back-office works — and more importantly, why it works that way.
On p.4 they wrote:
First, the transfer of digital assets is not stored by the means of the Bitcoin protocol; the protocol is unaware of digital assets and can only recognize and verify the move of value measured in bitcoins. Systems integrating digital assets with the Bitcoin blockchain utilize various colored coin protocols to encode asset issuance and transfer (see Section 2.2 for more details). There is nothing preventing such a protocol to be more adapted to registered assets.
Second, multisignature schemes allow for the creation of limited trust in the Bitcoin environment, which can be beneficial when dealing with registered assets and in other related use cases. Whereas raw bitcoins are similar to cash, multisignature schemes act not unlike debit cards or debit bank accounts; the user still has a complete control of funds, and a multisignature service provides reputation and risk assessment services for transactions.
This is the same half-baked non-sense that Robert Sams rightly criticized in May. This is a centralized setup. Users are not gaining any advantage for using the Bitcoin network in this manner as one entity still controls access via identity/key.
On p. 5 they wrote:
One of the use cases of the 2-of-3 multisignature scheme is escrow involving a mediator trusted by both parties. A buyer purchasing certain goods locks his cryptocurrency funds with a multisignature lock, which requests two of the three signatures: the buyer’s, the seller’s, and the mediator’s.
This is only useful if it is an on-chain, native asset. Registered assets represent something off-chain, therefore Bitcoin as it exists today cannot control them.
On p. 6 they talk about transactions being final for an entire page without discussing why this is important from a legal perspective (e.g., why courts and institutions need to have finality). This paper ignores how settlement finality takes place in Europe or North America nor are regulatory systems just going to disappear in the coming months.
On page 7 they mention that:
To prevent this, a protocol could be modified to reject reorganizations lasting more than a specified number of blocks (as it is done in Nxt). However, this would make the Bitcoin protocol weakly subjective , introducing a social-driven security component into the Bitcoin ecosystem.
There is already a very publicly known, social-driven security component: the Bitcoin dev mailing list. We see this almost daily with the block-size debate. The statement above seems to ignore what actually happens in practice versus theory.
On p. 7 and 8 they write:
The security of the Bitcoin network in the case of economic equilibrium is determined by the rewards received by block miners and is therefore tied to the exchange rate of Bitcoin. Thus, creating high transaction throughput of expensive digital assets on the Bitcoin blockchain with the help of colored coin protocols has certain risks: it increases the potential gain from an attack on the network, while security of the network could remain roughly the same (as there are no specific fees for digital asset transactions; transaction fees for these transactions are still paid in bitcoins). The risk can be mitigated if Bitcoin fees for asset transactions would be consciously set high, either by senders or by a colored coins protocol itself, allowing Bitcoin miners to improve security of the network according to the value transferred both in bitcoins and in digital assets.
There is no way to enforce this increase in fee. How are “Bitcoin fees for asset transactions … consciously set high”? This is a question they never answer, (Rosenfeld 2012) did not answers it, no one does. It is just assumed that people will start paying higher fees to protect off-chain securities via Bitcoin miners.
There is no incentive to pay more and this leads to a hold-up problem described in the colored coin “game” from Ernie Teo.
On p. 8 they wrote:
As there is a relatively small number of Bitcoin mining pools, miners can act as known processors of Bitcoin transactions originating from institutions (e.g., due to compliance reasons). The cooperation with institutions could take the form of encrypted channels for Bitcoin transactions established between institutions and miners.
This is silly. If they are known and trusted, you have a trusted network that lacks a Sybil attacker. There is no need for proof-of-work mining equipment in such a scenario.
On p. 8 they wrote:
In the ideal case though, these transactions would be prioritized solely based on their transaction fees (i.e., in a same way all Bitcoin transactions are prioritized), which at the same time would constitute payments for the validation by a known entity. Thus, this form of transaction processing would align with the core assumption for Bitcoin miningthat miners are rational economic actors and try to maximize their profit.
It cannot be assumed that miners will all behave as “rational economic actors.” They will behave according to their own specific incentives and goals.
On p. 9 they wrote:
Additionally, partnerships between institutions and miners minimize risk in case transactions should not be made public before they are confirmed.
Registered and identifiable miners is the direct anti-thesis of pseudonymous interactions circa Bitcoin 2008. That type of partnership is a win-lose interaction.
On p. 10 they wrote:
One of the interesting financial applications of colored coins is Tether (tether.to), a service using colored coins to represent US dollars for fast money transfer. Several cryptocurrencies such as Nxt and BitShares support custom digital assets natively.
As it exists today, Tether.to is similar in nature to a Ripple gateway such as SnapSwap: both are centralized entities that are subject to multiple regulatory and compliance requirements (note: SnapSwap recently exited its USD gateway business and locked out US-based users from its BTC2Ripple business).
According to FinCEN’s MSB Registrant Search Web page, Tether has a registration number (31000058542968) and one MSB. While they have an AML/CTF program in place, it is unclear in its papers how Bitfury believes the Bitcoin network (which Tether utilizes) can enforce exogenous claims (e.g., claims on USD, euros, etc.).
Furthermore, there has been some recent research looking at how the Federal Reserve and the Bank of England could use distributed ledgers to issue digital currency.3
If a central bank does utilize some kind of distributed ledger for a digital currency they do not need proof-of-work mining or the Bitcoin network to securely operate and issue digital currency.
Ignoring this possible evolution, colored coins are still not a secure method for exogenous value transfers.
On page 10 they wrote:
Colored coins are more transparent for participants and auditors compared to permissioned blockchains
This is untrue and unproven. As Christopher Hitchens would say, what can be asserted without evidence can be dismissed without evidence.
On page 10 they wrote:
As colored coins operate on top of permissionless blockchains, systems using colored coins are inherently resistant to censorship – restrictions on transactions are fully specified by a colored coins protocol instead of being enforced by a certain entity
This is also untrue. This is a bit like trying to have their cake and eat it too.
On page 11 they have a diagram which states:
Figure 2: Using colored coins on top of the Bitcoin blockchain to implement asset transactions. For compliance, financial institutions may use secure communication channels with miners described in Section 2.1 to place asset transactions on the blockchain
Again this is self-defeating. As the saying goes: be careful what you wish for. If Bitfury’s proposal came true, their pool(s) could become payment service providers (PSP) and regulated by FinCEN.
On page 12 and 13 they wrote:
Bitcoin and other public permissionless blockchains could be a part of the interconnected financial environment similarly to how cash is a ubiquitous part of the banking system. More concretely, cryptocurrencies could be used as: • one of the means to buy and sell assets on permissioned blockchains • an instrument that enables relatively fast value transfer among permissioned blockchains • an agreed upon medium for clearing operations among blockchains maintained by various institutions (Fig. 4).
Bitcoins as a permanent store-of-value are effectively a non-starter as they lack any endogenous self-stabilizing mechanism.4
According to Dave Hudson:
The systemic risks here just make this idea farcical. The Internet is somewhat immune to this because there are technology providers all over the world who can independently choose to ignore things in regulatory domains that want to do “bad things”. There is no such safety net in a system that relies on International distributed consensus (the Internet has no such problem, although DNS is a little too centralized right now). Even if it could somehow be guaranteed that things can’t be changed, fixed coin supply means artificial scarcity problems are huge (think Goldfinger trying to irradiate the gold in Fort Knox) – you wouldn’t need a nuclear weapon, just a good piece of malware that could burn coins (if they’re not stolen then there’s no way to trace who stole them). There’s also the 1M coins dropped onto exchanges problem.
The discussion over elastic and inelastic money supplies is a topic for another post.
On page 15 they wrote:
If a blockchain is completely opaque for its end users (e.g., a blockchain-based banking system that still uses legacy communication interfaces such as credit cards), the trustless aspect of blockchains is substantially reduced. End users cannot even be sure that a blockchain system is indeed in use, much less to independently verify the correctness of blockchain data (as there is no access to data and no protocol rules to check against). Human factor remains a vulnerability in private blockchain designs as long as the state of the blockchain is not solely based on its protocol, which is enforced automatically with as little human intervention as possible. Interaction based on legacy user authentication interfaces would be a major source of vulnerabilities in the case of the opaque blockchain design; new interfaces based on public key cryptography could reduce the associated risk of attacks.
While mostly true, there are existing solutions to provide secure verification. It is not as if electronic commerce did not or could not occur before Bitcoin came into existence. Some private entities take operational security seriously too. For instance, Visa’s main processing facility has 42 firewalls and a moat.
On page 15 they wrote:
Proprietary nature of private blockchains makes them less accessible; open sourced and standardized blockchain implementations would form a more attractive environment for developers and innovations. In this sense, blockchains with a public protocol are similar to open Internet standards such as IP, TCP and HTTP, while proprietary blockchain designs could be similar to proprietary Internet protocols that did not gain much traction. A proprietary blockchain protocol could contain security vulnerabilities that remain undiscovered and exploited for a long time, while a standardized open blockchain protocol could be independently studied and audited. This is especially true for protocols of permissionless blockchains, as users have a direct economic incentive to discover vulnerabilities in the system in order to exploit them.
This is just scaremongering. While some of the “blockchain” startups out there do in fact plan to keep the lower layers proprietary, the general view in October 2015 is that whatever bottom layer(s) are created, will probably be open-sourced and an open-standard. Bitcoin doesn’t have a monopoly on being “open” in its developmental process.
On page 15 they wrote:
As the Bitcoin protocol has been extensively studied by cryptographers and scientists in the field, it could arguably form the basis for the standardized blockchain design.
This is untrue, it cannot be the backbone of a protocol as it is not neutral. In order to use the Bitcoin network, users are required to obtain what are effectively illiquid pre-paid gift cards (e.g., bitcoins). Furthermore, an attacker cannot collect “51%” of all TCP/IP packets and take over the “internet” whereas with Bitcoin there is a real “majoritarianism” problem due to how network security works.
A truly neutral protocol is needed and there have been at least two proposals.5
On page 15 they wrote:
The key design element of blockchains is “embedded economy” – a superset of embedded security and transaction validation. Each blockchain forms its own economic ecosystem; a centrally controlled blockchain is therefore a centrally controlled economy, with all that entails.
This is untrue. If we are going to use real-world analogies: Bitcoin’s network is not dynamic but rather disperses static rewards to its labor force (miners). It is, internally, a rigid economy and if it were to be accurately labeled, it is a command economy that relies on altruism and VC subsidies to stay afloat.6
On page 16 they wrote:
It is not clear how the blockchain would function in the case validators would become disinterested in its maintenance, or how it would recover in the case of a successful attack (cf. with permissionless blockchains, which offer the opportunity of self-organization).
The statement above is unusual in that it ignores how payment service providers (PSPs) currently operate. Online commerce for the most part has and likely will continue to exist despite the needed maintenance and profit-motive of individual PSPs. There are multiple motivations for continued maintenance of maintenance transfer agreements — this is not a new challenge.
While it is true that there will likely be dead networks in the futures (just like dead ISPs in the past), Bitcoin also suffers from a sustainability problem: it continually relies on altruism to be fixed and maintained and carries with it an enormous collective action burden which we see with the block-size debate.
There are over a hundred dead proof-of-work blockchains already, a number that will likely increase because they are all public goods that rely on external subsidies to exist. See Ray Dillinger’s “necronomicon” for a list of dead alt coins.
If Bitfury’s proposal for having a set of “fixed” miners arises, then it is questionable about how much self-organization could take place in a static environment surrounding a public good.
Despite the broad scope of the two papers from Bitfury neither was able to redress some of the most important defects that public blockchains have for securing off-chain assets:
how is legal settlement finality resolved
how to incentivize the security of layers (such as colored coins) which distort the mining process
how to enforce the security of merged mining which empirically becomes weaker over time
If Bitfury is truly attempting to move beyond merely processing Bitcoin transactions in its Georgian facilities, it needs to address what constraints and concerns financial institutions actually face and not just what the hobbyist community on social media thinks.
About six weeks ago I mentioned a dollar figure during a panel at the Consensus event in NYC: $6 million. Six million USD is a loose estimate — for illustrative purposes — of the amount of engineering time representing thousands of man hours over the past 7-9 months that has gone into a productivity black hole surrounding the Bitcoin block size debate.
A little recent history
While there had been some low intensity discussions surrounding block size(s) over the past several years, most of that simmered in the background until the beginning of 2015.
On January 20th Gavin Andresen posted a 20 MB proposal which was followed over the subsequent weeks by a number of one-and-done counterpoints by various developers.
About four months later, beginning on May 4, Gavin posted a series of blog articles that kicked things up a notch and spurred enormous amounts of activity on social media, IRC, web forums, listservs, podcasts and conferences.
The crescendo of public opinion built up over the summer and reached a new peak on August 15th with a post from Mike Hearn, that Bitcoin would fork into two by the beginning of next year.
The passionate enthusiasts on all sides of the spectrum took to social media once again to voice their concerns. During the final two weeks of August, the debate became particularly boisterous as several moderators on reddit began to bandiscussions surrounding Bitcoin XT (among other forks and proposals). There was even an academic paper published that looked at the sock puppets involved in this period: Author Attribution in the Bitcoin Blocksize Debate on Reddit by Andre Haynes.
Ignoring the future evolution of block size(s), with respect to the opportunity costs of the debate itself: investors and consumers have unintentionally funded what has turned out to be a battle between at least two special interest groups. 1
So where does the $6 million figure come from?
Of the roughly $900 million of VC funding related to Bitcoin itself that has been announced over the past 3 years, about half has been fully spent and went towards legal fees, domain names, office rent, conference sponsorship’s, buying cryptocurrencies for internal inventory and about a dozen other areas.2
At the current burn rate, Bitcoin companies collectively spend about $8-$10 million a month, perhaps more. And since the debate is not isolated to development teams, because upper management at these companies are involved in letter writing campaigns (and likely part of the sock puppet campaigns), then it could be the case that 5-10% of on-the-clock time at certain companies was spent on this issue.
Consequently, this translates into about $400,000 to $1 million each month which has been redirected and spent funding tweets, reddit posts, blog posts, conferences, research papers and industryconferences.3
What about specific numbers?
For instance, with around 150-200 attendees the Montreal scalability conference likely absorbed $250,000 from everyone involved (via travel, lodging, food, etc.). Similarly, one independent estimate that Greg Maxwell mentioned at the same Consensus event was his back-of-the-envelope projection of the opportunity costs: a few hundred thousand USD in the first couple weeks of May alone as engineers were distracted with block sizes instead of shipping code.
While a more precise number (+/-) could probably be arrived at if someone were to link individual developer activity on the dev mailing list/reddit/twitter with their estimated salaries on Glassdoor — since this past spring roughly $6 million or so has probably gone towards what has amounted to basically two diametrically opposed political campaigns.
And the issue is still far from resolved as there are more planned scalability conferences, including one in Hong Kong in early December.
Why is it a black hole though? Surely there is utility from the papers and projects like Lightning, right?
It’s a money pit because it doesn’t and cannot resolve the coordination problem that decentralized governance creates. I have an upcoming paper that briefly touches on this issue (in Appendix A): the key point is that any time decision making is decentralized then specific trade-offs occur.
In this case, due to an intentional power vacuum in which there is no “leader,” special interest groups lobby one another for the de facto right to make decisions. Some decisions, like raising the minimum transaction relay fees involve less tweets and downvotes and are for various reasons considered less important as others. Yet ultimately, de jure decision making remains out of reach.
Not the first time to a rodeo
Because decentralized governance (and external social consensus) was/is a key feature for many cryptocurrencies, this type of political activity could happen again with say, increasing the money supply from 21 million or if KYC becomes mandatory for all on-chain interactions.
Again, this was bound to happen because of the tragedy of the commons: because the Bitcoin network is a public good that lacks an explicit governance structure. Anytime you have a lack of formal governance you often end up with an informal power structure that makes it difficult to filter marketing fluff from sock puppets like Cypherdoc (aka Marc Lowe) from actual fact-filled research.
And this subsequently impacts any project that relies on the Bitcoin network as its security mechanism. Why? According to anecdotes, projects from new organizations and enterprises have reconsidered using public blockchains due to the aforementioned inherent governance hurdles alone.
After all, who do they call when the next Mexican standoff, block reorg or mutually assured destruction situation arises? There is no TOS, EULA or service-level agreement and as a result they look at other options and platforms.4
It is probably too simplistic to say that, with $6 million in funding, these same developers could have simply created a new system, like Ethereum, from scratch that factors in scalability challenges from day one. It is unlikely that these same developers would have come to agreement on what to spend those funds on as well. [↩]
About a year ago I briefly explored the PR and branding challenges of Bitcoin, a topic that has been independently discussed by others.
Over the past 6 months there has been a visible trend in the overall “Bitcoin” space to rebrand or not use the term “Bitcoin” on corporate material. This has been done for a variety of reasons.
Some startups simply are no longer touching or interfacing with bitcoins or the Bitcoin network. Others do not want to be affiliated with the term preferring the alternative “Blockchain” as a catch-all euphemism.
For instance, below are 10 companies which raised their Series A (and sometimes more) and were originally affiliated with “Bitcoin” in some manner but are no longer publicly positioning themselves as such:
Abra ($14 million): originally launched as a “rebittance” company, still claims to use the Bitcoin network but the word Bitcoin does not appear on its homepage
BitGold ($5.3 million): pivoted from Bitcoin last December
Bitreserve ($14.6 million): rebranded as Uphold and now vocally moving away from Bitcoin
ChangeTip ($4.25 million): removed the word Bitcoin from its frontpage, now focused on USD-denominated tips
Chain ($43.7 million): after closing its recent B round, remarketed from Bitcoin-only and removed the word Bitcoin from its frontpage except in the headlines of past news articles
Circle ($76 million): rebranded after receiving a Bitlicense; neither its frontpage nor its new 60 second ad use the word Bitcoin
Cryex ($10 million): the word Bitcoin does not appear on its frontpage
Mirror, formerly Vaurum ($12.8 million): the word Bitcoin does not appear on its frontpage (but does on some older blog posts)
Peernova ($19 million): originally a Bitcoin mining company that is no longer affiliated with Bitcoin at all
Vogogo ($21 million): the word Bitcoin does not appear on its frontpage
A few others who have done marketing changes (some more substantive than others):
BTC China ($5 million): still focused on its virtual currency exchange renamed itself as BTCC to move further abroad into the international marketplace
itBit ($28.25 million): in addition to running its virtual currency exchange, they also launched the Bankchain initiative this past summer
DAH: originally planned on using the Bitcoin blockchain but broadened its scope during the summer after acquiring Hyperledger; the word Bitcoin does not appear on its homepage although it still uses the network for product launches (like Pivit)
Symbiont: originally used the Counterparty platform and the Bitcoin network as part of its financial service, but has now built a permission-based system
Align Commerce, Serica and many others do not use the word Bitcoin on their homepages yet still use the Bitcoin network for some lines of business
Coindesk renamed their quarterly report: “State of Bitcoin and Blockchain”
Inside Bitcoins (the conference circuit) added “with Blockchain Agenda” prominently at the top of their homepage
As visualized in the chart above, Bitcoin-related investments have declined the past two quarters.
However, the chart is not fully accurate as CBI includes 21inc funding as “one” round in Q1 2015. According to Nathaniel Popper, 21inc did not raise its war chest in one round but rather over the course of 3 rounds. So it is likely that Q1 2015 probably was altogether around $175 million as the other ~$60 million were raised in 2013 and 2014. Similarly Q3 2015 should be less as Chain.com is no longer a Bitcoin-specific company.
What about other changes in the VC world?
Crypto Currency Partners: renamed itself Blockchain Capital
Boost VC: while the word Bitcoin does appear on its homepage, in his most recent writeup of its portfolio, Adam Draper does not use the word Bitcoin but instead uses “block chain” to describe his investments
Pantera: while it remains publicly committed to Bitcoin, based on its most recent newsletter the team likely views the word “blockchain” as more palatable to investors and LPs.
For instance, the year-over-year comparison of word frequency between two Pantera Capital newsletters:
DCG: launched its website during the summer, prominently display the word “blockchain technology” instead of Bitcoin, despite the fact that nearly all of its portfolio is Bitcoin-reliant or Bitcoin-specific.
In fact it appears that the trend by some VC-backed Bitcoin-heavy portfolio’s adopting the term “blockchain” is a marketing gimmick as neither DCG, Pantera nor Boost have purposefully invested in non-Bitcoin blockchain companies. In fact, individuals such as Barry Silbert (founder of DCG) are outspoken in their dismissal of non-Bitcoin blockchains.
What are some reasons for the decline shown in the CBI numbers?
Part of it has to do with the fact that consumer-facing Bitcoin companies have found muted traction, if any at all. For instance, BitPay (which raised $32.5 million) recently laid off most of its staff, liquidated a large portion of its bitcoin holdings, raised its fees in order to stay afloat and did a (non-pivot) pivot towards catering to other enterprises. This looks bad for other Bitcoin-branded companies looking to try and raise funds for consumer-facing products.
Another reason is that some of the buzz and froth simmered down with the price of bitcoin itself. It seems common parlance to hear people at conferences say “the price of bitcoin doesn’t matter” but that is very untrue for fundraising. If prices were on a tear into orbit or were managing some stability higher than it was 2 years ago, it’d be easier for entrepreneurs to convince new investors (not just the same 4-5 funds) to deploy new capital in Bitcoin-specific products. Maybe Gemini will change that?
So where has some capital been deployed instead?
Into that amorphous catch-all term: “blockchain.”
There are just over a dozen “blockchain” / distributed ledger startups collectively trying to raise $200 million at over a $1 billion valuation.
And incidentally, there are a couple companies in each of the VC portfolio’s above that have now built non-Bitcoin blockchains or ledgers.
Some of them are currently raising while others recently closed funding rounds.
This includes: Symbiont, Chain, Peernova, Ripple, Eris, Setl, Credits, Tradeblock, itBit, Tembusu, Clearmatics, MultiChain, BlockStack, DAH, Blockstream (via Liquid) and a few others in stealth that well, are in stealth.
The term “blockchain technology” is basically a catch-all term at this point.
In many cases, when someone at a fintech conference now says they’re interested in “blockchain technology” it typically means they are interested in common elements like public/private key signing, resolutions to double-spending and permission-based multitenancy environments. Bitcoin, as described by Gwern Branwen, was not the creator of those elements.
What will next year look like? Will there be a new term that is co-opted? Or are we stuck using a word that never appeared in the original Satoshi white paper (it had a demarcated space between “block chain”) and has now become an umbrella term for many different neat ideas?
Although I cannot speak for the whole team, I can give you the vision I have with the aim of bringing clarity to the various bits of information that have been circulating.
Over the past year, the R3 team has spent copious amounts of time conducting due diligence on the greater “distributed ledger” or “shared ledger” space. I joined as an advisor in January when they were already knee deep in the task; I am now Director of Market Research.
What I and several others on the team found is that while there were a number of orthogonally useful pieces floating around (such as multisig and ideas like Engima), none of the publicly available technology platforms that has been funded by venture capital provided a flexible, holistic base layer with the specific functional requirements for secure, scalable enterprise use.
This includes incorporating non-functionals that globally regulated financial institutions must adhere to such as: compliance, privacy, reporting and reconciliation. Similarly, many of the venture funded projects also failed to address the business requirements of these same institutions.
In sportsball terms, the nascent industry is 0-for-2 in their current approach.
Some of that is understandable; for example, Bitcoin solves a set of problems for a niche group of individuals operating under certain security assumptions (e.g., cypherpunks not wanting to interface with banks or governments). Regulated financial institutions do not operate under those assumptions, thus axiomatically Bitcoin in its current form is highly unlikely to be a solution to their problems at this time. As a consequence, the technology solutions pitched by many of these startups are hammers looking for nails that do not exist in the off-chain world.
R3 is not a Bitcoin company nor a cryptocurrency company. We are not seeking to build a “better” or even a different type of virtual currency. Why not? Instead of starting with a known solution, such as a spreadsheet, we are starting with the problem set which continually influences the customized solution. This is one of the biggest reasons I was attracted to this specific effort: R3 is not a re-enactment of Field of Dreams. Build it with the hopes that someone will come is the siren song, the motto even, for throngs of failed startups.
But weren’t the original shared ledgers — often called blockchains — robust enough to protect all types of assets and a legion of use-cases?
Many public ledgers were originally designed to secure endogenous, on-chain information (e.g., the native token) but in their current incarnations are not fit for purpose to handle off-chain titles. For instance, Bitcoin was not initially designed to secure exogenous data — such as transmitting high-value off-chain securities — vis-a-vis pseudonymous miners. And it appears all attempts to mutate Bitcoin itself into a system that does, ends up creating a less secure and very expensive P-o-P network.
What are we doing then?
Rather than try to graft and gerrymander our business requirements onto solutions designed for other problems, we are systematically looking at a cornucopia of challenges and cost-drivers that currently exist at financial institutions. We will seek to address some of these drivers with a generalized agnostic fabric, with layers that fulfill the critical infrastructure specifications of large enterprises and with services that can be run on top in a compliant fashion.
What is a Global Fabric for Finance (G3F) then? If you had the chance to build a new financial information network from scratch that incorporated some of the elements and learnings of the shared ledger world, what would it look like?
For starters, a fabric specifically built for and by trusted parties does not need something akin to mining or block rewards. In fact, not only is there is no Sybil spoofing problem on a trusted network but there are already many known, existing methods for securely maintaining a transaction processing system. Consequently, needing a block reward may (or may not) be a red herring and has likely been a costly, distracting sideshow to other types of utility that this technology represents.
If trust is not an issue, what use (as Arvind Narayanan and certain high profile enthusiasts have asked) is any part of the shared ledger toolkit? There are a number of uses, many of which I touched on in a paper back in April.
What about specific use-cases?
While a number of ideas that have surfaced at conferences and media events over the past summer, R3 remains focused on an approach of exploration and ideation.
And while there will likely be some isolated tests on some use-case(s) in sand boxes in the coming year, it is important to reflect on the G3F vision which will be further elaborated on by Richard Brown (our head of technology) in the coming weeks. If the fabric is only capable of handling one or two specific asset classes, it will fall short of the mandate of being a generalized fabric used to secure financial information for enterprises.
Why directly work with banks during this formative stage? Why not just raise money and start building and shipping code?
To be frank, if financial institutions and regulatory bodies are not involved and engaged from the beginning, then whatever fabric created will likely: 1) fail to be viewed as an authoritative and legal record of truth and 2) fall short of adequately address their exacting needs. It would be a non-starter for a financial institution to use technology that is neither secure, or whose on-chain record is considered non-canonical by off-chain authorities.
What does that mean?
While some in the shared ledger community would like to believe that dry, on-chain code supersedes off-chain wet-code, the facts on the ground continue to contradict that thesis. Therefore, if you are going to create a non-stealth fintech startup, it must be assumed that whatever products and services you create will need to operate under existing laws. Otherwise you will spend most of your time hiding out in remote Caribbean islands or Thailand.
The R3 team is comprised of pragmatic thinkers and doers, experienced professionals who understand that a financial system cannot be built with up and down votes on reddit or whose transaction processors may reside in sanctioned countries.
While nothing is finalized at the time of this writing, it is our aim at R3 to make the underlying base layer of this fabric both open sourced and an open standard.
After all, a foundation layer this critical would benefit from the collective eyeballs of the entire programming community. It also bears mentioning that the root layer may or may not even be a chain of hashed blocks.
Furthermore, we are very cognizant of the fact that the graveyard for building industry standards is deep and wide. Yet, as I mentioned to IBT, failing to create a universal standard will likely result in additional Balkanization, recreating the same silos that exist today and nullifying the core utility of a shared ledger.
It is a pretty exciting time in modern history, where being a nerd — even a cryptonerd — means you are asked to appear on stage in front of decision makers, policy makers, captains of industry and social media influencers. Some even get to appear in person and not just as a telepresence robot. Yet as neat as some of the moon math and cryptographic wizardry may be, failing to commercialize it in a sustainable manner could leave many of the innovative forks, libraries and github repos no more than starry-eyed science fair projects.
To that end, we are currently hiring talented developers keen on building a scalable, secure network. In addition, rather than reinventing the wheel, we are also open to partnerships with existing technology providers who may hold key pieces to building a unified standard. I am excited to be part of this mathematical industrial revolution, it’s time to strike while the iron is hot and turn good academic ideas into commercial reality. Feel free to contact us.
As of this writing, more than half of all VC funding to date has gone into building permissioned systems on top of a permissionless network (Bitcoin). Permissioned-on-Permissionless (PoP) systems are an odd hydra, they have all of the costs of Sybil-protected permissionless systems (e.g., high marginal costs) without the benefits of actual permissioned systems (e.g., fast confirmations, low marginal costs, direct customer service).
Thus it is curious to hear some enthusiasts and VCs on social media and at conferences claim that the infrastructure for Bitcoin is being rolled out to enable permissionless activity when the actual facts on the ground show the opposite is occurring. To extract value, maintain regulatory compliance and obtain an return-on-investment, much of the investment activity effectively recreates many of the same permission-based intermediaries and custodians that currently exist, but instead of being owned by NYC and London entities, they are owned by funds based near Palo Alto.
For example, below are a few quotes over the past 18 months.
In a February 2014 interview with Stanford Insights magazine, Balaji Srinivasan, board partner at Andreessen Horowitz and CEO of 21inc, stated:
Thus, if the Internet enabled permissionless innovation, Bitcoin allows permissionless monetization.
In July 2015, Coinbase announced the winners of its hackathon called BitHack, noting:
The BitHack is important to us because it taps into a core benefit of Bitcoin: permissionless innovation.
Also in July 2015, Alex Fowler, head of business development at Blockstream, which raised $21 million last fall, explained:
At Blockstream, our focus is building and supporting core bitcoin infrastructure that remains permissionless and trustless with all of the security and privacy benefits that flow from that architecture.
Yet despite the ‘permissionless’ exposition, to be a customer of these companies, you need to ask their permission first and get through their KYC gates.
Without limiting the foregoing, you may not use the Services if (i) you are a resident, national or agent of Cuba, North Korea, Sudan, Syria or any other country to which the United States embargoes goods (“Restricted Territories”), (ii) you are on the Table of Denial Orders, the Entity List, or the List of Specially Designated Nationals (“Restricted Persons”), or (iii) you intend to supply bitcoin or otherwise transact with any Restricted Territories or Restricted Persons.
Is there another way of looking at this phenomenon?
There have been a number of interesting posts in the past week that have helped to refine the terms and definitions of permissioned and permissionless:
Rather than rehashing these conversations, let’s look at a way to define permissionless in the first place.
A couple weeks ago I gave a presentation at the BNY Mellon innovation center and created the mental model above to describe some attributes of a permissionless blockchain. It is largely based on the characteristics described in Consensus-as-a-service.
DMMS validators are described in the Blockstream white paper. In their words:
We observe that Bitcoin’s blockheaders can be regarded as an example of a dynamic-membership multi-party signature (or DMMS ), which we consider to be of independent interest as a new type of group signature. Bitcoin provides the first embodiment of such a signature, although this has not appeared in the literature until now. A DMMS is a digital signature formed by a set of signers which has no fixed size. Bitcoin’s blockheaders are DMMSes because their proof-of-work has the property that anyone can contribute with no enrolment process. Further, contribution is weighted by computational power rather than one threshold signature contribution per party, which allows anonymous membership without risk of a Sybil attack (when one party joins many times and has disproportionate input into the signature). For this reason, the DMMS has also been described as a solution to the Byzantine Generals Problem [AJK05]
In short, there is no gating or authorizing process to enroll for creating and submitting proofs-of-work: theoretically, validating Bitcoin transactions is permissionless. “Dynamic-membership” means there is no fixed list of signatories that can sign (i.e. anyone in theory can). “Multi-party” effectively means “many entities can take part” similar to secure multi-party computation.1
Or in other permission-based terms: producing the correct proof of work, that meets the target guidelines, permits the miner (block maker) to have full authority to decide which transactions get confirmed. In other words, other than producing the proof-of-work, miners do not need any additional buy-in or vetting from any other parties to confirm transactions onto the blockchain. It also bears mentioning that the “signature” on a block is ultimately signed by one entity and does not, by itself, prove anything about how many people or organizations contributed to it.2
Censorship-resistance, while not explicitly stated as such in the original 2008 white paper, was one of the original design goals of Bitcoin and is further discussed in Brown’s post above as well as at length by Robert Sams.
The last bucket, suitable for on-chain assets, is important to recognize because those virtual bearer assets (tokens) are endogenous to the network. DMMS validators have the native ability to control them without some knob flipping by any sort of outside entity. In contrast, off-chain assets are not controllable by DMMS validators because they reside exogenous to the network. Whether or not existing legal systems (will) recognize DMMS validators as lawful entities is beyond the scope of this post.
What are some current examples of permissionless-related investments?
This past week I was in India working with a few instructors at Blockchain University including Ryan Charles. Ryan is currently working on a new project, a decentralized version of reddit that will utilize bitcoin.
In point of fact, despite the interesting feedback on the tweet, OB1 itself, the new entity that was formed after raising $1 million to build out the Open Bazaar platform, is permission-based.
How is it permission-based when the DMMS validators are still permissionless? Because OB1 has noted it will remove illicit content on-demand from regulators.
In an interview with CoinDesk, Union Square Venture managing partner, Brad Burnham stated that:
Burnham acknowledged that the protocol could be used by dark market operators, but stressed the OpenBazaar developers have no interest in supporting such use cases. “They certainly won’t be in the business of providing enhanced services to marketplaces that are selling illegal goods,” he noted.
Based on a follow-up interview with Fortune, Brian Hoffman, founder of OB1 was less specific and a bit hand-wavy on this point, perhaps we will not know until November when they officially launch (note: Tor support seems to have disappeared from Open Bazaar).
One segment of permissionless applications which have some traction but have not had much (if any) direct VC funding include some on-chain/off-chain casinos (dice and gambling games) and dark net markets (e.g., Silk Road, Agora). Analysis of this, more illicit segment will be the topic of a future post.
What are some other VC-funded startups that raised at least a Series A in funding, that could potentially be called permissionless? Based on the list maintained by Coindesk, it appears just one is — Blockchain.info ($30.5 million).
Why isn’t Coinbase, Xapo or Circle? These will be discussed below at length.
What about mining/hashing, aren’t these permissionless activities at their core?
Certain VC funded mining/hashing companies no longer offer direct retail sales to hobbyists, this includes BitFury and KnC Miner. These two, known entities, through a variety of methods, have filed information about their operations with a variety of regulators.3 To-date BitFury has raised $60 million and it runs its own pool which accounts for about 16% of the network hashrate. Similarly, KnC has raised $29 million from VCs and also runs its own pool, currently accounting for about 6% of the network hashrate.
What about other pools/block makers? It appears that in practice, some require know-your-customer (KYC), know-your-business (KYB), know-your-miner (KYM) and others do not (e.g., selling custom-made hardware anonymously can be tricky).
Spondoolies Tech is currently sold out of their hardware but require some kind of customer information to fill out shipping address and customs details. They have raised $10.5 million in VC funding.
GHash allows you to set up a pseudonymous account with throwaway email addresses (or via Facebook and Google+), but they have not published if they raised any outside funding
Most Chinese hashing and mining pools are privately financed. For instance, Bitmain has not needed to raise funding from VCs (yet). The also, currently, do not perform KYC on their users. I spoke with several mining professionals in China and they explained that none of the big pools (Antpool, F2pool, BTC China pool, BW.com) require KYM at this time. Over the past four days, these pools accounted for: 21%, 17%, 10% and 8% of the network hashrate respectively — or 56% altogether. Update 7/29/2015: a representative at BTC China explained that: “Yes, we do KYC the members of our mining pool. We verify them the same way we KYC all registered users on BTCC.”
21inc, not much more is known publicly at this time but if the idea of a “BitSplit” chip is correct, then what could happen is the following: as more chips are flipped on in devices, the higher the difficulty level rises (in direct proportion to the hashrate added). As a result, the amount of satoshi per hash declines over time in these devices. What this likely will lead to is a scenario in which the amount of satoshi mined by a consumer device will be less than “dust limit” which means a user will likely be unable to move the bitcoins off of the pool without obtaining larger amounts of bitcoin first (in order to pay the transaction fee). Consequently this could mean the users will need to rely on the services provided by the pool, which could mean that the pool will need to become compliant with KYC/AML regulations. All of this speculation at this time and is subject to changes. They have received $121 million in VC funding.
As explained above, while individual buyers of hashing equipment, Bob and Alice, do typically have to “doxx” themselves up to some level, both Bob and Alice can resell the hardware on the second-hand market without any documentation. Thus, some buyers wanting to pay a premium for hashing hardware can do so relatively anonymously through middlemen.4 This is similar to the “second-hand” market for bitcoins too: bitcoins acquired via KYC’ed gateways end up on LocalBitcoins.com and sold at a premium to those wanting to buy anonymously.
Notice a pattern? There is a direct correlation between permissionless platforms and KYC/AML compliance (i.e., regulated financial service businesses using cryptocurrencies are permissioned-on-permissionless by definition).
Blockchain.info attempts to skirt the issue by marketing themselves as a software platform and for the fact that they do not directly control or hold private keys.5
This harkens back to what Robert Sams pointed out several months ago, that Bitcoin is a curious design indeed where in practice many participants on the network are now known, gated and authenticated except the transaction validators.
What about permissioned-on-permissionless efforts from Symbiont, Chain and NASDAQ? Sams also discussed this, noting that:
Now, I am sure that the advocates of putting property titles on the bitcoin blockchain will object at this point. They will say that through meta protocols and multi-key signatures, third party authentication of transaction parties can be built-in, and we can create a registered asset system on top of bitcoin. This is true. But what’s the point of doing it that way? In one fell swoop a setup like that completely nullifies the censorship resistance offered by the bitcoin protocol, which is the whole raison d’etre of proof-of-work in the first place! These designs create a centralised transaction censoring system that imports the enormous costs of a decentralised one built for censorship-resistance, the worst of both worlds.
If you are prepared to use trusted third parties for authentication of the counterparts to a transaction, I can see no compelling reason for not also requiring identity authentication of the transaction validators as well. By doing that, you can ditch the gross inefficiencies of proof-of-work and use a consensus algorithm of the one-node-one-vote variety instead that is not only thousands of times more efficient, but also places a governance structure over the validators that is far more resistant to attackers than proof-of-work can ever be.
This phenomenon is something I originally dubbed “permissioned permissionlessness” for lack of a better term, but currently think permissioned-on-permissionless is more straightforward and less confusing.
What does this mean?
The Venn diagram above is another mental model I used at the BNY Mellon event.
As mentioned 3 months ago, in practice most block makers (DMMS validators) are actually known in the real world.
While the gating process to become a validator is still relatively permissionless (in the sense that no single entity authorizes whether or not someone can or cannot create proofs-of-work), the fact that they are self-identifying is a bit ironic considering the motivations for building this network in the first place: creating an ecosystem in which pseudonymous and anonymous interactions can take place:
The first rule of cypherpunk club is, don’t tell anyone you’re a cypherpunk. The first rule of DMMS club is, don’t tell anyone you’re a DMMS.
The second bucket, neither censorship resistant nor trade finality, refers to the fact that large VC funded companies like Coinbase or Circle not only require identification of its user base but also be censor their customers for participating in trading activity that runs afoul of their terms of service. Technically speaking, on-chain trade finality hurdles refers to bitcoin transactions not being final (due to a block reorg, a longer chain can always be found, undoing what you thought was a confirmed transaction). This has happened several times, including notably in March 2013.
For instance, in Appendix 1: Prohibited Businesses and Prohibited Use, Coinbase lays out specific services that it prohibits interaction with, including gambling. For example, about a year ago, users from Seals with Clubs and other dice/gambling sites noticed that they were unable to process funds from these sites through Coinbase and vice versa.
The tweet above is from Brian Armstrong is the CEO of Coinbase, which is the most well-funded permissioned-on-permissionless startup in the Bitcoin ecosystem. For its users, there is nothing permissionless about Bitcoin as they actively gate who can and cannot be part of their system and black list/white list certain activities, including mining (hashing) itself.6 It is not “open” based on common usage of the word.
In other words, contrary to what some Coinbase executives and investors claim, in an effort to extract value in a legally palatable manner, they must fulfill KYC/AML requirements and in doing so, effectively nullify the primary utility of a permissionless network: permissionlessness. Furthermore, Coinbase users do not actually use Bitcoin for most transactions as they do not control the privkey, Coinbase does. Coinbase users are not using Bitcoin on Coinbase, they are using an internal database.7 Or to use the marketing phrase: you are not your own bank, Coinbase is — which leads to a bevy of regulatory compliance questions beyond the scope of this post.8 However, once your bitcoins are out of Coinbase and into your own independent wallet where you control the private key, then you get the utility of the permissionless platform once more.
What are other permissioned-on-permissionless platforms? Below are twenty-seven different companies that have raised at least a Series A (figures via CoinDesk) in alphabetical order:
Altogether this amounts to around $492 million, which is more than half of the $855 million raised in the overall “Bitcoin space.”
What do these all have in common again? Most are hosted wallets and exchanges that require KYC/AML fulfillment for compliance with regulatory bodies. They require users to gain permission first before providing a service.
The chart above visualizes funding based on the schema’s explored in this post. Based on a total venture capital amount of $855 million, in just looking at startups that have received at least a Series A, 57.5% or $492 million has gone towards permissioned-on-permissionless systems. An additional $224 million, or 26.1% has gone towards mining and hashing.10
Permissionless-on-permissionless includes Blockchain.info, ShapeShift, Hive, Armory and a sundry of other seed-stage startups that collectively account for around $50 million or 5.8% altogether. The remaining 10.6% include API services such as Gem and BlockCypher; hardware wallets such as Case and Ledger; and analytic services such as Tradeblock. In all likelihood, a significant portion of the 10.6% probably is related to permissioned-on-permissionless (e.g., Elliptic, Align Commerce, Bonafide, Blockscore, Hedgy, BitPagos, BitPesa) but they have not announced a Series A (yet) so they were not included in the “blue” portion.
Why is Ripple Labs on that funding list above? While Ripple is not directly related to Bitcoin, it is aggregated on the funding list by CoinDesk.
Is it permissioned or permissionless? A few weeks ago I met with one of its developers, who said in practice, the validator network is effectively permissionless in that anyone can run a validator and that Ripple Labs validators will process transactions that include XRP.11
This past week, Thomas Kelleher tried to outline how Ripple Labs is some kind of “third way” system, that uses ‘soft permissions’ in practice. There may be a case for granular permissions on a permissionless network, but it did not coherently arise in that piece.
For example, in early May, Ripple Labs announced that it had been fined by FinCEN for not complying with the BSA requirements by failing to file suspicious activity reports (SARs), including notably, on Roger Ver (who did not want to comply with its KYC requests).
In addition to the fine, Ripple Labs also implemented a new identification gathering process for KYC compliance, stating:
The Ripple network is an open network. No one, including Ripple Labs, can prevent others from using or building on the Ripple protocol as they desire. However, when Ripple Labs provides software, such as the Ripple Trade client, Ripples Labs may impose additional requirements for the use of the software. As such, Ripple Labs will require identification of Ripple Trade account holders.
In other words, Ripple Labs was just fined by FinCEN for doing the very thing that Kelleher wants you to believe he is not required to do. All new Ripple Labs-based “wallets” (Ripple Trade wallets) require user info — this likely means they can control, suspend and block accounts.12 All eight of the main Ripple gateways are also obliged to gather customer information. The current lawsuit between Jed McCaleb and Ripple Labs, over the proceeds of $1 million of XRP on Bitstamp, will probably not be the last case surrounding the identification and control of such “wallet” activity (e.g., specific XRP flagged).
Thus, while the Ripple network started out as permissionless, it could likely become permissioned at some point due to compliance requirements. Why? If you download and install rippled, in practice you are going to use the default settings which rely on Ripple Labs core nodes. In practice, “choose your own” means “choose the default” for 99% percent of its users, ergo Ripple Labs sets the defaults.13 In a paper recently published by Peter Todd, he explained there is no game theoretic advantage to selecting non-default configurations which were not discussed in Kelleher’s essay.
Bob cannot choose his own rules if he has to follow compliance from another party, Ripple Labs. The UNL set may converge on an explicit policy as nodes benefit from not letting other nodes validate (they can prioritize traffic).14
I reached out to Justin Dombrowski, an academic who has spent the past year independently studying different ledger systems for a variety of organizations. In his view:
I have a hard time thinking of Ripple as anything but plain permissioned because I have a hard time thinking of a realistic circumstance under which an active user wouldn’t also have an account subject to KYC, or be indirectly connected to one. Sure, I can run a node for the purpose of experimenting with some Ripple app I’m developing, but at the end of the day I expect to be payed for that app. And I could mine for free—and yeah, in that case the network is permissionless for me—but that’s a atypical, trivial example I’d think. Ripple is theoretically permissionless, but practically not because incentives align only with permissioned uses.
As Dombrowski noted, things get taxonomically challenging when a company (Ripple Labs) also owns the network (Ripple) and has to begin complying with financial service regulations. This trend will likely not change overnight and until it explicitly occurs, I will probably continue to put an asterisk next to its name.
Challenges for DMMS validators in a permissioned-on-permissionless world
Over the past month, I have been asked a number of questions by managers at financial institutions about using public / communal chains as a method for transferring value of registered assets.
For instance, what happens if Bank A pays a fee to a Bitcoin or Litecoin miner/mining pool in a sanctioned country (e.g., EBA concerns in July 2014)?
In February 2015, according to a story published by Free Beacon, Coinbase was on “the hot seat” for explicitly highlighting this use-case in an older pitch deck because they stated: “Immune to country-specific sanctions (e.g. Russia-Visa)” on a slide and then went on to claim that they were compliant with US Treasury and NY DFS requirements.
Another question I have been asked is, what if the Bitcoin or Litecoin miner that processes transactions for financial institutions (e.g., watermarked tokens) also processes transactions for illicit goods and services from dark net markets? Is there any liability for a financial institution that continues to use this service provider / block maker?
Lastly, how can financial institutions identify and contact the miner/mining pool in the event something happens (e.g., slow confirmation time, accidentally sent the wrong instruction, double-spend attempt, etc.)? In their view, they would like to be able to influence upgrades, governance, maintenance, uptime (i.e., typical vendor relationship).
In the Consensus-as-a-service report I used the following chart showing trade-offs:I also used the following diagram to illustrate the buckets of a permissioned blockchain:
Recall that the term “mintette” was first used by Ben Laurie in his 2011 paper describing known, trusted validators and was most recently used in Meiklejohn (2015).
The general idea when I published the report several months ago was that permissionless-on-permissioned (what effectively what Ripple sits) is untenable in the long-run: due to regulatory pressure it is impossible to build a censorship-resistant system on top of a permissioned network.
Ryan Shea pointed this out in his recent piece, noting that:
Permission-ed blockchains are useful for certain things but they are limited in what they can do. Fully decentralized, permission-less, censorship-resistant applications CANNOT be built on them, which for many is a deal-breaker.
What does this mean for your business or organization? Before deciding what system(s) to use, it is important to look at what the organizations needs are and what the customer information requirements are.
As explored above, several startups and VC funds have unintentionally turned an expensive permissionless system into a hydra gated permissioned network without the full benefits of either. If you are running a ledger between known parties who abide by government regulations, there is no reason to pay the censorship-resistance cost. Full stop.15
[The optics of permissioned-on-permissionless]
Most efforts for “legitimizing” or “fixing” Bitcoin involves counteracting features of Bitcoin that were purposefully designed such that it enables users to bypass third parties including governmental policies and regulations. Businesses and startups have to fight to turn Bitcoin into something it isn’t, which means they are both paying to keep the “naughty” features and paying to hide them. For example, if Satoshi’s goal was to create a permissioned system that interfaces with other permissioned systems, he would likely have used different pieces — and not used proof-of-work at all.
The commercial logic of this (largely) VC-backed endgame seems to be: “privatize” Bitcoin through a dozen hard forks (the block size fork is the start of this trend that could also change the 21 million bitcoin hard-cap).16
It seems increasingly plausible that some day we may see a fork between the “permissionless-on-permissionless” chain (a non-KYC’ed chain) and the “permissioned-on-permissionless” chain (a fully KYC’ed chain) — the latter comprising VC-backed miners, hosted wallets, exchanges and maybe even financial institutions (like NASDAQ). The motivations of both are progressively disparate as the latter appears uninterested in developer consensus (as shown by the special interest groups wanting to createlargerblocks today by ignoring the feedback from the majority of active core developers and miners). At that point, there is arguably minimal-to-no need for censorship resistance because users and miners will be entirely permissioned (i.e. known by/to participating institutions and regulators).
When drilling down, some of the permissioned-on-permissionless investment appears to be a sunk cost issue: according to numerous anecdotes several of these VCs apparently are heavily invested in bitcoins themselves so they double down on projects that use the Bitcoin network with the belief that this will create additional demand on the underlying token rather than look for systems that are a better overall fit for business use-cases.17
This raises a question: is it still Bitcoin if it is forked and privatized? It seems that this new registered asset is best called Bitcoin-in-name-only, BINO, not to be confused with bitcoin, the bearer asset.18
If the end game for permissionless systems is one in which every wallet has to be signed by something KYC/KYB approved, it appears then that this means there would be a near total permissioning of the ledger. If so, why not use a permissioned ledger instead for all of the permissioned activity?
The discussion over centralized versus institutionalized will also be discussed in a future post.
[Acknowledgements: thanks to Richard Apodaca, Anton Bolotinsky, Arthur Breitman, Richard Brown, Dustin Byington, Justin Dombrowski, Thomas Kelleher, Yakov Kofner, Antony Lewis and John Whelan for their feedback.]
Are there any other non-mining projects that are VC funded projects that do not require KYC? A few notable examples include ShapeShift (which de-links provenance and does not require KYC from its users) and wallets such as Hive and Armory. All three of these are seed-stage. [↩]
Using similar forensics and heuristics from companies like Chainalysis and Coinalytics, Ripple Labs and other organizations can likely gather information and data on Ripple users prior to the April 2015 announcement due to the fact that the ledger is public. [↩]
Two years ago, David Schwartz, chief cryptographer at Ripple Labs, posted an interesting comment related to openness and decentralization on The Bitcoin Foundation forum. [↩]
Thanks to Jeremy Rubin and Roberto Capodieci for their feedback. [↩]
A couple hours ago I gave the following presentation to Infosys / Finacle in Mysore, India with the Blockchain University team. All views and opinions are my own and do not represent those of either organization.
Earlier today I gave the following presentation to Infosys / Finacle in Mysore, India with the Blockchain University team. All views and opinions are my own and do not represent those of either organization.
A few hours ago I gave the following presentation to Infosys / Finacle in Mysore, India with the Blockchain University team. All views and opinions are my own and do not represent those of either organization.
Earlier this morning I gave the following presentation to Infosys / Finacle in Mysore, India with the Blockchain University team. All views and opinions are my own and do not represent those of either organization.
[Note: below is a slightly edited speech I gave yesterday at a banking event in Palo Alto. This includes all of the intended legalese, some of which I removed in the original version due to flow and time. Special thanks to Ryan Straus for his feedback. The views below are mine alone and do not represent those of any organization or individual named.]
Before we look to the future of fintech, and specifically cryptocurrencies and distributed ledgers, let’s look at the most recent past. It bears mentioning that as BNY Mellon is the largest custodial bank in the world, we will see the importance of reliable stewardship in a moment below.
In January 2009 an unknown developer, or collective of developers, posted the source code of Bitcoin online and began generating blocks – batches of transactions – that store and update the collective history of Bitcoin: a loose network of computer systems distributed around the globe.
To self-fund its network security, networks like Bitcoin create virtual “bearer assets.” These assets are automatically redeemable with the use of a credential. In this case, a cryptographic private key. From the networks point of view, possession of this private key is the sole requirement of ownership. While the network rules equivocate possession and control, real currency – not virtual currency – is the only true bearer instrument. In other words, legal tender is the only unconditional exception to nemo dat quod non habet – also known as the derivative principal – which dictates that one cannot transfer better title than one has.
Several outspoken venture investors and entrepreneurs in this space have romanticized the nostalgia of such a relationship, of bearer assets and times of yore when a “rugged individual” can once again be their own custodian and bank.1 The sentimentality of a previous era when economies were denominated by precious metals held – initially not by trusted third parties – but by individuals, inspired them to invest what has now reached more than $800 million in collective venture funding for what is aptly called Bitcoinland.
Yet, the facts on the ground clearly suggests that this vision of “everyone being their own bank” has not turned into a renaissance of success stories for the average private key holder. The opposite seems to have occurred as the dual-edged sword of bearer instruments have been borne out. At this point, it is important to clearly define our terms. The concepts of “custody” and “deposit” are often conflated. While the concepts are superficially similar, they are very different from a legal perspective. Custody involves the transfer of possession/control. A deposit, on the other hand, occurs when both control and title is transferred.
Between 2009 and early 2014, based on public reports, more than 1 million bitcoins were lost, stolen, seized and accidentally destroyed.2 Since that time, several of the best funded “exchanges” have been hacked or accidentally sent bitcoins to the wrong customer. While Mt. Gox, which may have lost 850,000 bitcoins itself, has attracted the most attention and media coverage – rightfully so – there is a never ending flow of unintended consequences from this bearer duality.3
For instance, in early January 2015, Bitstamp – one of the largest and oldest exchanges – lost 19,000 bitcoins due to social engineering and phishing via Gmail and Skype on its employees including a system administrator.4 Four months later, in May, Bitfinex, a large Asian-based exchange was hacked and lost around 1,500 bitcoins.5 In another notable incident, last September, Huobi, a large Bitcoin exchange in Beijing accidentally sent 920 bitcoins and 8,100 litecoins to the wrong customers.6 And ironically, because transactions are generally irreversible and the sole method of control is through a private key they no longer controlled them: they had to ask for the bitcoins back and hope they were returned.
A study of 40 Bitcoin exchanges published in mid-2013 found that at that time 18 out of 40 – 45% — had closed doors and absconded with some portion of customer funds.7 Relooking at that list today we see that about another five have closed in a similar manner. All told, at least 15% if not higher, of Bitcoin’s monetary base is no longer with the legitimate owner. Can you imagine if a similar percentage of real world wealth or deposits was dislocated in the same manner in a span of 6 years?8
In many cases, the title to this property is encumbered, leading to speculation that since many of these bitcoins are intermixed and pooled with others, a large percentage of the collective monetary base does not have clean title, the implications of which can be far reaching for an asset that is not exempted from nemo dat, it is not fungible like legal tender.9
As a consequence, because people in general don’t trust themselves with securing their own funds, users have given – deposited – their private keys with a new batch of intermediaries that euphemistically market themselves as “hosted wallets” or “vaults.” What does that look like in the overall scheme? These hosted wallets, such as Coinbase and Xapo, have collectively raised more than $200 million in venture funding, more than a quarter of the aggregate funding that the whole Bitcoin space has received. Simultaneously, the new – often unlicensed – parties collectively hold several million bitcoins as deposits; probably 25-30% of the existing monetary base.10 Amazingly, nobody is actually certain whether a “hosted wallet” is a custodian of a customers bitcoin or acquired title to the bitcoin and is thus a depository.
Yet, in recreating the same financial intermediaries that they hoped to replace – in turning a bearer asset into a registered asset – some Bitcoin enthusiasts have done so in fashion that – as described earlier – has left the system ripe for abuse. Whereas in the real world of finance, various duties are segregated via financial controls and independent oversight.11 In the Bitcoin space, there have been few financial controls. For example, what we call a Bitcoin exchange is really a broker-dealer, clearinghouse, custodian, depository and an exchange rolled into one house which has led to theft, tape painting, wash trading, and front-running.12 All the same issues that led to regulatory oversight in the financial markets in the first place.
And while a number of the better funded and well-heeled hosted wallets and exchanges have attempted to integrate “best practices” and even third-party insurance into their operation, to date, there is only one Bitcoin “vault” – called Elliptic — that has been accredited with meeting the ISAE 3402 custodial standard from KPMG. Perhaps this will change in the future.
But if the point of the Bitcoin experiment, concept, lifestyle or movement was to do away or get away from trusted third parties, as described above, the very opposite has occurred.
What can be learned from this? What were the reasons for institutions and intermediation in the first place? What can be taken away from the recent multi-million dollar educational lesson?
We have collectively learned that a distributed ledger, what in Bitcoin is called a blockchain, is capable of clearing and settling on-chain assets in a cryptographically verifiable manner, in near-real time all with 100% uptime because its servers – what are called validators – are located around the world. As we speak just under sixty four hundred of these servers exist, storing and replicating the data so that availability to any one of them is, in theory, irrelevant.13
Resiliency, accountability and transparency, what’s not to like? Why wouldn’t financial institutions want to jump on Bitcoin then, why focus on other distributed ledger systems?
One of the design assumptions in Bitcoin is that its validators are unknown and untrusted – that there is no gating or vetting process to become a validator on its open network. Because it is purposefully expensive and slow to produce a block that the rest of the network will regard as valid, in theory, the rest of the network will reject your work and you will have lost your money. Thus, validators, better technically referred to as a block maker, attempt to solve a benign math problem that takes on average about 10 minutes to complete with the hope of striking it rich and paying their bills. There are exceptions to this behavior but that is a topic for another time.14
The term trust or variation thereof appears 13 times in the final whitepaper. Bitcoin was designed to be a solution for cypherpunks aiming to minimize trust-based relationships and mitigate the ability for any one party to censor or block transactions. Because validators are unknown and untrusted, to protect against history-reversing attacks, Bitcoin was purposefully designed to be inefficient.15 That is to say attackers must expend real world resources, energy, to disrupt or rewrite history. The theory is that this type of economic attack would stave off all but the most affluent nation-state actors; in practice this has not been the case, but that again is a topic for another speech.
Thus Bitcoin is perhaps the world’s first, commodity-based censorship resistance-as-a-service. To prevent attackers on this communal network from reversing or changing transactions on a whim, an artificially expensive anti-Sybil mechanism was built in dubbed “proof of work” – the 10 minute math problem. Based on current token value, the cost to run this network is roughly $300 million a year and it scales in direct proportion to the bitcoin market price.16
Thus there are trade-offs that most financial institutions specifically would not be interested in.
Why you may ask?
Because banks already know their customers, staff and partners. Their counterparties and payment processors are all publicly known entities with contractual obligations and legal accountability. Perhaps more importantly, the relationship created between an intermediary and a customer is clear with traditional financial instruments. For example, when you deposit money in your bank account, you know (or should know) that you are trading your money for an IOU from the bank.17 On the other hand, when you place money in a safe deposit box you know (or should know) that you retain title to the subject property. This has important considerations for both the customer and intermediary. When you trade your money for an IOU, you are primarily concerned with the financial condition of the intermediary. However, when you retain title to an object held by somebody else, you care far more about physical and logical security.
As my friend Robert Sams has pointed out on numerous occasions, permissionless consensus as it is called in Bitcoin, cannot guarantee irreversibility, cannot even quantify the probability of a history-reversing attack as it rests on economics, not technology.18 Bitcoin is a curious design indeed where in practice many participants on the network are now known, gated and authenticated except the transaction validators. Why use expensive proof-of-work at all at this point if that is the case? What is the utility of turning a permissionless system into a permissioned system, with the costs of both worlds and the benefits of neither?
But lemonade can still be squeezed from it.
Over the past year more than a dozen startups have been created with the sole intent to take parts of a blockchain and integrate their utility within financial institutions.19 They are doing so with different design assumptions: known validators with contractual terms of service. Thus, just as PGP, SSL, Linux and other open source technology, libraries and ideas were brought into the enterprise, so too are distributed ledgers.
Last year according to Accenture, nearly $10 billion was invested in fintech related startups, less than half of one percent of which went to distributed ledger-related companies as they are now just sprouting.20
What is one practical use? According to a 2012 report by Deutsche Bank, banks’ IT costs equal 7.3% of their revenues, compared to an average of 3.7% across all other industries surveyed.21) Several of the largest banks spend $5 billion or more in IT-related operating costs each year. While it may sound mundane and unsexy, one of the primary use cases of a distributed ledger for financial institutions could be in reducing the cost centers throughout the back office.
For example, the settlement and clearing of FX and OTC derivatives is an oft cited and increasingly studied use case as a distributed ledger has the potential to reduce counterparty and systemic risks due to auditability and settlement built within the data layer itself.22
How much would be saved if margining and reporting costs were reduced as each transaction was cryptographically verifiable and virtually impossible to reverse? At the present time, one publicly available study from Santander estimates that “distributed ledger technology could reduce banks’ infrastructure costs attributable to cross-border payments, securities trading and regulatory compliance by between $15-20 billion per annum by 2022.”23
With that said, in its current form Bitcoin itself is probably not a threat to retail banking, especially in terms of customer acquisition and credit facilities. For instance, if we look at on-chain entities there are roughly 370,000 actors. If the goal of Bitcoin was to enable end-users to be their own bank without any trusted parties, based on the aggregate VC funding thus far, around $2,200 has been spent to acquire each on-chain user all while slowly converting a permissionless system into a permissioned system, but with the costs of both.24
That’s about twice as much as the average bank spends on customer acquisition in the US. While there are likely more than 370,000 users at deposit-taking institutions like Coinbase and Xapo, they neither disclose the monthly active users nor are those actual Bitcoin users because they do not fully control the private key.
If we were to create a valuation model for the bitcoin network (not the price of bitcoins themselves), the network would be priced extremely rich due to the wealth transfer that occurs every 10 minutes in the form of asset creation. The network in this case are miners, the block makers, who are first awarded these bearer instruments.
How can financial institutions remove the duplicative cost centers of this technology, remove this $300 million mining cost, integrate permissioned distributed ledgers into their enterprise, reduce back office costs and better serve their customers?
That is a question that several hundred business-oriented innovators and financial professionals are trying to answer and we will likely know in less time it took Bitcoin to get this far.