MONEDIAL.comThe History of Bitcoin

Historical Current

1988–2011

Cypherpunk Genesis

Privacy. Power. The possibility of money without an issuer.

Bitcoin was neither inevitable nor an isolated invention. Follow the people, documents and unfinished experiments that made it thinkable — and the choices that made it different.

Explore the history ↓
PrivacyPowerTrust

Documents, experiments, unfinished possibilities.
Follow the narrative; open a document to look closer.

01 / 18Before BitcoinBack to top ↑

01 / Orientation

Before Bitcoin

Before Bitcoin came decades of questions about privacy, power, money and trust.

Before Bitcoin became money, it was an answer to questions people had been asking for years.

Who should control privacy in a networked world? Could two people communicate without asking an institution for permission? Could they transact without exposing their identities? Could cryptography do more than conceal messages—could it change who held power?

Bitcoin did not emerge from nowhere in 2008. For years, cryptographers, programmers, privacy advocates and digital-money experimenters had been building systems that depended less on governments, banks, corporations and other central intermediaries. Their work ranged from political manifestos and battles over encryption to private digital cash, proof of work, distributed-money proposals and experiments in making computational effort transferable.

They were not one movement marching toward Bitcoin. Their politics differed, their technical goals differed, and most were solving problems of their own time rather than anticipating a cryptocurrency that did not yet exist. Civil libertarians worried about surveillance. Crypto-anarchists imagined autonomous digital societies. Engineers pursued difficult technical problems. Others focused on private payments, anonymous communication or secure software.

What connected much of this work was a recurring instinct: when architecture could reduce the need to trust an institution, a promise from that institution was not enough.

Bitcoin would eventually push that instinct into money. [1] [2]

Movement I Cryptography becomes political

02 / 1976–1992

When Cryptography Became Political

Cryptography expanded what individuals could do without prior institutional permission—and people began arguing over what to do with that power.

Before cryptography became a political program, it solved technical problems. In 1976, Whitfield Diffie and Martin Hellman described public-key cryptography and a way for people communicating over an exposed channel to establish secure communication without first exchanging a secret key. Rivest, Shamir and Adleman followed with a practical public-key construction supporting encryption and digital signatures. [36] [37]

These capabilities were related but not identical. Encryption concealed a message. A signature connected a message to a key. A pseudonym could provide continuity without revealing a civil name. None automatically provided anonymity, and none automatically proved who controlled a key. The technology expanded the available choices without dictating how those choices should be used. [36] [37] [2]

Institutional questions followed. The Computer Security Act of 1987 assigned civilian responsibilities for federal computer-security standards while preserving an advisory role for national-security expertise. It was not a prohibition on private encryption, but it illustrated a question that would become increasingly contentious: who should shape the rules governing powerful cryptographic tools? [38]

Timothy C. May pushed the implications much further. The Crypto Anarchist Manifesto imagined pseudonymous communication and exchange operating beyond established systems of identification and control. May later dated its writing and early circulation to 1988; that chronology is his own account, not a reconstructed founding scene. [1]

May treated cryptography as a challenge to institutional power. Eric Hughes’s 1993 manifesto emphasized a related but different goal: privacy through selective disclosure and systems people could actually use. The surviving documents reveal different emphases, not two neatly bounded factions. Cryptography had widened the possibilities. People still had to decide what to build, whom to trust and what consequences they were willing to accept. [1] [2]

Steven Levy’s contemporary reporting captures the political urgency surrounding public cryptography at the time. The mathematics had come first. The politics emerged from what people realized they could build with it. [57]

Primary document · manifesto · 1988

The Crypto Anarchist Manifesto

A political prospectus for cryptographic autonomy, not a prediction of Bitcoin.

Read the manifesto ↗
Document details

Timothy C. May · 1988

[1]

03 / 1992–1993

The Cypherpunks Form

A mailing list turned a local gathering into a distributed community built around argument, experimentation and code.

“Cypherpunks write code.”
Eric Hughes · A Cypherpunk’s Manifesto, 1993 [2]

The early cypherpunk community took shape through Bay Area meetings in September 1992. Eric Hughes, Timothy May and John Gilmore were central organizers; May later credited Judith “Jude” Milhon with the name cypherpunks. [39]

The meetings mattered, but the mailing list changed the scale of the conversation. Gilmore’s toad.com provided a home for it, with Hugh Daniel helping operate the infrastructure. Programs, arguments and failures could now circulate far beyond the people who fit in one room. [39] [3]

The community quickly moved from discussion to experimentation. On September 25, 1992, Hughes posted working hopping-remailer code designed to make the origin of a message harder to trace. It was an experiment, not a guarantee of anonymity. Headers, logs, operators and traffic analysis still mattered—but publishing the code allowed others to test those weaknesses rather than merely debate them. [40]

Hal Finney’s October discussions explored how pseudonyms could acquire continuity through cryptographic authentication. PGP, remailers and digital signatures made identity and privacy practical engineering problems rather than abstractions. The gap between a mechanism that worked in principle and a system ordinary people could safely use became part of the work. [41] [3]

Participants disagreed sharply about politics and conduct as well as technology. An April 1993 exchange in which Jim Warren defended Dorothy Denning’s integrity despite opposing her encryption views shows a community arguing not only about policy but about how disagreement itself should work. [42]

Eric Hughes captured the shared method in A Cypherpunk’s Manifesto:

“Cypherpunks write code.”

The phrase was more than a slogan. Privacy could not depend entirely on legislation, corporate promises or good intentions. If a capability mattered, build it, publish it, test it and learn what failed. [2]

Civil libertarians, crypto-anarchists, engineers and people with very different political commitments could all participate in that method. That diversity would become especially important when the problem shifted from private communication to money. [1] [2] [3]

Primary document · manifesto · 1993-03-09

A Cypherpunk’s Manifesto

Privacy, selective disclosure and the imperative to build.

Cypherpunks write code.
Read the manifesto ↗
Document details

Eric Hughes · 1993-03-09

[2]

document · 1992

A conversation becomes a network

The mailing list carried debate beyond the Bay Area meetings.

Read the original ↗
Document details

Cypherpunks participants · 1992

[3]
Eric Hughes

His manifesto connects selective disclosure to a practical demand: build privacy-preserving systems.

[2]
John Gilmore in 2006, a co-founder of the cypherpunk group.
John Gilmore, 2006
Image credit

Andy Sternberg (revolute) · CC BY-SA 2.0. Reduced-size reproduction.

John Gilmore

A central participant in the early meetings and debates. The accompanying portrait dates from 2006, rather than the group’s founding period.

[3] [30]

04 / 1991–2000

The Crypto Wars

Once strong encryption reached ordinary users, control over cryptography became a fight involving software, law, markets and government access.

