[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(n²).3

O(n²) 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(n²) scaling.67

What does this have to do with watermarked tokens?

As described in (Breitman 2015c):8

[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.

1. See A Survey and Comparison of Peer-to-Peer Overlay Network Schemes by Lua et al. p. 10 and Big-O scaling by Gavin Andresen [↩]
2. 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). [↩]
3. Why do people say that bitcoin scales according to O(n^2)? from StackExchange [↩]
4. I would like to thank Richard Brown for this example and illustration. [↩]
5. Block Size Increase from BitFury Group, p. 5 [↩]
6. See p. 9 from Ripple Protocol Consensus Algorithm Review by Peter Todd [↩]
7. Surveying literature we can see that historically there have been dozens of attempts to create decentralized peer-to-peer reputation systems that needed to be self-organizing, Sybil-resistant, fault tolerant as well as the ability to scale. A Survey and Comparison of Peer-to-Peer Overlay Network Schemes by Lua et al.; A Survey of Attack and Defense Techniques for Reputation Systems by Kevin Hoffman, David Zage and Cristina Nita-Rotaru; and Survey of trust models in different network domains by Mohammad Momani and Subhash Challa [↩]
8. Making sense of colored coins by Arthur Breitman [↩]
9. Ibid [↩]