Bitcoin’s origins

What hath Satoshi wrought?

An explanation of bitcoin’s origins; an exploration of its future.
Dhruv Bansal

Bitcoin is often compared to the Internet in the 1990s but I believe the better analogy is to the telegraph in the 1840s.

The telegraph was the first technology to transmit encoded data at near-light speed over long distances. It marked the birth of the telecommunications industry. The internet, though it is bigger in scale, richer in content, and many-to-many instead of one-to-one, is fundamentally still a telecommunications technology.

Both the telegraph and the internet rely upon business models in which companies deploy capital to build a physical network and then charge users to send messages through this network. AT&T’s network has historically transmitted telegrams, telephone calls, TCP/IP packets, text messages, and now TikToks.

The transformation of society through telecom has led to greater freedoms but also greater centralization. The Internet has increased the reach of millions of content creators and small businesses but has also strengthened the grasp of companies, governments and other institutions well-positioned enough to monitor and manipulate online activity.

But bitcoin is not the end of any transformation—it’s the beginning of one. Like the telegraph, bitcoin will change both human society and daily life. Predicting the full scope of this change today is akin to imagining the internet while living in the era of the telegraph. Understanding bitcoin’s long-term effects is only possible if we understand bitcoin.

In this piece, we will trace the history of digital currencies before bitcoin. Only by understanding where prior projects fell short can we perceive what makes bitcoin succeed—and how it creates a model for building the distributed internet of the future.

How did Satoshi think of bitcoin?

Sound monetary policy solved the double-spend problem.

Bitcoin was built on existing work in cryptography, distributed systems, economics and political philosophy. The concept of proof-of-work existed long before its use in money and prior cypherpunks such as Nick Szabo, Wei Dai, & Hal Finney anticipated and influenced the design of bitcoin with projects such as bit gold, b-money, and RPOW.

Consider that, by 2008, when Satoshi wrote the bitcoin white paper, the following ideas had already been proposed and/or implemented:

A few examples of wallets commonly used as “singlesig”

Bitcoin leverages all these concepts, but Satoshi didn’t originate any of them. To understand Satoshi’s contribution, as well as the success of bitcoin, we should determine which principles of bitcoin are missing from the above list.

Some obvious candidates are the finite supply of bitcoin, Nakamoto consensus, and the difficulty rebalancing algorithm.  But what led Satoshi to these ideas in the first place? 

Decentralized systems are markets

Bitcoin is often described as a decentralized or distributed system. Unfortunately, the words “decentralized” and “distributed” are frequently confused.

It’s common to illustrate the terms “centralized”, “distributed”, and “decentralized” using pictorial network diagrams.  But it’s more important to illustrate the different ways these systems enforce their rules.

It’s common to illustrate the terms “centralized”, “distributed”, and “decentralized” using pictorial network diagrams.  But it’s more important to illustrate the different ways these systems enforce their rules.

We’ll begin with a careful definition of these terms.  The conclusion we’re  that decentralized systems, lacking a central authority.

Distributed systems rely upon central authorities

In this work, we take “distributed” to mean any system that has been broken up into many parts (often referred to as “nodes”) which must communicate, typically over a network.

Software engineers have grown adept at building globally distributed systems.  The Internet is composed of distributed systems collectively containing billions of nodes.  We each have a node in our pocket which both participates in and relies upon these systems.

But almost all the distributed systems we use today are governed by some central authority, typically a system administrator, company, or government that is mutually trusted by all nodes in the system.

Central authorities ensure all nodes adhere to the system’s rules and remove, repair, or punish nodes that fail to do so. They are trusted to provide coordination, resolve conflicts, and allocate shared resources. Over time, central authorities manage changes to the system, upgrading it or adding features, and ensuring that participating nodes comply with the changes.

The benefits a distributed system gains from relying upon a central authority come with costs. While the system is robust against failures of its nodes, a failure of its central authority may cause it to stop functioning overall. The ability for the central authority to unilaterally make decisions means that subverting or eliminating the central authority is sufficient to control or destroy the entire system.

Despite these trade-offs, if there is a requirement that a single party or coalition must retain central authority, or if the participants within the system are content with relying upon a central authority, then a traditional distributed system is the best solution. No blockchain, token, or similar decentralized dressing is required.

In particular, the case of a VC- or government-backed cryptocurrency, with requirements that a single party can monitor or restrict payments and freeze accounts, is the perfect use case for a traditional distributed system.

Decentralized systems rely upon economics

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.

Proofs are the first kind of decentralized goods

Decentralized systems are markets, but building markets requires paying people!  How can a decentralized system actually affect economic outcomes?