PGP’s 1991 release transformed strong cryptography from published mathematics into software ordinary computer users could run. Its international circulation also attracted federal scrutiny, making distribution itself part of the political battle. The investigation ended in January 1996 without prosecution—not with an acquittal, because no trial occurred. [5] [59]

The conflict became more explicit in April 1993 when the Clinton administration announced the Clipper initiative. Its stated goal was to provide strong encrypted communications while preserving lawfully authorized access for law enforcement. The controversy centered on key escrow: a privileged recovery mechanism built into a system intended to protect private communication. [4]

Critics questioned both the architecture and the institutions controlling access. In 1994, Matt Blaze demonstrated that devices could be used without supplying a valid Law Enforcement Access Field. He had exposed a failure in the escrow protocol, not broken the Skipjack cipher itself. [43]

Export controls created another front. Phil Zimmermann published PGP source code in book form, deliberately highlighting the strange boundary between protected publication and regulated operational software. Printing code did not settle the law, but it sharpened the question of whether software could be treated only as technology or also as expression. [44]

The courts supplied important but bounded answers. A Ninth Circuit panel ruled for Bernstein in 1999, but that opinion was later withdrawn for rehearing. Junger separately recognized expressive characteristics of source code while remanding the broader constitutional questions. Neither case simply abolished encryption regulation. [6] [45] [7]

Meanwhile policy itself changed. Export jurisdiction shifted and Commerce liberalized encryption rules in 2000, while classifications and restrictions remained. Technical criticism, software distribution, litigation, commercial demand, international competition and regulatory change all contributed. The Crypto Wars had no single victor and no single ending. [43] [45] [7] [46]

The deeper lesson was one the cypherpunks would carry into money: architecture, law and institutional power could not be separated by pretending one of them did not exist.

announcement · 1993-04-16

The state proposes key escrow

The White House presented key escrow as a way to combine communications privacy with lawful interception. Excerpt of the archived web announcement.

View the announcement ↗

White House Office of the Press Secretary / National Archives · U.S. government work. Reduced-size reproduction.

Document details

White House · 1993-04-16

[4]

Document excerpt

THE WHITE HOUSE. Office of the Press Secretary. For Immediate Release, April 16, 1993. STATEMENT BY THE PRESS SECRETARY. The President today announced a new initiative that will bring the Federal Government together with industry in a voluntary program to improve the security and privacy of telephone communications while meeting the legitimate needs of law enforcement. The initiative will involve the creation of new products to accelerate the development and use of advanced and secure telecommunications networks and wireless communications links.

document · June 1991; updated 1999

Why I Wrote PGP

Zimmermann explains the privacy concerns behind PGP. This is his 1999 revision of the essay first included in the June 1991 user guide.

Read the original ↗
Document details

Philip Zimmermann · June 1991; updated 1999

[5]

photograph · Photograph date unverified

When encryption code became a protest object

Encryption code printed on a T-shirt turned a technical object into a protest against export restrictions.

Explore the artifact ↗

Adam Back · CC0 1.0. Reduced-size reproduction.

Image details

Adam Back · Photograph date unverified

[8]
Phil Zimmermann speaking at HAL in 2001, the creator of PGP.
Phil Zimmermann at HAL, 2001
Image credit

Photo by CEphoto, Uwe Aranas · CC BY-SA 3.0. Reduced-size reproduction.

Phil Zimmermann

PGP put strong encryption in ordinary users’ hands and became a focus of the export-control controversy.

[5] [31]

Movement II Money and the missing issuer

05 / 1982–1998

Can Money Be Private?

Cryptography could make electronic cash private. It could not make the issuer disappear.

Where is the point of control?

Could electronic money preserve something closer to the privacy of physical cash? Ordinary electronic payments leave records at intermediaries, allowing transactions to be connected to people over time. David Chaum approached the problem as one of information design: a payment institution did not necessarily need to know the full path its money later traveled. [9]

His blind-signature system separated approval from recognition. A customer could prepare and conceal a digital note before the bank signed it, then remove the concealment while retaining a valid signature. When the note was later redeemed, the bank could verify that it had authorized the value without automatically linking that redemption to the earlier withdrawal. [9]

The bank still mattered. It issued the money, debited accounts, verified signatures, redeemed notes and maintained records needed to reject duplicate spending. Privacy from the issuer and independence from an issuer were different goals. [9] [48]

DigiCash attempted to commercialize these ideas. Its CyberBucks experiment let users test electronic cash in 1994, and Mark Twain Bank announced dollar-denominated eCash the following year. Additional banking pilots followed internationally. The cryptography worked within a larger system that still needed banks, merchants, users and viable software. [47] [48] [58]

DigiCash entered bankruptcy in 1998. No single explanation adequately accounts for the outcome. Adoption, bank and merchant participation, existing payment competition, financing and commercial execution all mattered. The failure of one company was not a verdict on the cryptographic idea. [49] [50]

For Bitcoin’s prehistory, the important distinction is simpler. Chaum asked how an electronic payment could be private. Bitcoin would later ask how a shared monetary history could operate without a central issuer.

Removing that issuer would mean finding another way to perform its work. [9] [18]

document · 1982

Blind Signatures for Untraceable Payments

A foundation for payment privacy that still allows an issuing institution.

Read the original ↗
Document details

David Chaum · 1982

[9]

document · 1995-10-23

Mark Twain Bank offers dollar-denominated eCash

A commercial deployment within a bank, distinct from the CyberBucks trial currency.

Read the original ↗
Document details

DigiCash · 1995-10-23

[48]
David Chaum, whose blind-signature work underpins the private-cash discussion.
David Chaum; photograph date unrecorded
Image credit

Primepq · CC BY 2.5. Reduced-size reproduction.

David Chaum

His blind-signature work made payment privacy an architectural question, while retaining an issuer.

[9] [29]
Why does a central issuer matter?

An issuer can determine whether a token is issued or redeemed and can become a point of institutional control or failure. Privacy and issuer independence are separate design choices.

[9] [18]
What is blind-signature cash?

Blinding allows a signer to authorize a message without learning its unblinded form. In cash protocols this can separate issuance from later spending, while the issuer still checks validity. This is a conceptual explanation, not an implementation guide.

[9]

Follow a blind-signed note

A conceptual online cash flow. Select any step to follow it; every step remains available below.

  1. Customer prepares a note with a fresh random identifier.
  2. Customer blinds the note: its identifier is concealed from the bank.
  3. Bank debits the account and signs the blinded note.
  4. Customer unblinds: a valid bank signature remains on the private digital note.
  5. Customer pays the merchant, who submits the note to the issuer.
  6. Bank verifies and redeems: check the signature, reject an already spent note, and record this redemption.
[9]

