Fenix Bitcoin

Click here for cryptocurrency Links

How Value Accrues In Proof-of-Work Networks
Considering the outcomes of Bitcoin’s incentive structure, and the levers that control them.
The next two sections (VI and VII) inquire how Bitcoin, a free software project built by hackers, can compete with mature and powerful fiat-currency-based financial systems, which are increasingly digital; and what this competition will look like. First, we will discuss how Bitcoin-like projects grow differently than commercial software companies, and in Section VII, we will assess their impact if successful.

What qualities cause cryptocurrency systems to grow in value?
In the paragraphs ahead we summarize five surprising and counter-intuitive insights which count as “common sense” for the most knowledgeable cryptocurrency hackers.

We have established that free, open source software, built in New Jersey style, has rapidly outstripped commercial competitors at the foundations of the Web. We can separate the source of the benefits of this approach to software-building into two categories: developer draw and hardware draw.

1. Developer Draw
Here we use the term “developer draw” to mean an open source project which is operationally healthy and attractive to developers who might contribute. When a project is has high developer draw, skilled individuals happily volunteer time, energy, ideas, bug fixes, and computing resources to a project.

Satoshi Nakamoto envisioned Bitcoin as a platform for private economic activity, maintained by loose groups of volunteers. Platforms are most useful when they are stable. Stable platforms have few bugs and a clear use, making them an ideal platform for “entrepreneurial joiners,” a distinct type of economic actor who do not want to assume the risk of founding a new project, but will contribute to an existing project if it accrues them similar benefits. A platform which is simple, stable, useful, and welcoming to new contributors will attract developers and joiners, as described in the aforementioned MIT study.

Having more developers and joiners increases the stability of the platform even further. The thesis that "given enough eyeballs, all bugs are shallow,” is known as Linus's Law after the creator of Linux. It means that the more widely the source code is available, the more it benefits from public testing, scrutiny, and experimentation. These activities result in stable software.

In a private company building proprietary code, the momentous task of debugging falls on the few developers that have access to the codebase. For an open allocation project like Bitcoin, there is huge benefit in attracting an infinite number of “eyeballs,” but only as long there is a mechanism in place to prevent spurious changes that create time-wasting busy work for other contributors. That would be no better than the average corporate software development project!

Bitcoin’s incentive system allows the best of both worlds. Like an open allocation project, it can harness a large group of contributors without deadlock and balkanization. Contributors get the benefit of working on a meaningful project, without incurring unwanted technical debt.

Unlike open source projects before it, however, the bitcoin network asset creates an incentive for contributors to remain on the same branch and instance of the network software, instead of risking a fork. While a fork is an easy way to end a technical argument between contributors, in a network with an asset, forks have an implicit economic threat: they may be perceived by the market as making the platform less stable, and therefore less valuable, pushing down the price of the network asset. Like a commercial company, Bitcoin’s organizational structure incentivizes contributors to work out their differences and keep the group intact, for everyone’s financial gain.

Thus, Bitcoin is the first free, non-commercial software project with the intensity of a commercial product. Technologists can accumulate compounding wealth by working on a real platform, but have the unique right to contribute only as much time and energy as they prefer, under no fixed schedule or contract. Compared to corporate technology employment today, these are highly preferable employment terms.

2. Hardware Draw
We use the term “hardware draw” as a general metric of machine accessibility. Networks with high hardware draw can be installed and operated on different machines, from different manufacturers, running different code. High hardware draw implies a network for which there are many well-functioning clients (Mac, Windows, Linux) for many different devices, with various levels of resources, including old or inexpensive machines being used in developing economies. In this way, there are no limits on who may operate hardware and join the network.

The concept of hardware draw has its roots in New Jersey style viral software, which prioritizes low resource use, so as to be compatible with many older or cheaper computers (emphasis added):

“The worse-is-better philosophy means that implementation simplicity has highest priority, which means Unix and C are easy to port on such machines. Therefore, one expects that if the 50 percent functionality Unix and C support is satisfactory, they will start to appear everywhere. And they have, haven't they? Unix and C are the ultimate computer viruses.”

