We take “decentralized” to have a stronger meaning than “distributed”: decentralized systems are a subset of distributed systems that lack any central authority. A close synonym for “decentralized” is “peer-to-peer” (P2P).

Removing central authority creates several advantages. Decentralized systems grow quickly because they lack barriers to entry—anyone can grow the system by simply running a new node, there is no requirement for registration or approval from a central authority. Because all nodes are the same, decentralized systems are more robust than distributed systems.

Decentralized systems are also difficult to capture, regulate, tax, or surveil because they lack centralized points of control for governments to subvert. This is why peer-to-peer networks were an inspiration for Satoshi’s design of bitcoin.

Governments are good at cutting off the heads of…centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own. [Nakamoto, 2008]

But these strengths come with significant weaknesses.  Decentralized systems can be less efficient as each node must additionally bear responsibilities for coordination previously assumed by the central authority.  Browsing the Internet with Tor is slower than browsing it without.

Decentralized systems are also plagued by scammy, adversarial behavior.  Despite Satoshi’s nod to Gnutella, anyone who’s used a P2P file sharing program to download a file that turned out to be something gross or malicious understands the reasons that P2P file sharing never became the mainstream model for data transfer online.  Satoshi didn’t name it explicitly, but email is another decentralized system that has evaded government controls.  And email is similarly notorious for spam.

The root problem, In all of these cases, is that adversarial behavior (seeding bad files, sending spam emails) is not punished and cooperative behavior (seeding good files, only sending useful emails) is not rewarded.  Decentralized systems fail when they rely upon their participants to be good actors because they cannot prevent bad actors from also participating.

Without imposing a central authority, the only way to solve this problem is to use economic incentives. Successful decentralized systems must ensure that cooperative behavior is profitable and adversarial behavior is costly.  Good actors, by definition, play by the rules because they’re inherently motivated to do so.  Bad actors are, by definition, selfish, but proper economic incentives can redirect selfish behavior towards the common good.

Because of deep connections between mathematics, physics, and computer science, the computations required to produce proofs-of-work cost real-world energy and hardware resources – they cannot be faked.  Since real-world resources are scarce, proofs-of-work with high computational costs are also scarce.

Furthermore, the correctness and expected computational cost of a given proof-of-work can be (cheaply) verified by anyone without reference to a central authority.  Proofs-of-work are, to use Nick Szabo’s phrase, “unforgeable costliness”, directly legible to all participants in a decentralized system.

Dwork & Naur proposed limiting the abuse of a shared resource by forcing participants to provide proofs-of-work with an adjustable difficulty.  Dwork & Naur describe the difficulty as a “pricing function” because, by adjusting it, a “pricing authority” could ensure that the shared resource remained cheap to use for honest, average users but expensive for users seeking to exploit it.

In an email network the system administrator could serve as the pricing authority, setting a difficulty for sending email which corresponded to a trivial amount of computation for an average user’s computer but was too expensive in real-world cost for a spammer to send thousands of emails.

Dwork & Naur described proofs-of-work as an economic disincentive to combat resource abuse:

In this paper we suggest a computational approach to combatting the proliferation of electronic mail. More generally, we have designed an access control mechanism that can be used whenever it is desirable to restrain, but not prohibit, access to a resource. [Dwork & Naur, 1993]

Yet the nomenclature “pricing function” and “pricing authority” supports the market interpretation.  Users are purchasing access to a resource in exchange for proofs-of-work at a price set by the resource’s controller.  

In this interpretation, a decentralized email network is really a market trading email delivery for proofs-of-work.  Proofs-of-work are the currency of this market, the currency in which the price of email delivery is denominated.

This is a difficult problem.  The entire history of digital currencies, beginning with Dwork & Naur’s 1993 work, and culminating in Satoshi’s 2008 white paper, was a series of increasingly sophisticated attempts at building a functioning currency starting from proofs-of-work.