From blind signatures to bank deployment

  1. 1982

    Blind signatures

    CRYPTO ’82 presentation; proceedings followed.

    [9]
  2. Around 1990

    DigiCash, Amsterdam

    Company origins around 1990; approximate chronology.

    [47]
  3. 1994

    CyberBucks experiment

    Trial currency tests payment software.

    [47]
  4. 1995

    Mark Twain Bank

    Dollar-denominated eCash deployment.

    [48]
  5. 1996–97

    International pilots

    Bank announcements in 1996–97.

    [47]
  6. 1998

    Bankruptcy

    A commercial failure with multiple contributing pressures.

    [50] [49]

06 / The design problem

The Missing Pieces

Removing the bank did not remove its job. Someone—or something—still had to decide which history was real.

Suppose Alice owns digital coin X. She signs one transfer to Bob and another conflicting transfer of the same coin to Carol. Both signatures can be perfectly authentic. Authentication alone cannot decide which payment becomes history. [18]

That exposes several different problems hidden inside the idea of decentralized money. Scarcity governs how units are created. Verification determines whether a transaction follows the rules. Ordering determines which conflicting transfer came first. Agreement determines which history participants accept when different versions circulate. Solving one problem does not automatically solve the others. [18]

A bank or central issuer can perform these functions by maintaining the authoritative record. Remove that institution and the functions remain. Different participants may receive the same transactions in different orders, and a valid signature cannot appoint itself the final judge of competing histories. [9] [18]

Hashes and timestamping offered useful pieces. Haber and Stornetta showed ways to make records tamper-evident and place them in sequence—work Bitcoin would later cite. But timestamping alone did not decide ownership or create monetary consensus. [18]

Another line of research approached a different missing piece: could computation itself impose a verifiable cost?

That leads to proof of work. [10]

What is a double spend?

Digital data can be copied. A monetary system must decide which competing transfer of the same value counts. Bitcoin uses shared verification rules and a proof-of-work history rather than one privileged ledger keeper.

[18]

Double-Spend Decision: which one counts?

This is a question about rules, not a quiz. Choosing either recipient exposes the same unresolved problem.

  1. Alice → Bob: transfer of coin X, signed by Alice.
  2. Alice → Carol: conflicting transfer of the same coin X, also signed by Alice.
  3. Either choice needs a common ordering rule. Both signatures may be authentic; signatures alone cannot decide which transfer becomes accepted history.
[18]
Remove the bank

With an issuer, the bank performs these functions. Open this panel to remove the bank and reveal the jobs that remain.

  • Issue: who may create new units, and under what scarcity rule?
  • Record: who maintains the account or spent-note history?
  • Detect duplicates: how is reuse of the same value rejected?
  • Order transactions: how do observers seeing different arrival orders converge?
  • Resolve conflicts: which history is accepted when messages disagree?
[9] [18] [9] [18]

Build the System — missing pieces

Build the System: follow the same missing functions through Chapters 6, 7 and 11. Availability of a component is not a complete monetary system.

  1. Signatures → authorization. Available component; insufficient alone.
  2. Hashes → integrity. Available component; insufficient alone.
  3. Timestamps → evidence of sequence. Available component; insufficient alone.
  4. Scarcity → controlled issuance. Unresolved in this assembly.
  5. Ordering → an accepted transaction sequence. Unresolved in this assembly.
  6. Agreement → resolution of competing histories. Unresolved in this assembly.
  7. Proof of work → verifiable computational cost. Unresolved in this assembly.
[18] [11]

07 / 1992–2002

Proof of Work: Making Computation Cost Something

Proof of work made computation costly to produce and cheap to verify. That created a verifiable digital cost—but not yet digital money.

In 1992 Cynthia Dwork and Moni Naor proposed computational pricing as a defense against junk email. A small amount of work might be tolerable for one message but expensive for someone sending millions. The idea was resource pricing, not currency. [10]

Adam Back brought a related idea into working software. On March 28, 1997, he announced a Hashcash “postage” implementation to the cypherpunk mailing list. A sender repeatedly hashed changing input until finding an output that satisfied a difficulty target. Producing a valid stamp required expected computational effort; checking it required only a hash and a comparison. [51] [11]

Costly to produce. Cheap to verify.

That asymmetry was the important property. Difficulty represented expected work, not an exact receipt for effort: one producer might get lucky while another searched longer. Yet anyone could cheaply verify whether a successful result met the rule. [11]

Back’s 2002 Hashcash paper formalized the design and described its applications, but the implementation already existed in 1997. The two dates should not be collapsed into a single invention moment. [51] [11]

Hashcash still was not money. It did not provide transferable ownership or a distributed monetary history. A service could reject a stamp it had already seen, but local duplicate rejection was not network consensus.

What Hashcash supplied was narrower and enormously useful: a publicly verifiable digital cost. Bitcoin would later attach that cost to the history of transactions. [11] [51] [18]

document · 2002

Computational work as a cost

The later Hashcash paper explains a mechanism first proposed in 1997.

Read the original ↗
Document details

Adam Back · 2002

[11]

document · 1997-03-28

Hashcash: the working implementation

The 1997 announcement belongs before the formal 2002 paper. Follow the original message and its implementation context.

Read the original ↗
Document details

Adam Back · 1997-03-28

Archived source ↗ [51]
Adam Back in 2014, shown as the author of Hashcash; a later portrait.
Adam Back, 2014 — later portrait
Image credit

Joi Ito · CC BY 2.0. Reduced-size reproduction.

Adam Back

Hashcash supplied a proof-of-work mechanism; his correspondence also connected Satoshi to Wei Dai.

[11] [15] [28]
What is proof of work?

In Hashcash-style proof of work, a participant searches for a hash satisfying a difficulty condition. Others can check the result cheaply, but cannot infer the producer’s exact number of attempts. In Bitcoin, accumulated proof of work helps select among valid competing transaction histories.

[11] [18]

Build the System — verifiable cost

Build the System: follow the same missing functions through Chapters 6, 7 and 11. Availability of a component is not a complete monetary system.

  1. Signatures → authorization. Available component; insufficient alone.
  2. Hashes → integrity. Available component; insufficient alone.
  3. Timestamps → evidence of sequence. Available component; insufficient alone.
  4. Scarcity → controlled issuance. Unresolved in this assembly.
  5. Ordering → an accepted transaction sequence. Unresolved in this assembly.
  6. Agreement → resolution of competing histories. Unresolved in this assembly.
  7. Proof of work → verifiable computational cost. Available after Hashcash; not yet money.
[18] [11]

Movement III Roads toward decentralized money

08 / 1998–2005

Three Roads Toward Decentralized Money

b-money, Bit Gold and RPOW attacked different parts of the same problem. None was simply “Bitcoin before Bitcoin.”

