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.
For instance, in Circle’s user agreement they note that:
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.
Permissionless blockchains
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.
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.
Another potential term for DMMS is what Ian Grigg called a Nakamoto signature.
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.
Permissionless investments
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. 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).
- MegaBigPower gathers KYC information.
- 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. 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.
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?
Permissioned-on-Permissionless
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. 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. 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. 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:
- Bitex.la: ($4 million)
- BitGo: ($14 million)
- BitGold: ($5.3 million)
- Bitnet: ($14.5 million)
- BitPay: ($32.5 million)
- Bitreserve: ($14.6 million)
- Bitstamp: ($10 million)
- BitX: ($4.82 million)
- BTC China ($5 million)
- ChangeTip: ($4.25 million)
- Chain: ($13.7 million)
- Circle: ($76 million)
- Coinbase: ($106 million)
- Coinplug: ($3.3 million)
- Coinsetter: ($1.9 million)
- Cryex: ($10 million)
- GoCoin: ($2.05 million)
- Huobi ($10 million)
- itBit: ($28.25 million)
- Korbit: ($3.4 million)
- Kraken: ($6.5 million)
- Mirror, formerly Vaurum: ($12.8 million)
- OKCoin: ($11 million)
- Ripple Labs ($37 million)
- Vogogo ($21 million)
- Xapo: ($40 million)
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.
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.
Ripple Labs
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.
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.
We will ask you to submit personally identifiable information (PII) similar to what you would submit to open a bank account, such as full name, address, national ID number, and date of birth. Users may also be asked to upload their driver’s license or other identifying documents. We will use this information to verify your identity for compliance purposes. We take privacy seriously, so the information you provide during the customer identification process is encrypted and managed by Ripple Trade’s Privacy Policy.
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. 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. 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).
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).
Trade-offs
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.
Conclusions
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.
[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).
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 create larger blocks 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.
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.
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.]
Endnotes
