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 overview on scaling Bitcoin was originally included in a new paper but needed to be removed for space and flow considerations]
Looking in the past, the older Viceroy overlay network scaled at O(logN) where N is the number of peers which is different than the contentious scaling in Bitcoin, where even Core developers do not agree on how per node bandwidth actually scales.1
For instance, one group of developers thinks that per node bandwidth on the Bitcoin network scales linearly, O(n).2
The use of O(n) is a way of capturing simply whether something scales linearly or not. O(n) means: if it takes 5 seconds to do something when there are 10 nodes, it will take 50 seconds if there are 100. An example would be washing the dishes. It takes 30 seconds per plate and you just keep going one plate after another.
In contrast, another group of developers believes bandwidth requirements squares per node, which reads as O(n2).3
O(n2) means: if it takes 5 seconds to do something when there are 10 nodes, it will take 5 hundred seconds if there are 100. O(x) notation is an approximate. That is to say, while you have increased the number of items by a factor of 10, the time taken increased by a factor of about 100.
An example here might be if Bob needs to broker bilateral contracts between all the members of a new limited partnership fund. Four partners would require six bilateral NDAs in total. Eight partners would require 24. Thus if Bob doubled the number of partners he would need more than four times as many contracts executing.4
One calculation (BitFury 2015a) implies that in terms of block verification time, Bitcoin scales at: N(1 + 0:091 log2 N).5 For comparison, Ripple’s consensus ledger also has O(n2) scaling.67
What does this have to do with watermarked tokens?
[C]olored coins are potentially nefarious to the Bitcoin ecosystem. The security of Bitcoin rests on the assumption that miners stand to lose more by departing from consensus than they stand to gain. This assumption requires a balance between the reward received by miners, and the amounts they might stand to gain by reversing transactions. If colored coins represent valuable assets, this balance might be upset, endangering the status of all transactions.
A consequence of the hold-up problem is that it could lead to vertical integration. That is to say, to prevent this type of event (holding up the whole network) from happening in the future, colored coin platforms could acquire (or build) hashing facilities and pools.
Yet if they did this, not only would they need to increase expenditures by several orders of magnitude – which is the very reason they wanted to piggy back off the existing infrastructure to begin with – but they would effectively be building a permissioned network, with very high marginal costs.
In (Breitman 2015c) the author uses a car analogy to describe the cantankerous situation colored coins have created.9
In the analogy, the author explores an alternative universe in which the car was recently created and new owners foresaw the ability to use the car in many different ways, including a new “application” called shipping.
In this scenario, the car owners unilaterally dismissed unproven alternative “truck technology” and instead designed a solution for shipping: bolt a new wooden layer on top of four cars, much like watermarked platforms bolt themselves on top of Bitcoin.
But what about all the various mechanical challenges that came with this new ad hoc design?
Breitman makes the point that, though the same functionality of a truck can be achieved by putting a slab of wood on top of four cars, choosing it as a solution when other options exist is not effective. Similarly, in the context of a closed system, it makes little sense to rely on bitcoind, though inexperienced developers may have a bias towards it:
To be sure, they were several problems with the design. The aerodynamics were atrocious, but that could be somewhat alleviated by placing a tent over the contraption. Turning was initially difficult, but some clever engineers introduced swivels on top of the car, making the process easier. The cars would not always stay at the same speed, but using radio communication between the drivers more or less remedied the issue.
But, truck technology? Well that was unproven, and also trucks looked a lot like train wagons, and the real innovation was the car, so cars had to be used!
Where am I going with this? A large number of projects in the space of distributed ledgers have been peddling solutions involving the use of colored coins within permissioned ledgers. As we’ve explained earlier, colored coins were born out of the near impossibility of amending the code base of Bitcoin. They are first and foremost a child of necessity in the Bitcoin world… a necessary evil, a fiendish yet heroic hack unlocking new functionality at a dire cost.
One could argue that reusing the core bitcoind code offers the benefit of receiving downstream bug fixes from the community. This argument falls flat as the gist of such fixes can be incorporated into any implementation. Issues encountered by Bitcoin have ranged from a lack of proper integer overflow checking to vulnerabilities with signature malleability. Such issues can potentially affect any blockchain implementation; the difficulty lies in identifying them, not in producing a patch to fix them, a comparatively straightforward process. Of course, other bugs might be introduced when developing new functionalities, but the same is true regardless of the approach undertaken.
Basing a fresh ledger, independent from the Bitcoin blockchain, on a colored coin implementation is nothing short of perversion. It is akin to designing a truck using a wooden board bolted on the top of four cars. If, for some reason, the only type of vehicle that could use a highway were sedans, that solution might make sense. But if you have the chance to build a truck and instead chose to rig a container on top of a few cars then perhaps you should first learn how to engineer trucks.
As explored in the game theory model in Appendix B and car example above, there are real security issues with using this specific layered approach in both permissionless and permissioned systems.
The typical excuse for going such route is that building a new blockchain from scratch (e.g., Ethereum, Zerocash, Tendermint, Tezos) delays market entry and could make your startup fall behind the competition.
While it may be true that spending a year or more to purposefully design a new distributed ledger network from scratch will take significant time and resources, the reasons for doing (better security and scalabity) outweigh the downsides (systemic risks and vulnerabilities). Future research should also build models with additional agents.
It also bears repeating that based on the model presented in Appendix B, if the cost of attack is very high, the more plausible outcome is to not attack. However, if it is very attractive to attack there could have a different outcome that is worth further research.
Over the past five months there have been volumes of emails, forum posts and panel discussions on the topic of how Bitcoin can and does scale. One thread that is recommended to readers is a recent reddit debate between Mike Hearn (mike_hearn) and Greg Maxwell (nullc). [↩]
[Note: the following literature review was originally included in a new paper but needed to be removed for space and flow considerations]
How has previous research looked at information security?
Academic literature covering distributed computing and economics of information security and specifically peer-to-peer networks “Before Bitcoin” spans several decades.
Surveying literature (Lua et al. 2004; Hoffman et al. 2007; Momani and Challa 2009) we can see that there have been dozens of attempts to create decentralized peer-to-peer reputation systems that needed to be self-organizing, Sybil-resistant and fault tolerant.1
For instance, the Content Addressable Network (CAN), Chord, Kademlia and the Cooperative File System (CFS) each had a variety of characteristics that attempted to stave off abuse from attackers due to the environments they operated in (e.g., a distributed decentralized P2P infrastructure). Some used public-private key pairs, content hashes and others used NodeID.
These surveys also looked at Distributed Hash Trees (DHT) which have been known to be vulnerable to a number of attacks including Eclipse attacks, where the peering network itself comes under attack (which Bitcoin’s network is also prone to).2
What about other game theory issues? For example in (Lua et al., 2004) the authors wrote that:3
The ability to overcome free-rider problems in P2P overlay networks will definitely improve the system’s reliability and its value.
Sybil attacked termed by Douceur4 described the situation whereby there are a large number of potentially malicious peers in the system and without a central authority to certify peers’ identities. It becomes very difficult to trust the claimed identity. Dingledine et al.,5 proposes puzzles schemes, including the use of micro-cash, which allows peers to build up reputations. Although this proposal provides a degree of accountability, this still allows a resourceful attacker to launch attacks.
This is the same problem discussed above, that (Rosenfeld 2012) runs into regarding how to pay nodes on an open network.
How do these researchers believe it could be solved or fixed? According to (Lua et al., 2004):6
Having some sort of incentive model using economic and game theories, for P2P peers to collaborate is crucial to create an economy of equilibrium. When non-cooperative users benefit from free-riding on others’ resources, the tragedy of the commons7 is inevitable. Such incentives implementation in P2P overlay services would also provide a certain level of self-regulatory auditing and accounting behavior for resource sharing.
As shown above, despite rhetoric at Bitcoin-related conferences, many of the challenges facing Bitcoin today are in fact known problems facing decentralized peer-to-peer networks in general. The problem space for preventing Sybil attacks was and is relatively well-defined, Bitcoin again side-steps the actual solution by making it economically expensive, but not technically impossible to conduct history-reversing attacks, or even Sybil attacks on the gossip network.
P2Prep is a reputation system designed to “mitigate the effects of selfish and malicious peers in an anonymous, completely decentralized system.”8
How did it do this?
The system guards the anonymity of users and the integrity of packets through the use of public key cryptography. All replies are signed using the requester’s public key, protecting the identity of the responder and the integrity of the data. Only the requester is able to decrypt the packet and check the validity of the information.9
Credence (Walsh and Sirer 2006) is another peer-to-peer reputation system that uses gossip-based techniques to disseminate information.10 It defends itself:11
A key security consideration in the Credence system is the use of mechanisms to prevent spoofed votes or votes generated by fake identities. The system guards against such attacks by issuing digital certificates in an anonymous but semi-controlled fashion. The authors propose to mitigate Sybil attacks by requiring expensive computation on the part of the client before the server grants a new digital certificate. Every voting statement is digitally signed by the originator and anyone can cryptographically verify the authenticity of any given voting statement.
In (Momani and Challa 2010) the authors looked at security and trust concepts surrounding wireless sensor networks (WSN). At first glance this may seem unrelated to peer-to-peer networks but there are many similarities:12
The security issue has been raised by many researchers [14 – 24], and, due to the deployment of WSN nodes in hazardous and/or hostile areas in large numbers, such deployment forces the nodes to be of low cost and therefore less reliable or more prone to overtaking by an adversary force. Some methods used, such as cryptographic authentication and other mechanisms [25 – 32], do not entirely solve the problem. For example, adversarial nodes can have access to valid cryptographic keys to access other nodes in the network. The reliability issue is certainly not addressed when sensor nodes are subject to system faults. These two sources of problems, system faults and erroneous data or bad routing by malicious nodes, can result in the total breakdown of a network and cryptography by itself is insufficient to solve these problems. So new tools from different domains social sciences, statistics, e-commerce and others should be integrated with cryptography to completely solve the unique security attacks in WSNs, such as node capturing, Sybil attacks, denial of service attacks, etc.
In their survey they identified previous research that had looked at some of these same issues including In (Xiong and Liu 2003) where the authors attempted to build a reputation-based trust model for peer-to-peer distributed commerce platforms and use game theory to ameliorate the trust parameters by threats from malicious attacks.13
Going back more than fifteen years we can see that other researchers (Lamport 1998) and (Castro and Liskov 1999), that successful attempts were made to “use cryptographic techniques to prevent spoofing and replays and to detect corrupted messages” on a network that replicates services in the face of Byzantine faults.14
Volumes more can and will likely be written covering the research on these specific topics due in large part to the integral role that different types of information and financial networks play in the lives of consumers and businesses alike.
J. R. Douceur, “The sybil attack,” in Proceedings of the First International Workshop on Peer-to-Peer Systems , March 7-8 2002, pp. 251– 260. [↩]
R. Dingledine, M. J. Freedman, and D. Molnar, “Accountability measures for peer-to-peer systems,” in Peer-to-Peer: Harnessing the Power of Disruptive Technologies , D. Derickson, Ed. O’Reilly and Associates, November. [↩]
[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. [↩]
[Note: the following overview on known Bitcoin mining farms was originally included in a new paper but needed to be removed for space and flow considerations]
Several validators on the Bitcoin network, as well as many watermarked token issuers, are identifiable and known.1 What does this mean? Many Bitcoin validators are drifting usage outside the pseudonymous context of the original network due to their use of specialty equipment that creates a paper trail. In other words, pseudonymity has given way to real world identity. Soon issuers of color will likely follow because they too have strong ties to the physical, off-chain world.
For instance, on August 4, 2015, block 368396 was mined by P2Pool. This is notable for two reasons.
The first is that the block included a transaction sent from Symbiont.io, a NYC-based startup building “middleware” that enables organizations and financial institutions to create and use ‘smart securities’ off-chain between multiple parties and have the resulting transaction hashed onto a blockchain, in this case, the Bitcoin blockchain.2
Several weeks later, Symbiont announced that it would begin using their “stack” to provide similar functionality on a permissioned ledger.3 This follows a similar move by T0.com – a wholly owned subsidiary of Overstock.com – which initially used Open Assets to issue a $5 million “cryptobond” onto the Bitcoin blockchain, but have subsequently switched to using a “blockchain-inspired” system designed by Peernova.456
The second reason this was notable is that the block above, 368396, included at least one transaction from Symbiont which was mined by a small pool called P2Pool.7Unlike other pools discussed in this paper, P2Pool is not continually operated in a specific region or city.
It is decentralized in that all participants (hashers) must run their own full Bitcoin nodes which stand in contrast with pools such as F2Pool, KnC mining pool and BTCC (formerly called BTC China), where the pool operator alone runs the validating node and the labor force (hashers) simply search for a mid-state that fulfills the target difficulty.8
Due to this resource intensive requirement (running a full node requires more bandwidth and disk space than merely hashing itself), P2Pool is infrequently used and consequently comprises less than 1% of the current network hashrate.
P2Pool’s users are effectively pseudonymous. Due to the intended pseudonymity it is also unclear where the transaction fees and proceeds of hashing go. For instance, do the hashers comprising this pool benefit from the proceeds of illicit trade or reside in sanctioned countries or who to contact in the event there is a problem? And unlike in other pools, there is no customer service to call and find out.
Bitcoin’s – and P2Pool’s – lack of terms of service was intentionally done by design (i.e., caveat emptor). And in the event of a block reversal, censored transaction or a mere mistake by end-users, as noted above there is no contract, standard operating procedure or EULA that mining pools (validators) must adhere to. This is discussed in section 3.
This pseudonymous arrangement was the default method of mining in 2009 but has evolved over the years. For example, there are at least two known incidents in which a miner was contacted and returned fees upon request.
Launched in late summer of 2012 and during the era of transition from GPUs and FPGA mining, ASICMiner was one of the first publicly known companies to create its own independent ASIC mining hardware. Its team was led by “FriedCat,” a Chinese businessman, who custom designed and integrated ASIC chips called Block Eruptors, ASICMiner operated their own liquid immersion facility in Hong Kong.9
At its height, ASICMiner (which solo-mined similar to KnC and BitFury do today) reached over 10% of the network hashrate and its “shareholders” listed its stock on GLBSE (Global Bitcoin Stock Exchange), GLBSE is a now defunct virtual “stock market” that enabled bitcoin users to purchase, trade and acquire “shares” in a variety of listed companies.10 GLBSE is notable for having listed, among other projects, SatoshiDice which was later charged by the Securities and Exchange Commission (SEC) for offering unregistered securities to the public.1112
While unregistered stock exchanges catering to cryptocurrency users and China-based mining pools may be common sights today, on August 28, 2013, a bitcoin user sent a 200 bitcoin fee that was processed by ASICMiner.13 Based on then-market rates, this was approximately worth $23,518.14 The next day, for reasons that are unknown, ASICMiner allegedly sent the errant fee back to the original user.15At the time, one theory proposed by Greg Maxwell (a Bitcoin Core developer) was that this fee was accidentally sent due to a bug with CoinJoin, a coin-mixing service.16
Liquid cooled hashing equipment at ASICMiner in 2013. Source: Xiaogang Cao
The second notable incident involved BitGo, a multisig-as-a-service startup based in Palo Alto and AntPool, a large China-based pool (which currently represents about 15% of the network hashrate) operated by Bitmain which also manufacturers Antminer hardware that can be acquired directly from the company (in contrast to many manufacturers which no longer sell to the public-at-large). On April 25, 2015 a BitGo user, due to a software glitch, accidentally sent 85 bitcoins as a mining fee to AntPool. Based on then-market rates, this was worth approximately $19,197.17
The glitch occurred in BitGo’s legacy recovery tool which used an older version of a library that causes a 32-bit truncation of values and results in a truncation of outputs on the recovery transaction.18 To resolve this problem, the user “rtsn” spent several days publicly conversing with tech support (and the community) on Reddit.19
Eventually the glitch was fixed and Bitmain – to be viewed as a “good member of the community” yet defeating the purpose of a one-way-only, pseudonymous blockchain – sent the user back 85 bitcoins.
Fee to Bitmain (Antpool) highlighted in red on Total Transaction Fee chart. Source: Blockchain.info
On September 11, 2015 another user accidentally sent 4.6 bitcoins (worth $1,113) as a fee to a mining pool, which in this instance was AntPool.20 Bitmain, the parent company, once again returned the fee to the user.
HaoBTC is a newly constructed medium-sized hashing farm located in Kangding, western Sichuan, near the Eastern border with Tibet.22 It currently costs around 1.5 million RMB per petahash (PH) – or $242,000 – to operate per year. This includes the infrastructure and miner equipment costs. It does not include the operating costs which consists of: electricity, labor, rent and taxes (the latter two are relatively negligible).
The facility itself cost between $600,000 – $700,000 to build (slightly less than the $1 million facility BitFury built in 2014 in the Republic of Georgia) and its electrical rate of 0.2 RMB per kWh comes from a nearby hydroelectric dam which has a 25,000 kW output (and cost around $10 million to construct).23
In dollar terms this is equivalent to around $0.03 / kWh (during the “wet” or “summer” season). For perspective, their electric bill in August 2015 came in at 1.4 million RMB (roughly $219,000); thus electricity is by far the largest operating cost component.
When all the other costs are accounted for, the average rises to approximately $0.045 per kWh. The electricity rate is slightly more expensive (0.4 RMB or $0.06) during winter due to less water from the mountains. The summer rate is roughly the same price as the Washington State-based hashing facilities which is the cheapest in the US (note: it bears mentioning that Washington State partly subsidizes hydroelectricity).
HaoBTC staff installing hashing equipment. Source: Eric Mu
At this price per joule it would cost around $105 million to reproduce “work” generated by the 450 petahash Bitcoin blockchain. Due to a recent purchase of second-hand ASICMiner Tubes, HaoBTC currently generates just over 10 PH and they are looking to expand to 12 PH by the end of the year.24The key figure that most miners are interested in is that at the current difficulty level it costs around $161 for HaoBTC’s farm to create a bitcoin, giving them a nearly 100% margin relative to the current market price.
The ASIC machines they – and the rest of the industry uses – are single use; this hashing equipment cannot run Excel or Google services, or even bitcoind. Thus common comparisons with university supercomputers is not an apples-to-apples comparison as ASIC hashing cannot do general purpose computing; ASIC hashing equipment can perform just one function.25
There is also a second-hand market for it. For instance, hashing facilities such as HaoBTC actively look to capitalize off their unique geographical advantages by using older, used hardware. And there is a niche group of individuals, wanting to remain anonymous, that will also purchase older equipment.26
Although individual buyers of new hashing equipment such as Bob, do typically have to identify themselves to some level, both Bob can also resell the hardware on the second-hand market without any documentation. Thus, some buyers wanting to buy hashing equipment anonymously can do so for a relative premium and typically through middlemen.2728
While Bitbank’s BW mining farm and pool have been in the news recently29, perhaps the most well-known live visual of mining facilities is the Motherboard story on a large Bitcoin mining farm in Dalian, Liaoning:30
Incidentally, while Motherboard actually looked at just one farm, the foreigner helping to translate for the film crew independently visited another farm in Inner Mongolia which during the past year Bitbank apparently acquired.31
Are there any other known facilities outside of China?32
Genesis Mining is a cloudhashing service provider that purportedly has several facilities in Iceland.33According to a recent news story the company is one of the largest users of energy on the island and ignoring all the other costs of production (aside from electricity), it costs about $60 to produce a bitcoin.34 However, when other costs are included (such as hardware and staffing) the margin declines to — according to the company — about 20% relative to the current bitcoin price. At the time of the story, the market price of a bitcoin was around $231.
The four illustrations above are among a couple dozen farms that generate the majority of the remaining hashrate.
What does this have to do with colored coins?
The network was originally designed in such a way that validators (block makers) were pseudonymous and identification by outside participants was unintended and difficult to do. If users can now contact validators, known actors in scenic Sichuan, frigid Iceland or rustic Georgia, why not just use a distributed ledger system that already identifies validators from the get go? What use is proof-of-work at all? Why bother with the rhetoric and marginal costs of pseudonymity?
The social pressure type of altruism noted above (e.g,. Bitmain and BitGo returning fees) actually could set a nebulous precedent: once block rewards are reduced and fees begin to represent a larger percentage of miner revenue, it will no longer be an “easy” decision to refund the user in the event there is a mistake.35 If Bitmain did not send a refund, this backup wallet error would serve as a powerful warning to future users to try and not make mistakes.
While there have been proposals to re-decentralize the hashing process, such as a consumer-device effort led by 21inc which amounts to creating a large corporate operated botnet, one trend that has remained constant is the continued centralization of mining (block making) itself.3637 The motivation for centralizing block making has and continues to be about one factor: variance in payouts.38 Investors in hashing prefer stable payouts over less stable payouts and the best way to do that with the current Poisson process is to pool capital (much like pooling capital in capital markets to reduce risk).
Whether or not these trends stay the same in the future are unknown, however it is likely that the ability to contact (or not contact) certain pools and farms will be an area of continued research.
Similarly one other potential drawback of piggy backing on top of a public blockchain that could be modeled in the future is the introduction of a fat tail risk due to the boundlessness of the price of the native token.39 In the case of price spikes even if for short time can create price distortions or liquidity problem on the off-chain asset introducing a correlation between the token and the asset that theoretically was not supposed to be there.
For instance, the staff of Let’s Talk Bitcoin issues LTBCoin on a regular basis to listeners, content creators and commenters. [↩]
One reviewer likened the Overstock “cryptobond” proof of concept as a large wash trade: ”Basically it’s a cashless swap of paper and thus no currency settlement. And the paper has no covenants and thus very easy to digitally code. Basically Overstock is paying FNY a spread of 4% for doing this deal. And if the bond and loan are called simultaneously, say in the next month, that means that Overstock paid FNY about $16,667.00 to do this trade. And since there was no cash exchanged, I am presuming, then this is smoke and mirrors. But they actually did it. However, I don’t see much of a business model where the issuer of a bond has to simultaneously fund the investor with a loan to buy the bond and pay him 33 basis points to boot!” [↩]
In (Rosenfeld 2012) the author noted that one of the risks for running an “alternative to traditional markets” – such as GLBSE – were the regulatory compliance hurdles. Overview of Colored Coins by Meni Rosenfeld, p. 4. [↩]
Personal correspondence with Eric Mu, August 10, 2015 [↩]
One common talking point by some Bitcoin enthusiasts including venture capitalists is that Google’s computers, if repurposed for mining Bitcoin, would generate only 1-2% of the network hashrate – that the Bitcoin network is “faster” than all of Google’s data centers combined. This is misleading because these Bitcoin hashing machines cannot provide the same general purpose utility that Google’s systems can. In point of fact, the sole task that ASIC hashing equipment itself does is compute two SHA256 multiplications repeatedly. [↩]
Some academic literature refers to miners on the Bitcoin network as “anonymous participants.” In theory, Bitcoin mining can be anonymous however by default mining was originally a pseudonymous activity. Participants can attempt to remain relatively anonymous by using a variety of operational security methods or they can choose to identify (“doxx”) themselves as well. See The Bitcoin Backbone Protocol: Analysis and Applications by Garay et al. [↩]
This is similar to the “second-hand” market for bitcoins too: bitcoins originally acquired via KYC’ed gateways sometimes end up on sites like LocalBitcoins.com (akin to “Uber for bitcoins”) – where the virtual currency is sold at a premium to those wanting to buy anonymously. [↩]
While it is beyond the scope of this paper, there are a couple of general reasons why medium-sized farms such as HaoBTC have been erected in China. Based upon conversations with professional miners in China one primary reason is that both the labor and land near energy generating facilities is relatively cheap compared with other parts of the world. Furthermore, energy itself is not necessarily cheaper, unless farms managers and operators have guanxi with local officials and power plant owners. And even though it is common to assume that due to the capital controls imposed at a national level – citizens are limited to the equivalent of $50,000 in foreign exchange per year – there have been no public studies as to how much capital is converted for these specific purposes. There are other ways to avoid capital controls in China including art auctions and pawn shops on the border with Macau and Hong Kong. See also How China’s official bank card is used to smuggle money from Reuters and What Drives the Chinese Art Market? The Case of Elegant Bribery by Jia Guo See On Getting Paid From China. Is There Really A $50,000 Yearly Limit? from China Law Blog and Bitcoins: Made in China [↩]
It is unclear how much hashrate they actually operate or control, a challenge that plagues the entire cloudhashing industry leading to accusations of fraud. [↩]
And this is also a fundamental problem with public goods, there are few mechanisms besides social pressure and arbitrary decision making to ration resources. As described in (Evans 2014), since miners are the sole labor force, they create the economic outputs (bitcoins) and security, it is unclear why they are under any expectation to return fees in a network purposefully designed to reduce direct interactions between participants. See Economic Aspects of Bitcoin and Other Decentralized Public-Ledger Currency Platforms by David Evans [↩]
In 2014 the state of New Jersey sued a MIT student, Jeremy Rubin, for creating a web-based project that effectively does the same thing as the silicon-based version proposed by 21inc. See Case Against Controversial Student Bitcoin Project Comes to Close from CoinDesk. In addition, the FTC, in its case against Butterfly Labs also looked at BFL not informing customers properly regarding difficulty rating changes. According to the FTC’s new release on this case: “A company representative [BFL] said that the passage of time rendered some of their machines as effective as a “room heater.” The FTC charged that this cost the consumers potentially large sums of money, on top of the amount they had paid to purchase the computers, due to the nature of how Bitcoins are made available to the public.” [↩]
This issue was cited in the CryptoNote whitepaper as one motivation for creating a new network. On p. 2: “This permits us to conjecture the properties that must be satisfied by the proof-of-work pricing function. Such function must not enable a network participant to have a significant advantage over another participant; it requires a parity between common hardware and high cost of custom devices. From recent examples , we can see that the SHA-256 function used in the Bitcoin architecture does not possess this property as mining becomes more efficient on GPUs and ASIC devices when compared to high-end CPUs. Therefore, Bitcoin creates favourable conditions for a large gap between the voting power of participants as it violates the “one-CPU-one-vote” principle since GPU and ASIC owners possess a much larger voting power when compared with CPU owners. It is a classical example of the Pareto principle where 20% of a system’s participants control more than 80% of the votes.” [↩]
I would like to thank Ayoub Naciri for providing this example. [↩]
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.
[Note: Below is a guest post from Ernie Teo, a post-doctorate researcher at SKBI (where I am currently a visiting research fellow). It is referenced in a new paper covering the distorted incentives for securing public blockchains.]
Integrating, Mining and Attacking: Analyzing the Colored Coin “Game”
By Ernie G. S. Teo, Sim Kee Boon Institute for Financial Economics,
Singapore Management University
The research in this post came about when Tim Swanson invited me to look at colored coin providers and their incentives from a game theory perspective. The results are based on a number of phone conversations with Tim; I would like to take the opportunity to thank Tim for his insights on the matter. For an introduction to what colored coins are, refer to Chapter 3 in Great Chain of Numbers.
The initial question Tim wanted to know was if colored coins can be identified will miners charge excessively high fees to include these transactions. The led to a discussion of the possibilities of the colored coin issuer becoming a miner; and of an attack on the network to take control of the colored assets.
The problem proved to be very interesting as there could be many implications on the success of the system given the potential costs and benefits. Entities or players within the “game” could strategically choose to sabotage themselves if the incentives were right. In this post, I will attempt to explain this using a “sequential game” format. I will explain the various stages where choices can be made and the players involved in each stage. This will be followed by an analysis of the various outcomes and the strategic choices of each party given the incentives involved.
Before we start, I would like to disclaim that the model that follows is a simplified version of the problem and helps us to think about the potential issues that could arise. They are based on various assumptions and in no way should the results be taken at face value.
Stage 1: Before the colored coin issuer (CCI) starts operations, we assume that they will consider if they will choose to become a miner (Assuming that they can include their own transactions into blocks if no one else would). The decision maker (or player) here is the CCI, the choices available are to integrate or to not integrate.
Stage 2a: When the CCI starts issuing colored coins, it would have to decide on the fees it would pay for the transaction. We assume that the CCI is a rational entity and will choose the optimal fees. However as there are two possibilities in stage 1, there will be 2 possible fees quoted; one for a CCI whom is also a miner (integrated) and another for a CCI whom is not a miner (non-integrated). The decision maker here is the CCI and the choice is the fee quoted.
Stage 2b: This is immediately followed by the miners deciding to include the transaction in the block or not. For simplicity’s sake, we assume that there is only one miner in this game (this can be the CCI). The decision maker here is the miner and the choice is to mine the transaction or not.
If the decision in Stage 2b is not to mine, the game ends (End 1).
Stage 3: We next assume that the miner can choose to fraudulently attack the system and transfers the colored coin to itself. The decision maker here is still the miner and the choice is to attack or not.
This gives us 2 alternative endings (End 2 and End 3). The game can be described by Figure 1.
Figure 1: The stages of the “game”
If we consider the game, there are only 2 decision makers or players: The CCI and the miner. Next, we consider what are the possible outcomes or payoffs for each possible ending described above. This is described in Figure 2 below, there are actually 6 possibilities as there are 2 types of CCIs, integrated and non-integrated. When there is integration, there is really only one player.
Figure 2: Payoffs of the game
Having setup the game and determined the payoffs, we analyze the possibilities of each outcome. This is subject to the comparative magnitude of each payoff. Let’s start with the non-integrated outcomes, there are 3 possibilities:
Not Integrated. Mined. Attacked.
Not Integrated. Mined. Not Attacked.
Not Integrated. Not Mined.
An attack happens if M3>M2 (this will happen if the net benefit of the attack is positive).
If M3>M2, the transaction will be mined if M3>M1. This is because the miner expects the attack to take place, the miner will thus only mine the transaction if it the payoff from mining and attacking is better than not mining. Since we assumed that M1=0, M3 will be always larger than M1. Thus When M3>M2, mining always takes place and an attack happens.
If M2>M3, the attack will not happen (this would indicate that the net benefits of the attack is negative). The transaction will be mined if M2>M1 or if the transaction fees are positive.
The transaction will not be mined if M1≥M2. Since M2 (the transaction fee) has to be at least zero, if M2=0, the transaction will not be mined.
To summarize, there are 3 scenarios:
M3>M2≥M1: The transaction is mined and an attack takes place. The CCI gets CC3NI.
M2>M3 and M2>M1: The transaction is mined and an attack will not take place. Note that the inequality between M1 and M3 does not matter for this outcome. The CCI gets CC2NI.
M1≥M2>M3: The transaction is not mined. The CCI gets CC1NI.
In stage 1, the CCI is making the decision to integrate. To analyze this, we need to compare the non-integrated outcomes with the integrated ones. We thus have to look at the integrated outcomes first before we discuss stage 1. The outcomes are:
Mined. Not Attacked.
An attack happens if CC3I>CC2I. (This again will happen if the net benefit of the attack is positive).
If CC3I>CC2I, mining will occur if CC3I>CC1I. Similar to the non-integrated case, CC3I is always larger than CC1I . In fact this case is stronger as CC1I is at most zero and is likely to be negative as it is a cost. Thus if the CCI is willing to launch an attack against itself, it will definitely mine the transaction.
If CC2I>CC3I, no attack happens. For mining to occur, CC2I≥CC1I (the CCI will prefer to mine if they are indifferent). CC2I will always be larger than CC1I unless mining fees are zero (in which case it is equal), mining will always occur if CC2I>CC3I.
For mining to not occur, CC1I>CC2I or CC1I>CC3I needs to hold. To summarize, there are 3 scenarios:
CC3I>CC2I and CC3I>CC1I: The transaction will be mined and an attack occurs. CC3I is the final payoff.
CC2I>CC3I and CC2I>CC1I: The transaction is mined and no attack happens. CC2I is the final payoff.
CC1I>CC3I (we had determined that CC1I>CC2I could not be possible): No mining occurs. CC1I is the final payoff.
Note that we have determined that mining will always occur if the CCI chooses to integrate. Thus there are only 2 relevant scenarios instead of the 3 found in the non-integrated case. The main assumption is that the CCI miner will be able to get its transaction included on the blockchain; this could be either because it is the only miner or it has invested in sufficient computing resources to ensure it.
There are a total of 9 combinations of events detailed in Figure 3. Figure 3 also shows the conditions required for integration to occur under each scenario.
Figure 3: Analyzing the Integration Choice.
Figure 2: Payoffs of the game
Referring back to figure 2, we can make the following assumptions:
CC1NI is always larger than CC1I
CC2NI is always larger than CC2I
CC2NI is always larger than CC1I
Thus the 3 inequalities highlighted in red in Figure 4 are never possible, no integration will occur in scenario B+E, B+F and C+F.
In the other 6 scenarios, integration could occur given the right conditions. We can make some predictions on what is likely to occur.
In all scenarios with event A (A+D, A+E and A+F) where the non-integrated miner attacks, it is likely that the CCI prefers to integrate.
In scenario B+D, there are two possibilities. If the cost of attack is large, the CCI will not integrate. Otherwise, it will integrate and reap the benefits of launching an attack on itself.
When event C occurs and no integration takes place, the transaction will not be mined and the CCI gets nothing. Integration will thus occur as long as the cost of integration is small enough. This will be relevant for scenario C+D and C+E as we has ruled out C+F earlier.
One may ask if the CCI would want to attack itself. Well, if the benefit of attacking is large, a colored coin issuer may want to attack the network to derive a onetime benefit even though the company will never be trusted afterwards. However, this is unlikely as the cost of integration has to be extremely large for the CCI to be able to successfully attack the network.
Finally to answer our initial question, let us consider the issue of whether a non-integrated miner (in the event that a colored coin transaction can be identified) will force the CCI to quote high fees in order to get the transaction included. This is only relevant in the scenarios where the CCI initially chooses not to integrate. However, if colored transactions can be identified, miners can choose not to include these transactions unless the transaction fees are high enough. The fee can only be so high that it does not force the CCI to choose integration instead. In general, we can say that this fee cannot be higher than the cost of integration (this would refer to the per transaction cost of integration on average).
Based on this “game”, will colored coins be able to exist on a network such as Bitcoin? If colored transactions can be identified, there could be 2 issues. 1. The colored assets are so valuable that the non-integrated miner would want to attack the system, 2. The fees do not incentivized non-integrated miners to include the transactions. To overcome these issues the CCI could chose to integrate (or become a miner with sufficient computing power to be able to ensure that its transactions gets recorded). However, if the cost of doing so is too high to be justifiable, the CCI is better off not operating at all.