b-money: accounts among pseudonyms

Wei Dai’s 1998 b-money proposal explicitly invoked May’s crypto-anarchy. Public-key pseudonyms would hold balances, signed messages would transfer value, and computational work could create money. Contracts could rely on deposits, reparations and arbitration rather than assuming conventional institutions would enforce every obligation. [12]

Dai proposed two accounting models. One asked participants broadly to maintain balances; another assigned accounting to servers whose deposits and published commitments were intended to make misconduct detectable. He also recognized a difficult problem: the real cost of computation varied, complicating monetary issuance. These were designs on paper, not a deployed Bitcoin-like network. [12]

The connection to Bitcoin is nevertheless documented. Adam Back directed Satoshi toward Dai, and surviving correspondence records Satoshi contacting him while development was already underway. That establishes contact and citation—not a claim that b-money caused Bitcoin. [16] [15]

Bit Gold: costly objects and title

Nick Szabo’s December 2005 public account of Bit Gold combined proof of work, distributed timestamping and a chain of property titles. Finney had already referred publicly to Bit Gold in 2004, so 2005 is a secure publication anchor rather than necessarily the date of conception. [13] [33]

Its units also created a valuation problem: computational work performed by different machines at different times did not automatically produce equally valuable objects. Timestamp services, title records and valuation arrangements remained important parts of the trust model. [13]

Bit Gold is therefore a strong conceptual precedent. Satoshi acknowledged it in 2010, but the surviving record does not establish when or how strongly it influenced Bitcoin’s original design. [34] [13]

RPOW: making a trusted component inspectable

Hal Finney’s Reusable Proofs of Work went further into implementation. In 2004 he invited people to test software that exchanged Hashcash proofs for reusable RSA-signed tokens. Spent tokens were replaced by new ones, allowing the server to reject reuse. [14]

The server ran on an IBM 4758 cryptographic coprocessor, and remote attestation allowed users to compare its reported configuration with published code. RPOW therefore did not eliminate the trusted component. It tried to make that component more verifiable. Hardware, attestation and server availability still mattered. [14]

Three projects, three different locations for trust. None solved the problem in exactly the way Bitcoin later would.

document · 1998-11

b-money

A proposal for pseudonymous participants to cooperate through money and contracts.

Read the original ↗
Document details

Wei Dai · 1998-11

[12]

document · 2005-12-29

Bit Gold

Szabo’s December 2005 account of Bit Gold. Finney had already discussed the concept publicly in August 2004.

Read the original ↗
Document details

Nick Szabo · 2005-12-29

[13] [33]

announcement · 2004-08-15

Reusable Proofs of Work

A transferable token experiment using a server backed by trusted hardware.

View the announcement ↗
Document details

Hal Finney · 2004-08-15

[14]

correspondence · August 2008 correspondence; 2023 testimony

A citation request and an introduction

In his 2023 witness statement, Back reproduces Satoshi’s August 20, 2008 citation request and describes his reply pointing Satoshi toward Wei Dai.

View correspondence ↗
Correspondence details

Adam Back; correspondence with Satoshi Nakamoto · August 2008 correspondence; 2023 testimony

[15]

correspondence · 2008-08

Satoshi contacts Wei Dai

Direct correspondence establishes contact while showing that development was already underway.

View correspondence ↗
Correspondence details

Satoshi Nakamoto and Wei Dai · 2008-08

[16]
Wei Dai

b-money proposed distributed monetary accounting. The correspondence documents contact without proving a simple origin story.

[12] [16]
Nick Szabo

Bit Gold preceded Bitcoin, and Satoshi acknowledged it in 2010. The timing and extent of its design influence remain uncertain.

[13] [34]

Issuance and scarcity

  1. b-money: computational production priced by cost; Dai identifies measurement difficulty and proposes an auction alternative.
  2. Bit Gold: costly proofs, with differing costs across machines and time; fungibility needs additional arrangements.
  3. RPOW: equal-value Hashcash or existing RPOW exchanged for new signed tokens.
[12] [13] [14] [16] [34]

Ownership and transfer

  1. b-money: balances associated with public-key pseudonyms; signed messages update accounts.
  2. Bit Gold: ownership follows the chain of title in a property registry.
  3. RPOW: a holder presents a token to the server and receives a replacement for onward transfer.
[12] [13] [14] [16] [34]

Duplicate spending and agreement

  1. b-money: replicated accounting or accountable servers, with demanding communication assumptions.
  2. Bit Gold: timestamp services and title registry distribute responsibility; this is not Bitcoin’s accumulated-work rule.
  3. RPOW: the server accepts a token once, then replaces it; its records enforce duplicate rejection.
[12] [13] [14] [16] [34]

Where trust remains

  1. b-money: broadcast assumptions, accounting participants or deposited and auditable servers.
  2. Bit Gold: timestamping, title-registry operation and valuation of differently costly units.
  3. RPOW: server availability, IBM 4758 hardware and remote attestation against published source.
[12] [13] [14] [16] [34]

Implementation and evidence

  1. b-money: proposal; DOCUMENTED CONNECTION to Bitcoin through citation and correspondence.
  2. Bit Gold: proposal; CONCEPTUAL PRECEDENT, with later acknowledgment but no demonstrated design pathway.
  3. RPOW: working experimental software; PARTICIPANT / CONCEPTUAL CONTINUITY through Finney, not demonstrated copying.
[12] [13] [14] [16] [34]

Follow an RPOW transfer

  1. Hashcash proof → RPOW server.
  2. RPOW server → RSA-signed reusable token.
  3. Holder → recipient: transfer the token.
  4. Recipient → server: exchange once for a replacement token.
  5. The server detects reuse. Remote attestation checks its reported code configuration; hardware and availability remain dependencies.
[14]

09 / Relationships, not a ladder

The Lineage, Without the Myth

The lineage is a network of problems, experiments and documented relationships, not a ladder pointing inevitably toward Bitcoin.

A neat sequence—Chaum → Hashcash → b-money → Bit Gold → RPOW → Bitcoin—is tempting because it makes history look orderly.

It is also misleading.

These projects addressed different problems: payment privacy, resource pricing, distributed balances, computational scarcity, title records and reusable tokens. They were not coordinated versions of one design slowly approaching Bitcoin. [9] [11] [12] [13] [14]

Monedial therefore distinguishes different kinds of historical relationship.

Documented contact or influence requires evidence such as a citation or correspondence. Even then, contact does not prove that a particular design decision resulted from it. The Hashcash citation and Satoshi’s correspondence with Back and Dai meet this narrower documentary standard. [16] [15] [18]