The challenge arises because currencies are complex systems.  Unlike proofs-of-work, currencies require monetary policy, issuance & ownership models, a ledger of transactions, &c.  The units of a currency must be fungible with each other and of equal value at the same time.

Yet decentralized systems are markets, so all these basic functions of a currency must somehow be provided through market forces, through the exchange of goods.  Like compiling the first compiler, a black start of the electrical grid, or the evolution of life itself, we’re confronted with a bootstrapping problem: we must define the economic incentives that create a functioning currency without having a functioning currency in which to denominate those incentives.

Progress comes from recognizing that we only have two kinds of goods in a decentralized system. The first kind are proofs-of-work and the second kind are units of the currency we’re trying to build. The only market exchange possible must therefore be between these two goods.  Proofs-of-work must be sold for units of currency or, equivalently, units of currency must be sold for proofs-of-work.

This framing is crucially different from the usual claim that “digital currency is created through proof-of-work”, so let’s repeat it.  Currency isn’t created through proof-of-work, currency is created through consensus.  Currency is exchanged for proof-of-work in a decentralized market.

Exchanging currency for proof-of-work is the structure of the decentralized market but what are its semantics?  What real-world value do the network and its users obtain from buying proofs-of-work?  What market services are being provided by the creators of the proofs?

The answer must be: the capabilities of a functioning currency.  The market for proofs-of-work must bootstrap the initial issuance and ongoing transaction capabilities of the currency it itself settles in.

A major function of markets is price discovery.  A market for proofs-of-work must assign a value to computations.

We don’t typically assign monetary value to computations. We typically value the capacity to perform computations because we value the output of computations, not the computations themselves. If the same output can be performed more efficiently, with fewer computations, that is usually called progress.

Proofs-of-work are specific computations whose only output is proof that they were performed.  Performing the same work with fewer computations would be called a bug.  Proofs are thus a strange and novel good to attempt to value (but so are novel currencies).

When proofs-of-work are thought of as merely disincentives against resource abuse, it is not necessary to value them precisely or consistently. All that matters is that difficulties are low enough to be unnoticeable for legitimate users yet high enough to be prohibitive for spammers. There is thus a broad range of acceptable “prices” and each participant (e.g. a peer in an email network) acts as their own pricing authority, applying their own pricing function.

But units of a currency are meant to be fungible, each having the same value. Due to changes in technology over time, two units of currency created with the same proof-of-work—as measured by number of expected computations—may have radically different real-world costs of production, as measured by the required investment in time, energy, and/or capital. When proof-of-work is sold for currency, and the underlying cost of production is variable, how can the market ensure a consistent price?

Nick Szabo clearly identified this pricing problem when describing bit gold:

The main problem…is that proof of work schemes depend on computer architecture, not just an abstract mathematics based on an abstract "compute cycle." …Thus, it might be possible to be a very low cost producer (by several orders of magnitude) and swamp the market with bit gold. [Szabo 2005]

The number of monetary units created is equal to the cost of the computing effort in terms of a standard basket of commodities. For example if a problem takes 100 hours to solve on the computer that solves it most economically, and it takes 3 standard baskets to purchase 100 hours of computing time on that computer on the open market, then upon the broadcast of the solution to that problem everyone credits the broadcaster's account by 3 units. [Dai, 1998]

Unfortunately Dai does not explain how users in a supposedly decentralized system are supposed to agree upon the definition of a “standard basket”, which computer solves a given problem “most economically”, or the cost of computation on the “open market”.  Achieving consensus among all users about a time-varying shared dataset is the essential problem of P2P systems!

To be fair to Dai, he realized this:

One of the more problematic parts in the b-money protocol is money creation. This part of the protocol requires that all [users] decide and agree on the cost of particular computations. Unfortunately because computing technology tends to advance rapidly and not always publicly, this information may be unavailable, inaccurate, or outdated, all of which would cause serious problems for the protocol. [Dai, 1998]

