- Public versus Private Blockchains Part 1, Permissioned Blockchains
- Public versus Private Blockchains Part 2, Permissionless Blockchains
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.
For those interested, there are a handful of “standard’ transaction types that are usually accepted by most mining pools.
On p. 11, I disagree with this statement:
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.
Yes there is in fact things preventing Bitcoin from being used to move registered assets, see “Watermarked tokens and pseudonymity on public blockchains.” And their methods in Section 1.6 are non-starters.
Also on page 4 they wrote:
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.
- See also: Needing a token to operate a distributed ledger is a red herring and A blockchain with emphasis on the “a” [↩]
- See also: Can Bitcoin’s internal economy securely grow relative to its outputs? and Will colored coin extensibility throw a wrench into the automated information security costs of Bitcoin? [↩]
- This includes: Fedcoin—how banks can survive blockchains by Robin Winkler and Centrally Banked Cryptocurrencies by George Danezis and Sarah Meiklejohn [↩]
- See Seigniorage Shares from Robert Sams [↩]
- See: A Protocol for Interledger Payments by Stefan Thomas and Evan Schwartz and An architecture for the Internet of Money by Meher Roy [↩]
- See also: Chapter 10 in The Anatomy of a Money-like Informational Commodity and Economic Aspects of Bitcoin and Other Decentralized Public-Ledger Currency Platforms by David Evans [↩]