Conceptual precedent identifies an earlier design addressing a related problem even where direct influence cannot be shown. Bit Gold belongs here: historically relevant resemblance, followed by later acknowledgment, without a demonstrated pathway into the original design. [13] [34]

Broader technical context identifies ideas that belong to the intellectual environment without turning every predecessor into a personal influence on Satoshi.

Later acknowledgment is evidence from the date it occurred. It cannot be projected backward.

The result is less tidy than a family tree—and more historically useful. [34] [33]

An atlas of relationships

The lineage, without the myth

This diagram shows historical relationships and precedents. It does not mean Bitcoin was inevitable or that every predecessor directly influenced Satoshi.

  • Documented contact or influence
  • Conceptual precedent
  • Broader technical context

Private digital cash

Computational cost

Distributed money proposals

Bitcoin

All relationships · text equivalent
  • Chaum / DigiCash

    Payment privacy with an issuer: a distinct goal, not a proven direct path into Bitcoin.

    [9]

    Chaum / DigiCash → Bitcoin · broader technical context. Both address electronic cash; their privacy and issuer choices differ. [9] [18]

  • Dwork & Naor

    Earlier computational-cost research belongs to the broader proof-of-work context, not a demonstrated direct influence on Satoshi.

    [10]

    Dwork & Naor → Bitcoin · broader technical context. Computational pricing belongs to the broader technical history, not a claim of direct Satoshi influence. [10]

  • Hashcash / Back

    A cited proof-of-work mechanism, plus documented correspondence with Satoshi.

    [11] [15]

    Hashcash / Back → Bitcoin · documented contact or influence. The white paper cites Hashcash and correspondence documents contact with Back. [18] [15]

  • b-money / Dai

    Adam Back directed Satoshi toward Wei Dai’s proposal, after which Satoshi contacted Dai.

    [12] [16]

    b-money / Dai → Bitcoin · documented contact or influence. Correspondence and citation document a connection, not a simple invention-origin claim. [16] [18]

  • Bit Gold / Szabo

    A conceptual predecessor acknowledged by Satoshi in 2010; its role in the original design remains uncertain.

    [13] [34]

    Bit Gold / Szabo → Bitcoin · conceptual precedent. Conceptual precedent with later acknowledgment; direct design influence remains unresolved. [13] [34]

  • RPOW / Finney

    Reusable computational tokens, with a trusted hardware-backed server.

    [14]

    RPOW / Finney → Bitcoin · conceptual precedent. A prior reusable-token experiment with a different trust architecture. [14]

  • Bitcoin

    A different synthesis, not the inevitable endpoint of every earlier experiment.

    [18]

    Chaum / DigiCash → Bitcoin · broader technical context. Both address electronic cash; their privacy and issuer choices differ. [9] [18]

    Dwork & Naor → Bitcoin · broader technical context. Computational pricing belongs to the broader technical history, not a claim of direct Satoshi influence. [10]

    Hashcash / Back → Bitcoin · documented contact or influence. The white paper cites Hashcash and correspondence documents contact with Back. [18] [15]

    b-money / Dai → Bitcoin · documented contact or influence. Correspondence and citation document a connection, not a simple invention-origin claim. [16] [18]

    Bit Gold / Szabo → Bitcoin · conceptual precedent. Conceptual precedent with later acknowledgment; direct design influence remains unresolved. [13] [34]

    RPOW / Finney → Bitcoin · conceptual precedent. A prior reusable-token experiment with a different trust architecture. [14]

Movement IV Bitcoin’s synthesis

10 / August–October 2008

An Unknown Person Enters the Conversation

The surviving record gives us a system before it gives us a person.

In August 2008, someone using the name Satoshi Nakamoto contacted Adam Back about an electronic-cash design and a Hashcash citation. Back pointed Satoshi toward Wei Dai’s b-money, and Satoshi then contacted Dai about citing the proposal. Back’s later witness statement describes and reproduces portions of that exchange; it is retrospective testimony, not a complete archive of every email. [15] [16]

The chronology matters. Bitcoin development was already underway before the b-money referral. Satoshi later said the code had been written before the paper. Those statements do not provide a complete development diary, but they make a simple story of one predecessor suddenly producing Bitcoin impossible to sustain. [16] [32]

On October 31, 2008, Satoshi announced Bitcoin: A Peer-to-Peer Electronic Cash System to the Cryptography Mailing List:

“I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.”

The paper proposed a way for a network to resolve duplicate spending without appointing a central financial institution to maintain the authoritative history. [17] [18]

The historical evidence gives us correspondence, a paper and eventually code.

It does not give us a verified biography.

The system enters the record before the person behind the name does. [18]

announcement · 2008-10-31

An electronic cash system is announced

A mailing-list message introduced the paper to its first public audience.

I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.
View the announcement ↗
Document details

Satoshi Nakamoto · 2008-10-31

[17]

document · 2008-10-31

Bitcoin: A Peer-to-Peer Electronic Cash System

Read the technical argument in the original paper.

Read the original ↗
Document details

Satoshi Nakamoto · 2008-10-31

[18]

11 / The architecture

What Bitcoin Actually Combined

Bitcoin combined familiar components into an architecture of reduced institutional trust.

Satoshi did not invent digital signatures, hashing, electronic cash, proof of work, peer-to-peer communication or timestamping. The innovation was making several existing ideas perform different jobs inside one monetary architecture. [36] [37] [9] [10] [11]

Signed transactions authorize transfers. Peer-to-peer communication distributes them. Nodes independently check validity. Miners assemble transactions into blocks and perform proof of work. Hash linkage makes alteration visible, while accumulated work helps participants choose among valid competing histories. Proof of work cannot make an invalid transaction valid. [18]

Issuance rewards and transaction fees supply incentives to participate. Difficulty adjustment responds to changes in computational capacity. A public transaction history allows participants to verify the rules for themselves rather than relying on a central issuer’s private ledger. Confirmations reduce reversal risk under the system’s assumptions; they do not create unconditional finality. [18]

Bitcoin therefore reduced one kind of institutional trust without abolishing reliance altogether. Software still implements rules. Hardware performs work. Incentives shape behavior. Developers maintain code. People coordinate responses to faults and proposed changes.

Removing the monetary operator did not remove the humans. [18] [21] [52]

Bitcoin was a synthesis—not an inevitable endpoint.

Build the System — the synthesis

A SYNTHESIS — NOT AN INEVITABLE ENDPOINT. These functions participate together; implementation, incentives and human coordination remain.

  1. Signatures → authorization.
  2. Hashes → integrity and block linkage.
  3. Timestamps → record context; not an authority by themselves.
  4. Proof of work → costly history, under security assumptions.
  5. Peer-to-peer communication → open distribution.
  6. Block chain → ordering within a candidate history.
  7. Validation rules → independent verification and issuance limits.
  8. Accumulated work → selection among valid competing histories.
  9. Issuance/rewards and fees → participation incentives.