Dai would go on to propose a more sophisticated auction-based pricing function, one that was a direct inspiration for Satoshi’s design in bitcoin.  We will return to this auction scheme below, but first let’s turn to bit gold, and look at Szabo’s solution to the same problem.

Szabo’s solution begins with the claim that proofs-of-work should be “securely timestamped”:

The proof of work is securely timestamped.  This should work in a distributed fashion, with several different timestamp services so that no particular timestamp service need be substantially relied on. [Szabo 2005]

The phrases “securely” and “distributed fashion” are carrying a lot of weight here.  Szabo links to a page of resources on secure timestamping maintained by Helger Lipmaa, but nothing in that page or in Szabo’s description of bit gold provides an algorithm or code illustrating how nodes can arrive at a consensus timestamp for a given proof.  The general approach is, like Dai’s approach to measuring the cost of computation, hand-wavy and relies upon (many) “outside the system” services for consensus.

Regardless of implementation fuzziness, Szabo was right — the time a proof-of-work was created is an important factor in pricing it because it is related to the cost of production:

…However, since bit gold is timestamped, the time created as well as the mathematical difficulty of the work can be automatically proven.  From this, it can usually be inferred what the cost of producing during that time period was… [Szabo 2005]

“Inferring” the cost of production is important in bit gold because there is no built-in mechanism to restrict the supply of bit gold.  Anyone can create bit gold by performing proof-of-work.  Without the ability to regulate issuance, bit gold is a akin to a collectible:

…Unlike fungible atoms of gold, but as with collector's items, a large supply during a given time period will drive down the value of those particular items. In this respect "bit gold" acts more like collector's items than like gold… [Szabo 2005]

Bit gold requires an additional, external process to create fungible units of currency:

...[B]it gold will not be fungible based on a simple function of, for example, the length of the string. Instead, to create fungible units dealers will have to combine different-valued pieces of bit gold into larger units of approximately equal value. This is analogous to what many commodity dealers do today to make commodity markets possible. Trust is still distributed because the estimated values of such bundles can be independently verified by many other parties in a largely or entirely automated fashion. [Szabo 2005]

The dealers defining “larger units of approximately equal value” are providing a similar pricing function as Dai’s “standard basket of commodities”. Fungible units are not created in bit gold when proofs-of-work are produced, only later when those proofs are combined into larger units of “equal value” by dealers outside of the system providing a pricing function.

This is the third instance of a hand-wavy solution appealing to an “outside the system” consensus, in this case for how proofs-of-work should be bundled together into fungible coins of the same value. To his credit, Szabo recognizes this flaw:

…The potential for initially hidden supply gluts due to hidden innovations in machine architecture is a potential flaw in bit gold, or at least an imperfection which the initial auctions and ex post exchanges of bit gold will have to address. [Szabo 2005]

This is the third instance of a hand-wavy solution appealing to an “outside the system” consensus, in this case for how proofs-of-work should be bundled together into fungible coins of the same value. To his credit, Szabo recognizes this flaw:

Again, despite not having arrived at (what we now know as) the solution, Szabo was pointing us at it: because the cost of computation changes over time, the network must respond to changes in the supply of proof-of-work by adjusting the price of money.

Szabo’s dealers would have been an out-of-system market that defined the price of (bundles of) bit gold after its creation. Is it possible to implement this market within the system, instead of outside it?

As mentioned earlier, Wei Dai proposed an alternative auction-based model for b-money:

So I propose an alternative money creation subprotocol, in which [users]…instead decide and agree on the amount of b-money to be created each period, with the cost of creating that money determined by an auction. Each money creation period is divided up into four phases, as follows:

[Dai, 1998]

B-money makes significant strides towards the correct structure for a market for proofs-of-work.  It attempts to eliminate external dealers and allow users to engage in price discovery by directly bidding against each other.  But implementing Dai’s proposal as written would be challenging:

Decentralized systems struggle to track data and make choices consistently yet b-money requires tracking prices from many users and making consensus choices among them.  This complexity prevented b-money from ever being implemented.