Any coupling between a decentralized system and fiat money, traditional assets, or physical commodities would reintroduce dependencies on the central authorities that control payment processors, banks, & exchanges.  A decentralized system can’t create incentives using dollars while remaining decentralized; existing economic goods are illegible within decentralized systems.

Creating decentralized incentives requires new kinds of decentralized goods, goods which are directly addressable and transferable within decentralized systems.  The first such goods are “proofs-of-work”, first proposed in 1993 by Cynthia Dwork and Moni Naur.

A few examples of wallets commonly used as “singlesig”

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.  

A few examples of wallets commonly used as “singlesig”

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.

Currency is the second kind of decentralized good

Decentralized systems are markets, but building markets requires paying people!  How can a decentralized system actually affect economic outcomes?

Any coupling between a decentralized system and fiat money, traditional assets, or physical commodities would reintroduce dependencies on the central authorities that control payment processors, banks, & exchanges.  A decentralized system can’t create incentives using dollars while remaining decentralized; existing economic goods are illegible within decentralized systems.

Creating decentralized incentives requires new kinds of decentralized goods, goods which are directly addressable and transferable within decentralized systems.  The first such goods are “proofs-of-work”, first proposed in 1993 by Cynthia Dwork and Moni Naur.

Proof-of-work is the first decentralized good.  The second decentralized good is currency.  The first decentralized system implements this currency through a market for proofs-of-work.  A decentralized currency allows further decentralized markets to be implemented for other goods and services.  The development of decentralized systems must necessarily proceed in this sequence.  From this perspective, bitcoin is zero to one.

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.

A few examples of wallets commonly used as “singlesig”

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.

How do markets price proofs?

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]

A few examples of wallets commonly used as “singlesig”

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.

Proofs at the same time have the same cost

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.

A few examples of wallets commonly used as “singlesig”

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.

A few examples of wallets commonly used as “singlesig”

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.

Currency should be auctioned

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:

Planning. The [users] compute and negotiate with each other to determine an optimal increase in the money supply for the next period. Whether or not the [network] can reach a consensus, they each broadcast their money creation quota and any macroeconomic calculations done to support the figures.
Bidding. Anyone who wants to create b-money broadcasts a bid in the form of <x, y> where x is the amount of b-money he wants to create, and y is an unsolved problem from a predetermined problem class. Each problem in this class should have a nominal cost (in MIPS-years say) which is publicly agreed on.
Computation. After seeing the bids, the ones who placed bids in the bidding phase may now solve the problems in their bids and broadcast the solutions.
Money creation. Each [user] accepts the highest bids (among those who actually broadcasted solutions) in terms of nominal cost per unit of b-money created and credits the bidders' accounts accordingly.

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

In the “Planning” phase, users bear the burden of negotiating the “optimal increase in the money supply for the next period”.  How “optimal” should be defined or how users should negotiate is not clear.
Regardless of what was planned, the “Bidding” phase allows anyone to submit a “bid” to create b-money.  The bids include both an amount of b-money to be created as well as a corresponding amount of proof-of-work so each bid is really a price, the number of computations for which a given user is willing to sell a given amount of b-money for.
Once bids/prices are submitted, the “Computation” phase consists of bidders doing the work they bid and broadcasting solutions.  No mechanisms for filtering solutions to only those produced by bidders or for matching bidders to solutions is provided.  More problematically, it’s not clear how users should know that all bids/prices have been submitted – when does the “Bidding” phase end and the “Computation” phase begin?
These problems recur in the “Money Creation” phase.  Because of the nature of proof-of-work, users can verify the proofs they receive in solutions are real.  But how can users collectively agree on the set of “highest bids”?  What if different users pick different such sets?

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.

Satoshi’s monetary policy goals led them to bitcoin

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.

A few examples of wallets commonly used as “singlesig”

Bit gold and b-money granted users the freedom to affect the money supply.  Satoshi’s goal of zero “tail emission” and a finite supply suggested an obvious solution: eliminate this freedom.  Individual users cannot create bitcoin.  Only the bitcoin network can create bitcoin.  It does so through a predetermined monetary policy chosen by Satoshi and endorsed by each bitcoin user when they run the software.  The entire “Planning” phase of b-money’s auction model is done once, at the inception of the bitcoin project.

Using a predetermined monetary policy further reduces scope the “Bidding” phase.  Instead of tracking prices from individual users, the bitcoin network simply ensures that all nodes deterministically demand the same price at the same time.

At any given moment, all bitcoin nodes in the world agree on the price:

$ bitcoin-cli getblockstats 804716
{ ... “subsidy”: 6250000000, … } # 6.25 BTC
$ bitcoin-cli getdifficulty
{ "result": 55621444139429.57, … }