In Bitcoin, transactions contain small amounts of data, and its blockchain grows slowly. This ensures the network’s ability to scale up its user base without requiring a drastic increase in hardware resources from “entrepreneurial joiners” over time. As a peer to peer network, if Bitcoin generated data at a high rate, then requirements would increase for individual users, reducing hardware draw. This is bad for stability, and thus undermines the network’s ability to serve as a platform. Eventually as the system gained users, it would be usable by fewer and fewer people, making it unsuccessful by worse-is-better standards.

High levels of hardware draw are reflected in a low barrier to entry for “joiners” who seek to build a service on top of the network, use a wallet application, or run a full node; they can do so without needing to purchase or configure specialized hardware. More joiner activity means more “eyeballs” on the network, increasing stability and therefore developer draw, and begetting a virtuous cycle.

Conversely, a system which starts out with low hardware draw—requiring fast, expensive computers to run—may never reach an adequate population of users:

“Once the virus has spread, there will be pressure to improve it, possibly by increasing its functionality closer to 90 percent, but users have already been conditioned to accept worse than the right thing. Therefore, the worse-is-better software first will gain acceptance, second will condition its users to expect less, and third will be improved to a point that is almost the right thing.”

Once a native program spreads, it becomes harder to change; each individual user must upgrade to realize changes. Furthermore, an over-reliance on upgrading the software later will result in technical debt, as some users fail to upgrade, and developers feel pressure to continue to support these old versions of the software.

Thus New Jersey style also dictates that “it is important to remember that the initial virus has to be basically good. If so, the viral spread is assured as long as it is portable.“ Comments from Nakamoto on June 17, 2010, imply that the challenge of Bitcoin was designing a network which would have high developer draw, and high hardware draw, but still achieve “functionality closer to 90 percent” of what people would want in a currency system right off the bat:

“The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met... Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them... The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc. If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.”

This uncompromising (but somewhat extensible) design rationale makes Bitcoin viral and also useful to a broad base of potential users.

Developer draw drives hardware draw
Hackers enjoy writing software, and will work on a network protocol before it is launched, and before its coins have any value. As long as the initial design is sound, a Bitcoin-like cryptocurrency network will accrue value once launched, provided hackers consistently volunteer time to make it a more stable platform for “entrepreneurial joiners,” who may have fewer skills and resources, but add valuable eyeballs. Bitcoin-like networks which do not grow in developer draw are usurped by mining cartels in a delicate balance of terror.

This means that in projects where developer draw is high, diverse contributors improve the underlying system, building and testing client applications on a broad base of hardware and software platforms. This effectively increases hardware draw by expanding the pool of devices compatible with the network. Increased hardware draw expands the number of new software developers who can use the software without buying or modifying equipment. This virtuous cycle begins with developer draw.

Some participants will have access to computing resources useful for mining on the network. Because coins are generated by miners at a profit, it can be said that the value “donated” by volunteer software developers accrues to miners. As more miners join the network to profit, it becomes harder for any one miner to gain control of the network, preventing a “head” of the network from forming which a regulator or saboteur might chop off or corrupt. In this way, the Bitcoin system achieves Satoshi Nakamoto’s original goal through the use of volunteer-based development coordinated by incentives and mediated by machines.

The enrichment of miners is a trade-off which is acceptable to the contributors only when they enjoy the contribution. If contributions are difficult or unpleasant, developer draw drops. Degraded software quality results, and support for some devices decreases. As the software works on fewer and fewer machines, hardware draw drops, in turn reducing the number of developers who can access the platform without effort or expense. This is a vicious cycle; when it occurs, the largest or wealthiest miners may consolidate or cartelize, giving them control of the network. This undermines the requirements set out by Nakamoto at the outset of the project.

Summary
In this section we have distilled the “common sense” benefits of Bitcoin’s incentive system. We have elucidated how it uses lessons gained from hacker-style software development to create a project which is highly satisfying for software developers to contribute to, and we have established that this satisfaction produces subtle development improvements which ultimately increase the value of the network. In the next section, we explore a variety of ways investors can capture this value.