The root of this complexity is Dai’s belief that the “optimal” rate at which b-money is created should fluctuate over time based on the “macroeconomic calculations” of its users.  Like bit gold, b-money has no mechanism to limit the creation of money!  Anyone can create units of b-money by broadcasting a bid and then doing the corresponding proof-of-work.

Both Szabo and Dai proposed using a market for proofs-of-work to implement a currency yet neither bit gold nor b-money defined a monetary policy to regulate supply within this market.

In contrast, a sound monetary policy was one of Satoshi’s foremost goals for bitcoin.  In the very first mailing list post where bitcoin was announced, Satoshi wrote:

The root problem with conventional currency is all the trust that's required to make it work. The central bank must be trusted not to debase the currency, but the history of fiat currencies is full of breaches of that trust…[Satoshi 2009]

Satoshi would go on to describe other problems with fiat currencies such as risky fractional reserve banking, a lack of privacy, rampant theft & fraud, and the inability to make micropayments.  But Satoshi started with the issue of debasement by central banks – with monetary policy.

Satoshi wanted bitcoin to ultimately reach a finite circulating supply that cannot be diluted over time.  The “optimal” rate of bitcoin creation, for Satoshi, should thus eventually be zero.

This monetary policy goal, more than any other characteristic they personally (or collectively!) possessed, was the reason Satoshi “discovered” bitcoin, the blockchain, Nakamoto consensus, &c. – and not someone else.  It’s the short answer to the question posed in the title of this article: Satoshi thought of bitcoin because they were focused on creating a digital currency with a finite supply.

Finite supply is not only a monetary policy goal or a meme for bitcoiners to rally around.  It’s the essential technical simplification that allowed Satoshi to build a functional bitcoin implementation while Dai’s b-money remained just a fascinating web post.  Like many technical simplifications, it worked by reducing scope.

Ensuring all nodes deterministically calculate the same subsidy ensures that the supply of bitcoin matches its predetermined monetary policy.  It’s also relatively straightforward to implement (compared to the deterministic difficulty, below).

The simplest choice Satoshi could have made would have been to set a constant subsidy, say 50 BTC. Each bitcoin block (Dai’s “money creation period”), the network would create exactly 50 BTC, forever.  This simple choice is trivial to implement but fails to meet Satoshi’s requirement that bitcoin have a finite ultimate supply.  Needless to say, Satoshi rejected this option.

The next simplest choice is for the network to create some predetermined number of bitcoin in each block until the total planned supply is reached – and then stop.

Adopting this choice changes the semantics of bitcoin’s market for proofs-of-work.  The bitcoin being paid to miners for their proofs-of-work is not bitcoin that is newly created, it’s bitcoin that is distributed from an existing supply:

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. [Nakamoto, 2008]

Satoshi wanted a strong monetary policy but, bitcoin being a decentralized system, there was no central authority to appeal to for this strength.  Instead Satoshi chose to hard-code these rules into software.  By choosing to run the Bitcoin Core software, users are voluntarily endorsing Satoshi’s monetary policy.  This is reflected by their nodes each executing an identical algorithm for determining the bitcoin subsidy at a moment in time.

Dai jumped right past this simple solution to a more complex (and impractical) model because he was not focused on a finite supply or a sound monetary policy.

The deterministic subsidy algorithm above ensures that, at a given time, all nodes in the network are selling the same “tranche” of bitcoin from the existing supply.  How does the network ensure that all nodes demand the same price (in proof-of-work computations) for each tranche?

Again, the simplest choice, of setting a fixed network difficulty, was rejected by Satoshi.  As computing hardware or the supply of proof-of-work increased, a fixed difficulty would lead to blocks being produced faster and faster.

In bit gold and b-money, this accelerating pace of money creation is not necessarily a problem because the supplies of bit gold and b-money are unlimited.  In response to an increasing supply of proof-of-work, bit gold’s “dealers” would simply adjust the price of fungible “bundles” of bit gold.  B-money’s users would (somehow) collectively agree that the “optimal” price of new b-money should be raised.  Regulating the rate of money creation over time was not a major concern of either project.