[18] [11]

12 / The privacy trade-off

The Cypherpunk Compromise

Bitcoin removed the issuer. It did not remove the observer.

What happens when the issuer disappears?

Chaumian electronic cash and Bitcoin solved different trust problems.

Blind signatures allowed a central issuer to validate digital cash without automatically linking a later redemption to the original withdrawal. The bank remained responsible for issuance, validity and duplicate-spend detection, but the payment relationship could be concealed from it. [9]

Bitcoin removed the central issuer and exposed a public transaction graph instead. The white paper proposed using public keys without attaching real-world identities and encouraged fresh keys, but it also acknowledged that transactions could be linked. Bitcoin is pseudonymous, not inherently anonymous. Outside information can connect an identity to a visible history. [18]

That is the cypherpunk compromise.

Chaumian cash kept the issuer and hid more of the payment relationship. Bitcoin removed the issuer and made monetary history independently verifiable by exposing it publicly.

Bitcoin therefore did not fulfill every cypherpunk privacy ambition. It exchanged one architecture of trust for another set of trade-offs.

The result was censorship-resistant monetary verification—but not invisible money. [9] [18] [2]

Why does a public ledger limit privacy?

Pseudonymous keys are not equivalent to unobservable payments. Public transfers can be linked to each other, and outside information can connect keys with people. The white paper acknowledges this information structure.

[18]

Two different privacy bargains

  1. Chaumian digital cash

    Private payment relationship

    Issuer: bank. Ledger: private issuer records. Payer/payee relationship: blinding separates withdrawal and redemption. Duplicate-spend authority: issuer. Verification: issuer signature and spent-note check. Trust remains in issuance, redemption and availability.

    [9]
  2. Bitcoin

    Public transaction graph

    Issuer: no central issuer. Ledger: public. Payer/payee relationship: pseudonymous, potentially linkable. Pseudonymous keys do not make payments inherently anonymous. Duplicate-spend resolution: validation and accumulated work among valid histories. Verification: participants can check independently. Trust remains in software, hardware, incentives and coordination.

    [18]

13 / 2008–2009

Bitcoin and the Financial Crisis

The financial crisis is launch context and symbolism, not demonstrated origin.

August 2008

Development was already underway.

Bitcoin development was already underway by August 2008. Lehman Brothers filed for bankruptcy on September 15. Satoshi announced the paper on October 31.

That chronology rules out the simplest version of the story: Lehman’s collapse did not initiate work already documented the month before. [16] [15] [20]

It does not reveal Satoshi’s private motivation. The broader financial crisis had begun before Lehman, and chronology alone cannot prove or exclude its influence. [35]

What the record does establish is symbolism.

The January 3, 2009 genesis block contains:

“The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”

The message anchors Bitcoin’s launch to a contemporary banking headline. It does not explain why development began. [19]

The crisis therefore belongs to Bitcoin’s launch context and historical meaning, not to a proven origin story. [19] [20] [17]

document · 2009-01-03

A newspaper headline in the genesis block

The embedded text places the launch alongside the banking crisis; it cannot by itself establish why development began.

The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
Read the original ↗
Document details

Satoshi Nakamoto · 2009-01-03

[19]

Development, crisis, announcement, launch

  1. 2008-08

    Development already underway

    Correspondence with Back and Dai predates Lehman’s collapse.

    [15] [16]
  2. 2008-09-15

    Lehman collapses

    The crisis intensifies; it is not the first evidence of Bitcoin development.

    See this moment in the Bitcoin Timeline → 2049 [20]
  3. 2008-10-31

    The paper is announced

    The Cryptography Mailing List receives Satoshi’s proposal.

    See this moment in the Bitcoin Timeline → 2050 [17]
  4. 2009-01-03

    Genesis block

    The embedded headline gives the launch a banking-crisis context.

    See this moment in the Bitcoin Timeline → 2051 [19]

14 / January 2009

The System Becomes Real

Bitcoin became a network when participation stopped belonging only to its creator.

The genesis block dates to January 3, 2009.

Five days later, Satoshi announced Bitcoin v0.1 and offered software other people could run. It was explicitly experimental—an alpha release, not a finished monetary economy—but the idea had crossed an important boundary. A paper could be debated. Software could be tested. [19] [21]

Hal Finney joined almost immediately. His January 11 message said simply:

“Running bitcoin”

Finney later recalled finding bugs, reporting them and working with Satoshi as fixes were made. The early network was not merely a chain of blocks; it was people running software and helping it survive contact with reality. [22] [23]

Finney also recalled receiving ten bitcoins from Satoshi in the first known person-to-person Bitcoin transfer. “First known” matters: the surviving record cannot prove that no private test preceded it. [23]

The progression was becoming visible:

Idea → Software → Network

Money would require another step—people willing to treat the units as something worth exchanging.

In January 2009, the crucial change was simpler.

Someone other than Satoshi was running Bitcoin. [21] [23]

announcement · 2009-01-08

Bitcoin v0.1 released

The January 8, 2009 mailing-list announcement invited others to run the first software release.

View the announcement ↗
Document details

Satoshi Nakamoto · 2009-01-08

[21]

document · 2009-01-11

Running bitcoin

A short public message marks participation in the early network.

Running bitcoin
Read the original ↗
Document details

Hal Finney · 2009-01-11

[22]
Hal Finney

He built RPOW and later helped test Bitcoin, linking earlier experimentation to the first working network.

[14] [23]

Idea → Software → Network → Money

  1. 2008-10-31

    Paper announcement

    The white paper proposes the architecture.

    [17]
  2. 2009-01-08

    Public release

    A release lets others run it.

    [21]
  3. 2009-01

    Participation

    Finney joins and helps test the software.

    [22] [23]
  4. 2010-05-22

    Money exchanged for goods

    The pizza exchange demonstrates economic use; it does not imply a mature market.

    [53]

Movement V The network becomes independent

15 / 2009–2010

From Cryptography Experiment to Monetary Community

A protocol supplied common rules. People supplied the reasons to use them.

By the end of 2009, Bitcoin was becoming more than Satoshi’s program.

The Bitcoin 0.2 announcement credited Martti Malmi with development work including Linux support and features that helped keep the software running in the background. It thanked New Liberty Standard for testing and pointed users toward a new forum. The network was beginning to depend on contributions its creator did not make alone. [52]

Exchange followed the same pattern. Bitcoin’s protocol did not contain a dollar price. Participants had to discover one socially. In early 2010, Malmi discussed adjusting an exchange service’s pricing according to supply and demand while New Liberty Standard reported small-volume trading. Merchants and exchangers faced a chicken-and-egg problem: each needed users the other did not yet have. [56]