The ratio of the subsidy to the difficulty target is the current market price of proofs-of-work denominated in bitcoin.  Every bitcoin node agrees on this price because all nodes execute the same deterministic algorithms to calculate it.  These algorithms allow the bitcoin network itself to play the role of Szabo’s “dealers” and “secure timestamping protocol”.  They adjust the price of money in response to the supply of proof-of-work.

The chain of simplifications extends to the “Money creation” phase.  B-money required each user to accept the “highest bids…in terms of nominal cost per unit of b-money created”.  This requirement exists to ensure low prices (bids with a huge amount of b-money for very little work) are not accepted by the network.

But the bitcoin network doesn’t offer multiple concurrent prices to miners.  There is a single consensus price at all times, offered by all nodes identically.  Bitcoin nodes therefore do not have to wait to determine which block has the “highest difficulty” – they can accept the first block they see that meets the network’s current price.  This “greedy convergence” model, along with the Sybil resistance provided by proof-of-work, is what makes Nakamoto consensus a Byzantine fault-tolerant consensus algorithm.

A few examples of wallets commonly used as “singlesig”

A deterministic subsidy means all 21M bitcoin already exist

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.

A few examples of wallets commonly used as “singlesig”

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.

A deterministic difficulty ensures bitcoin’s distribution schedule

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.

A few examples of wallets commonly used as “singlesig”

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.

Deterministic pricing leads to decentralized consensus

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.

Bitcoin is a pair of layered markets

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

Layer 1 Market
1. network participants bid for their transaction's inclusion in block
2. winning participants board the train
3. train departs
Layer 0 Market
1. miner wins contest
2. miner earns opportunity to choose train passengers
3. miner conducts auction
4. miner collects block reward
5. miner mines block
6. train departs

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.


The short answer to the question posed in this article’s title was already given in the subtitle: Satoshi thought of bitcoin because they were trying to create a digital currency with a finite supply.

Having come this far, we can offer a more detailed answer.  How did Satoshi think of bitcoin?

Satoshi was familiar with b-money and its auction model
But Satoshi wanted a currency with a finite supply
So Satoshi eliminated the freedom of b-money users to create money
The network itself would create money based on a deterministic pricing function
Eliminating this freedom radically simplified the the auction for money creation
The subsidy was determined by fixing the supply of coins and picking one of the most natural distribution schedules possible
The difficulty was determined by fixing the rate at which coins are distributed
This required the blocks to contain timestamps and for the blockchain itself become a timestamping server
The benefit of a deterministic auction model was that it resulted in Nakamoto consensus
Having built the primary market for money distribution, Satoshi then turned to the secondary market for transaction settlement
Satoshi used existing approaches to transactions as chains of signatures
But solved the existing double-spend problem by including transactions in blocks where they would be protected by Nakamoto consensus
Transaction fees were created as a way to support the market for proofs-of-work as the subsidy decreases

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


1. The title of this piece is taken from the first telegraph message in history, sent by Samuel Morse in 1844: “What hath God wrought?”
2. The inverse is also true: bitcoin is (or was) largely illegible to traditional financial systems.
3. The moniker “proof-of-work” was provided later in 1999 by Markus Jakobsson and Ari Juels.
4. The modern email market has largely abandoned economics as a way of controlling spam.  While users and companies do pay email providers monthly in USD, spam is controlled through banlists and machine learning on user-data provided by central authorities.
5. At this juncture, some readers may believe me dismissive of the contributions of Dai or Szabo because they were inarticulate or hand-wavy on some points.  My feelings are the exact opposite:  Dai and Szabo were essentially right and the fact that they could not articulate every detail the way Satoshi subsequently did does not detract from their contributions.  Rather it should heighten our appreciation of them, as it reveals how difficult and unnatural distributed systems engineering is, even for its best practitioners.
6. There are two simplifications being made here:
a. The difficulty as reported by bitcoind is not exactly the number of expected computations; one must multiply by a factor of X: a difficulty of Y corresponds to Z expected computations to find a block.
b. The real price of proofs-of-work is increasingly affected by the transaction fee market.  See subsequent sections for more details on this.
7. In this model, the subsidy now depends on the block number.  For all nodes to calculate the same subsidy, the network must guarantee that all nodes have the same number of blocks.  These synchronization and consensus requirements were implicit in b-money’s auction model, as well.  We’ll explore below how bitcoin maintains this block number guarantee where b-money would have struggled.
8. Bitcoin nodes use several interesting heuristics to define the “current time” and validate that new blocks’ timestamps lie in an acceptable interval surrounding it.
9. 25% of the bitcoin white paper is a calculation by Satoshi—replete with C code!—demonstrating this claim.

Want to upgrade your bitcoin security? Onboard today!