But bitcoin’s market is based upon a predetermined monetary policy.  The subsidy algorithm ensures that 21M bitcoin will be distributed through the market for proofs-of-work in a fixed sequence of tranches.  But the rate of distribution of this supply matters greatly to the way the market should value each tranche.  21M bitcoin created over 130 years is a very different value proposition than 21M bitcoin created over 130 days.

In a sense, the bitcoin network must ensure that a shared resource—the finite, existing supply of bitcoin—is not distributed too quickly.  In the spirit of Dwork & Naur’s “Pricing via Processing”, the bitcoin network acts as its own price authority, adjusting the difficulty so that rapid increases in proof-of-work supply do not create a corresponding supply glut of bitcoin.

Satoshi makes the simplest choice of having the bitcoin price authority adjust difficulty so that blocks are produced at a constant rate, given market demand:

To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases. [Nakamoto, 2008]

This “difficulty adjustment algorithm” can be thought of as a mixture of an English & Dutch auction where the auctioneer (a set of deterministic algorithms run by all network participants identically) adjusts the price up or down so as to keep the rate of purchasing constant.

But telling time in a decentralized, adversarial system is not trivial.  It requires the bitcoin network to become the “secure timestamping protocol” Szabo required for bit gold.

Such protocols required publishing timestamps into shared public resources (typically thought of as Usenet posts or newspapers) so they can be widely copied and referenced.  The subsidy algorithm already required all users to have the same number of blocks.  Additionally including timestamps in these blocks allows them to become the public resource required by the secure timestamping protocol.  By including these timestamps, users are adding another market requirement to blocks beyond having sufficient proof-of-work: new blocks must also be timestamped close to the current time.

These intricacies are why Satoshi describes bitcoin as first and foremost a “distributed timestamp server on a peer-to-peer basis” [Nakamoto 2008] and why early implementations of the bitcoin source code use the world “timechain” rather than “blockchain” to describe the shared data structure that implements bitcoin’s proof-of-work market.

In the preceding sections we established that bitcoin nodes can independently calculate the same subsidy and difficulty target only if the network can guarantee that each has the same set of blocks.

This block-ordering problem is an instance of the more general problem of consensus, also known as the “Byzantine generals” or “double-spend” problem.  Sharing an identical sequence of data among all network participants is challenging inside an adversarial, decentralized network.  Existing solutions to this problem – so-called “Byzantine-fault tolerant (BFT) consensus algorithms” – require advanced knowledge of all participants or a supermajority (>67%) of participants to not behave adversarially.

In b-money, which suffers from the same block ordering problem, each participant must keep track of multiple users’ proposed prices as well as choose only the proofs-of-work corresponding to the “highest” prices.  The complexity of this order book makes b-money impossible to implement.

Bitcoin solves this problem by taking deterministic pricing seriously. In bitcoin, there is only one price—the consensus, deterministic price set by all network participants identically—and any (valid) block a node sees is immediately considered settled.  Order matching for the market of bitcoin blocks is thus trivial.  The order book for bitcoin blocks has zero complexity.

The happy consequence of each node greedily accepting the first block it sees that meets the current network requirements is that all nodes will provably converge on consensus about the sequence of blocks. Building a market for timestamped proofs-of-work results in a novel BFT consensus algorithm!  Moreover, this new “Nakamoto consensus” algorithm only requires 50% of participants to not be adversarial, a significant improvement on the state of the art.

Satoshi made this breakthrough, instead of a computer scientist at a traditional academic research group, because of their extreme focus on a sound monetary policy to back a digital currency, rather than a generic consensus algorithm for distributed computing.

To turn this money-distribution-market-cum-consensus-algorithm into a functioning currency, Satoshi needed a way to describe transactions that could transfer bitcoin between users.