Then came pizza.

On May 18, 2010, Laszlo Hanyecz offered 10,000 bitcoins for someone to arrange delivery of pizzas. On May 22 he reported that the trade had succeeded and thanked jercos. The enduring importance of the exchange is not a retrospective dollar value.

It is that someone surrendered an ordinary good for bitcoin. [53]

Software development, conversation, exchange and commerce were becoming parts of the same community. Participants did not need to agree on Bitcoin’s ultimate purpose or political meaning.

They only needed enough agreement on the rules to transact with one another. [52] [53]

16 / 2010–2011

WikiLeaks: When the Theory Met the World

Censorship resistance became meaningful when someone needed it—and risky when the network was still fragile.

In late 2010, payment restrictions disrupted WikiLeaks’s access to conventional donation channels. A problem cypherpunks had discussed for years suddenly became concrete: financial intermediaries could refuse to carry a payment. WikiLeaks’s own account documents its experience of the blockade, though not every institution’s rationale. [24]

Bitcoin supporters immediately saw the connection.

Satoshi saw the danger as well.

When forum participants discussed encouraging WikiLeaks to use Bitcoin, Satoshi asked them not to invite that level of attention while the software and community were still small. On December 11, amid growing publicity, he wrote that WikiLeaks had “kicked the hornet’s nest.” [25] [26]

The hesitation was not a rejection of censorship resistance. It exposed a tension inside the idea.

A censorship-resistant monetary system matters because it can operate when intermediaries refuse to cooperate.

But a young system may not survive the pressure required to prove it.

WikiLeaks announced Bitcoin donations in June 2011. By then the theoretical use case had become real. Capability and survivability, however, remained different questions. [24] [55] [54]

document · 2010-12-11

The hornet’s nest

The warning concerns the pressure on a small network, not a proven explanation for Satoshi’s later departure.

Read the original ↗
Document details

Satoshi Nakamoto · 2010-12-11

[26]
Theory → Reality: capability versus survivability
  • Theory: reduce dependence on payment intermediaries that can refuse service.
  • Reality: a blocked recipient needs a usable alternative.
  • Survivability: a small network may attract pressure before its software and community are ready.
[24] [25] [26] [24] [25] [26]

17 / 2010–2011

Satoshi Leaves

The mystery is why Satoshi left. The historical fact is that Bitcoin did not stop.

Satoshi’s withdrawal was gradual rather than theatrical. Other developers were already contributing, and technical correspondence continued after public participation began to recede. There was no single farewell moment. [52] [27]

The last post in Satoshi’s established BitcoinTalk sequence concerned denial-of-service protections in version 0.3.19 on December 12, 2010. The page records an edit the following day. It was a software post, not a goodbye. [54]

On April 23, 2011, Satoshi wrote to Mike Hearn:

“I’ve moved on to other things. It’s in good hands with Gavin and everyone.”

The sentence establishes the decision to move on.

It does not establish why. [27]

Years of speculation have attached government attention, the CIA, WikiLeaks and many other explanations to the departure. The surviving evidence does not establish those causes, and proximity in time cannot substitute for proof. [27] [26]

The more important historical fact is visible without solving the mystery:

Bitcoin continued.

A network conceived without a central monetary authority also survived the departure of the person who introduced it. That did not make Bitcoin perfectly decentralized or make influential people irrelevant.

It did mean Bitcoin was no longer Satoshi’s project alone. [27] [52]

correspondence · 2011-04-23

In good hands

Correspondence with Mike Hearn records withdrawal, without establishing its cause.

I've moved on to other things. It's in good hands with Gavin and everyone.
View correspondence ↗
Correspondence details

Satoshi Nakamoto · 2011-04-23

[27]
Gavin Andresen

He took on a larger development role as Satoshi withdrew; Satoshi named him in the April 2011 correspondence.

[27]

18 / An unfinished inheritance

What Did the Cypherpunks Give Bitcoin?

Problems, methods and experiments survived their original settings—and changed as Bitcoin combined them.

The cypherpunks did not give Bitcoin a blueprint.

They gave it questions.

How much information should a payment reveal? Who should control communication? Could identity exist without permission? Could software reduce the power of intermediaries? Could digital value move without an institution deciding every transaction?

They also supplied a method: where possible, replace promises with mechanisms that people can inspect, test and use. [1] [2]

And they supplied experiments.

Chaum showed that cryptography could alter what a payment intermediary learned, while retaining an issuer. Hashcash turned computation into a verifiable cost. b-money described pseudonymous monetary cooperation. Bit Gold combined costly computation with timestamping and title. RPOW made computational tokens reusable while keeping a verifiable trusted server. [9] [11] [12] [13] [14]

None was Bitcoin waiting to be finished.

Bitcoin made different choices.

It removed the central monetary issuer but exposed a public ledger. It attached proof of work not merely to a request but to the history of transactions. It combined validation, incentives and accumulated work so that strangers could maintain a common monetary record without appointing one institution to own it. [18]

The inheritance was therefore neither a straight line nor a completed ideology.

It was a collection of problems, tools and habits of thought.

The cypherpunks did not give Bitcoin its final form.

They helped create a world in which someone could imagine it—and a method for turning that imagination into running code. [1] [2]

Sources & further investigation

Primary documents

  1. The Crypto Anarchist Manifesto
    Source provenance

    Timothy C. May · 1988

  2. A Cypherpunk's Manifesto
    Source provenance

    Eric Hughes · 1993-03-09

  3. Cypherpunks mailing-list archive
    Source provenance

    Cypherpunks participants

  4. Why I Wrote PGP
    Source provenance

    Philip Zimmermann · June 1991; updated 1999 · Author-hosted essay, 1999 revision of the June 1991 text.

  5. Munitions T-shirt (back)
    Source provenance

    Adam Back · Photograph date unverified

  6. Blind Signatures for Untraceable Payments
    Source provenance

    David Chaum · 1982

  7. Pricing via Processing or Combatting Junk Mail
    Source provenance

    Cynthia Dwork and Moni Naor · 1992

  8. Hashcash — A Denial of Service Counter-Measure
    Source provenance

    Adam Back · 2002-08-01 · Sections 2.1 and 3, printed pages 2–3; probabilistic cost and the Hashcash cost-function.

  9. b-money
    Source provenance

    Wei Dai · 1998-11

  10. Bit Gold
    Source provenance

    Nick Szabo · 2005-12-29

  11. RPOW — Reusable Proofs of Work
    Source provenance

    Hal Finney · 2004-08-15

  12. Satoshi–Wei Dai correspondence, 2008–2009 — published on Gwern.net
    Source provenance

    Satoshi Nakamoto and Wei Dai · Gwern.net · Correspondence, 2008–2009; published later on Gwern.net · Introductory publication explanation; Emails 1–3. Email 1: August 22, 2008, “Citation of your b-money page.” Email 3: January 10, 2009.

  13. Bitcoin P2P e-cash paper announcement
    Source provenance

    Satoshi Nakamoto · 2008-10-31

  14. Bitcoin: A Peer-to-Peer Electronic Cash System
    Source provenance

    Satoshi Nakamoto · 2008

  15. Bitcoin genesis block construction
    Source provenance

    Bitcoin Core contributors

  16. Bitcoin v0.1 released
    Source provenance

    Satoshi Nakamoto · 2009-01-08

  17. Running bitcoin
    Source provenance

    Hal Finney · 2009-01-11

  18. Bitcoin and me
    Source provenance

    Hal Finney · 2013-03-19

  19. Banking Blockade
    Source provenance

    WikiLeaks

  20. WikiLeaks contact info?
    Source provenance

    Bitcoin forum participants · 2010 · Satoshi’s December 5, 2010 response, post #148; discussion began in November

  21. Satoshi: WikiLeaks has kicked the hornet’s nest
    Source provenance

    Satoshi Nakamoto · 2010-12-11

  22. Satoshi correspondence with Mike Hearn
    Source provenance

    Satoshi Nakamoto and Mike Hearn · 2011-04-23

  23. Adam Back, 2014 — later portrait
    Source provenance

    Joi Ito · 2014-12-02

  24. David Chaum; photograph date unrecorded
    Source provenance

    Primepq

  25. John Gilmore, 2006
    Source provenance

    Andy Sternberg (revolute)

  26. Phil Zimmermann at HAL, 2001
    Source provenance

    Photo by CEphoto, Uwe Aranas

  27. Bitcoin P2P e-cash paper — code before the paper
    Source provenance

    Satoshi Nakamoto · 2008-11-08 · November 8, 2008, 20:58 EST (November 9 UTC); final substantive paragraph before signature.

  28. RPOW — discussion of Nick Szabo’s Bit Gold
    Source provenance

    Hal Finney · 2004-08-19 · August 19, 2004, 01:45 EDT; paragraph beginning “Another way to think of RPOWs”.

  29. Re: They want to delete the Wikipedia article
    Source provenance

    Satoshi Nakamoto · 2010-07-20 · Reply #14, message 4508, opening paragraph; July 20, 2010, 18:38:28 UTC. Edited July 22; acknowledgment also quoted in the next reply on July 20.

  30. New Directions in Cryptography
    Source provenance

    Whitfield Diffie and Martin Hellman · 1976-11

  31. A Method for Obtaining Digital Signatures and Public-Key Cryptosystems
    Source provenance

    Ronald Rivest, Adi Shamir and Leonard Adleman · 1978-02

  32. The Cyphernomicon
    Source provenance

    Timothy C. May · 1994-09-10 · Participant retrospective; sections on the origins of the group and list

    Archived source
  33. The hopping remailer is done
    Source provenance

    Eric Hughes · 1992-09-25

  34. Pseudonyms and cryptographic authentication: October 1992 discussion
    Source provenance

    Hal Finney · 1992-10

  35. More details from Denning
    Source provenance

    Jim Warren · 1993-04-21

  36. Protocol Failure in the Escrowed Encryption Standard
    Source provenance

    Matt Blaze · 1994-08-20

  37. Author’s preface: PGP Source Code and Internals
    Source provenance

    Philip Zimmermann · 1995

  38. eCash: original DigiCash announcements and chronology
    Source provenance

    David Chaum · 1994 trial; 1995 deployment; 1996–97 bank announcements; participant-maintained archive

  39. First Bank to Launch Electronic Cash
    Source provenance

    DigiCash · 1995-10-23

  40. [ANNOUNCE] hash cash postage implementation
    Source provenance

    Adam Back · 1997-03-28

    Archived source
  41. Bitcoin 0.2 released
    Source provenance

    Satoshi Nakamoto · 2009-12-17 · UTC timestamp; credits Martti Malmi and New Liberty Standard

  42. Pizza for bitcoins?
    Source provenance

    Laszlo Hanyecz and forum participants · 2010-05 · May 18 offer; May 22 completion, post #11

  43. Added some DoS limits, removed safe mode (0.3.19)
    Source provenance

    Satoshi Nakamoto · 2010-12-12 · Last post in the established BitcoinTalk sequence; edited December 13

  44. New Exchange Service: BTC 2 PSC — discussion of exchange and pricing
    Source provenance

    Martti Malmi, NewLibertyStandard and forum participants · 2010-01 · January 17 and 19 posts; participant descriptions of pricing and small-volume exchange

  45. Zimmermann Case Dropped: defense counsel announcement
    Source provenance

    Philip L. Dubois and Philip Zimmermann · 1996-01-12

  1. Clipper Chip encryption initiative
    Source provenance

    White House · 1993-04-16

  2. Bernstein v. DOJ, 176 F.3d 1132 (panel opinion)
    Source provenance

    U.S. Court of Appeals, Ninth Circuit · 1999

  3. Junger v. Daley, 209 F.3d 481
    Source provenance

    U.S. Court of Appeals, Sixth Circuit · 2000-04-04

  4. Adam Back: first witness statement, including correspondence with Satoshi
    Source provenance

    Adam Back · 2023-07-17 · COPA v Wright, IL-2021-000019; paragraphs 5-10, pages 2-3; identifies Exhibit AB1.

  5. Reflections on a Year of Crisis
    Source provenance

    Ben S. Bernanke · 2009-08-21 · Opening paragraph identifies August 2007 as the onset of the crisis.

  6. Computer Security Act of 1987 (Public Law 100–235)
    Source provenance

    United States Congress · 1988-01-08

  7. Bernstein: order withdrawing panel opinion and granting rehearing en banc
    Source provenance

    Ninth Circuit · 1999-09-30

  8. Revisions to Encryption Items, 65 FR 2492
    Source provenance

    Bureau of Export Administration · 2000-01-14

Contemporary reporting

  1. The Bankrupt Promise of Micropayments
    Source provenance

    WIRED · 1998-04

  2. WikiLeaks Asks For Anonymous Bitcoin Donations
    Source provenance

    Andy Greenberg · 2011-06-14 · Used for acceptance date and payment restrictions, not the article’s overstatement of anonymity

  3. Crypto Rebels
    Source provenance

    Steven Levy · 1993-02-01

  4. E-Money (That’s What I Want)
    Source provenance

    Steven Levy · 1994-12

Scholarship & later histories

  1. Support for Specific Institutions
    Source provenance

    Federal Reserve History · 2008-09-15

  2. Digging Those Digicash Blues
    Source provenance

    WIRED · 2001-06