Here Satoshi was able to mostly incorporate prior work on transactions as chains of digital signatures.  But by including transaction data inside of blocks, transactions would gain the double-spend protections of Nakamoto consensus that were lacking in prior projects such as bit gold and b-money.

The additional step of including fees in transactions, also paid to the winning miner, ensures that the market of bitcoin for timestamped proofs-of-work continues to operate even as the rate of bitcoin being distributed for sale gradually decreases and reaches zero.

To incentivize this behavior, Satoshi ensured that the inclusion of transactions in blocks is itself a second market within bitcoin.  Users must bid a certain amount of sats/vbyte when they broadcast transactions to the mempool and miners collectively have an “ask”—the current “fee rate”.

While superficially similar to the “primary” market of bitcoin for proofs-of-work, the “secondary” transaction market is actually subtly different.  The primary market is between Bitcoin, the network, and miners.  Bitcoin is paying miners for timestamped proofs-of-work with newly distributed bitcoins.  The constraints that drive scarcity in the primary market are the finite supply of bitcoin and the fixed block time.  An auction model is used but the network offers a single consensus price to miners.  The data determining the state of this primary market is what we call the blockchain.

The secondary market is between individual bitcoin users and miners.  Bitcoin’s users are paying miners with previously distributed bitcoins to execute transactions with finality.  Finality in this secondary transaction market is provided by Nakamoto consensus in the primary market for money distribution.  The constraint that therefore drives scarcity is the block size.  An auction model is also used but bids are submitted individually, there is no consensus price for the inclusion of transactions in blocks.  The data determining the state of the secondary market is what we call the mempool.  The mempool only exists to serve the secondary market – it is not required for the primary market.

The primary market can operate independent of the secondary market—witness miners who mine blocks with zero transactions in them (other than the coinbase).  But the secondary market cannot exist without the primary market because the secondary market relies upon the primary market for settlement: transactions are removed from the mempool when they enter the blockchain.

As a result, the size and complexity of the order book for transactions – the mempool – is small but nonzero.  Yet, other than the basic P2P gossipping that shares transactions among nodes, bitcoin does not force any particular consensus requirements for the mempool.  Unlike the blockchain, where any local differences between nodes are quickly erased by convergence to a shared consensus, nodes are allowed to differ significantly in the contents of their mempools.

The secondary transaction market also implements semantics which are unnecessary for the primary money distribution market.  Almost the entirety of the Script instruction set is to enable the business logic of transactions in the secondary market – the primary market “only” needs to be able to credit newly distributed bitcoin to the public key of the winning miner.

Yet, in order to protect against misuse, the primary market must have some awareness of the semantics of the secondary market – valid blocks in the primary market must contain only valid transactions in the secondary market.  This coupling between market layers allows the validity of transactions in the secondary market (mempool) to be quickly determined.  This means users aren’t just paying for timestamped proofs-of-work, they’re paying for timestamped proofs-of-work which additionally respect the semantics of Bitcoin Script in any included transactions.

Of course, without the secondary market, the primary market would collapse. A system that rewards miners with coins that they don’t or cannot spend would not have been sustainable.  When bitcoin first launched and there was no secondary market usage, the primary market did not grow.  For the first year of bitcoin’s history, it’s likely that Satoshi was the only miner (the first upward difficulty adjustment wasn’t even triggered until February 14th, 2010).

The secondary market can also affect incentives and therefore the function of the primary market.  The rules of the secondary market prohibit bitcoin credited to miners from being spent (transferred in the secondary market) for 100 blocks (most of a day).  This reduces the chance that recently created UTXOs are spent in forks, improving the stability of the blockchain.

Thinking of bitcoin as layered primary and secondary markets foreshadows what the future of the bitcoin ecosystem must look like.  Layers of markets which build upon one another, lower layers providing capabilities for higher layers to build upon, higher layers constraining and  increasing the value of lower layers.

Following Satoshi’s thinking doesn’t make it any less original or remarkable.