The Written History of Bitcoin, Part 2: The Ghost in the Code

A Deliberate Detour

We were going to stay chronological. In the last installment, we watched Satoshi register bitcoin.org, send courtesy emails to Adam Back and Wei Dai, post the whitepaper on Halloween 2008, launch v0.1 on a Friday in January 2009, and recruit Martti Malmi to write the FAQ.¹ The natural next step is 2010. Pizza, Gavin, the first exchange, the first exploit, the first time Satoshi rolls back the ledger with his own keystrokes.

We will get there.

Watch the video live or after April 28, 2026.

But something keeps dragging at me every time I try to write the 2010 chapter, and I have to stop and deal with it before we go another step. The image of Satoshi that everyone else is leaning on makes less and less sense the longer I stare at the primary sources. The community has spent seventeen years building a mythology around a cypherpunk wizard, a serious cryptographer, a hoodie-wearing anon Linux purist with perfect OPSEC and Zen detachment.

The code does not describe that man. The forum posts do not describe that man. The bugs he shipped, the tools he chose, the people he panicked in front of, the features he fought against, and the miner he kept to himself do not describe that man either.

So we are taking a tangent. One article. A forensic profile built from the inside out. Not from who he was, but from what he left behind.

The ghost is in the code. And he left fingerprints everywhere.

The Finding Satoshi Problem

In 2026, a documentary called "Finding Satoshi" argued that bitcoin was co-created by Hal Finney and Len Sassaman.² I wrote a full response to that film already, and I will not repeat the whole thing here.³ The short version is that the documentary is hunting the wrong archetype. In fact, I argued they may be doing it deliberately.

Finney was a serious cryptographer. One of the best alive. He worked on PGP for years, built RPOW in 2004 as a reusable proof-of-work token, and spent his career in the world of academic and applied cryptography. Sassaman was a privacy researcher and a mix-network operator, the kind of person who ran a remailer and wrote academic papers on anonymous communication.

Both men were brilliant. Neither looks like Satoshi on the evidence.

Finney himself is on the record describing his first encounter with Bitcoin. He wrote, "When Satoshi announced the first release of the software, I grabbed it right away."⁴ Read that sentence with a forensic eye. It is the sentence of a user, not a co-author. A co-author does not "grab" a release. A co-author builds the release.

Adam Back, who actually got Satoshi's first email in August 2008, has rejected the Finney/Sassaman theory on narrower grounds. Timeline contradictions. Sassaman was in Belgium during hours when Satoshi was posting from what looked like a North American timezone. Neither family has ever found a private key or a wallet. Nathaniel Popper, the New York Times journalist who wrote Digital Gold, spent time with the Finney family, reviewed Hal's emails and wallets in person, and found nothing that put Hal inside the Satoshi account.⁵

But none of that even matters. The real problem with the Finney/Sassaman theory is not timelines or wallets. It is the wrong profile. Finney was a cryptographer, and Sassaman was a privacy researcher, but Bitcoin was clearly not built by a cryptographer. Gavin Andresen said so in public, to a room full of cryptographers, and nobody in the room argued with him.

The code says so too. The tools say so. The bugs say so. The way he managed the project says so.

So if Satoshi was not a cypherpunk, an open source ninja, or a serious cryptographer, what was he?

The code left fingerprints.

The Naive Cryptographer

In January 2015, the International Financial Cryptography Association held its annual conference in San Juan, Puerto Rico. The invited keynote was delivered by Gavin Andresen, the man who had received Satoshi's handoff in 2011 and run the reference client for the next three years. The title of his talk was "What Satoshi Did Not Know." The paper is published in Springer's Lecture Notes in Computer Science. The PDF is on the IFCA website. You can download it today.⁶

Gavin stood up in front of a room of professional cryptographers and walked them through a quiet thesis. The man who invented bitcoin, he explained, was not one of them.

"There is actually very little cryptography in Bitcoin," Gavin told the room. ECC keys. ECDSA signatures. SHA-256 hashing. That is the full list. Bitcoin does not use zero-knowledge proofs. It does not use blind signatures. It does not use homomorphic encryption. It does not use group signatures or ring signatures or any of the more advanced primitives that were already in the literature by 2008. Satoshi assembled three cryptographic building blocks, all of them widely available, and bolted them onto a consensus rule.

And then Gavin said the line that matters most.

Naive. Not an insult. A diagnosis. Satoshi used OpenSSL, but he used it shallowly. He picked ECC curve parameters without explaining his choices and without citing the academic debates around curve safety that were active at the time. He wrote his own serialization code instead of using an existing library. He wrote his own variable-length integer encoding. He shipped a hash function stack that worked but was not elegant.

A professional cryptographer would have shown his work. A professional cryptographer would have cited the papers. A professional cryptographer would have discussed curve selection on the mailing list. Satoshi did none of that.

He just shipped.

The Kaminsky Paradox

Around 2011, the security researcher Dan Kaminsky decided to break Bitcoin. Kaminsky had made his name in 2008 discovering a fundamental DNS vulnerability that affected almost every router on the internet. He was one of the best offensive security minds in the world. He looked at Bitcoin's thirty-one thousand lines of code and saw what he expected to see, a buggy payment network with exploitable holes.

He "failed quite gloriously."⁷

His own description of the experience, given to CoinDesk in 2013, is worth reading verbatim. He described the Bitcoin codebase as "dense and inscrutable." He said that every time he thought he had found a bug, he would keep reading and discover that the bug was already addressed, sometimes in a line or two further down the same function. The system, he said, was "preternaturally sound" despite running on top of "the buggy technologies we call the internet."

Hold the paradox in your head for a second.

Gavin Andresen, a working systems engineer who became the reference client maintainer, says the cryptographer Satoshi was naive. Dan Kaminsky, one of the best offensive security researchers in the world, says the code was so defensively written that he could not find a vulnerability he could exploit.

How do both of those things come out of the same man?

The answer is coming, but not yet.

The Fingerprints in the Code

Any working developer who has opened the Bitcoin v0.1 source code has had the same reaction within thirty seconds. "This looks like Windows code. This looks old. This looks like something my dad wrote."

They are not wrong. The evidence is everywhere, and it dates the author to a specific professional era.

Hungarian Notation

Variables in Bitcoin v0.1 are prefixed with type indicators. pindex for pointer to index. nValue for a number value. vch for a vector of chars. strHex for a string of hex.⁸ This is Systems Hungarian Notation, popularized by Charles Simonyi at Microsoft in the 1980s and mandatory for Windows developers through the 1990s.

By 2008, Hungarian notation was not just out of style in academia and open-source development. It was actively discouraged. Modern C++ style guides explicitly told developers to stop using it. Linux kernel contributors mocked it. University professors taught against it.

Satoshi did not care. His variables wore their types on their sleeve the way they had in Microsoft code shops in 1998.

The MFC Classes

Next to the Hungarian variables are the class definitions. CBlock. CTransaction. CWallet. CScript.⁹ That capital-C prefix on class names is the signature of Microsoft Foundation Class Library (MFC), the coding suite that Microsoft shipped for serious Windows developers from the early 1990s through the early 2000s. MFC peaked in the late 1990s. It was superseded by .NET a full decade before Bitcoin was written.

Hungarian notation plus CClassName prefixes is not a random coincidence. Taken together, we are looking at the combined grammar of professional Windows development from the Windows NT 4.0 through Windows XP era. Mike Hearn, who worked alongside Satoshi in 2010 and 2011, later summarized the pattern bluntly. Satoshi, he said, "came of age as a developer in the '90s and then stopped. He did not keep up with the evolution of the industry."¹⁰

The Monolithic main.cpp

The heart of Bitcoin v0.1 was a single file called main.cpp. Roughly 2,600 lines. Mining logic, network protocol, transaction validation, wallet management, and coinbase handling all in one file.¹¹

Zero unit tests...

Any computer science graduate in 2008 had been taught modularity, separation of concerns, and test-driven development. Any open-source contributor who had been paying attention for the previous decade would have laughed at a monolithic main file for a whole host of reasons. Satoshi wrote one anyway. He was not writing for peer review. He was writing for a shipping product, and he either didn't know or didn't care about what software developers were up to for the decade leading up to bitcoin's release.

The C++ Question

In the Finding Satoshi documentary (here comes the compliment, Mr Cohan), Bjarne Stroustrup, the creator of C++, actually said Satoshi was "a reasonably good C++ programmer for the time" and was "proficient in C++, not just C."¹² The broader developer community reviewing the code has pointed out that Satoshi wrote in "C-style" but compiled to C++, which is also an oddity worth noting.

What you can say, and what the developer community has been saying for fifteen years, is this. The code uses structs and pointers extensively. It avoids heavy templates, the Standard Template Library, and modern C++ abstractions like exceptions and smart pointers. This is the hallmark of a systems programmer or an embedded developer in a financial company or perhaps even a hardware or infrastructure context. People who write software inside routers, financial terminals, industrial machines, or high-frequency trading systems. They avoid complex language features because those features can cause hidden performance costs, hidden memory allocations, or hidden exception paths that crash the system at 3 AM.

Satoshi wrote code like someone who had lost sleep over a memory leak in a production system.

Berkeley DB

For the initial database layer, Satoshi chose Berkeley DB, which is another telling choice. BDB is a key-value store known for extreme speed and low-level control. It was the industry standard for high-frequency trading systems, LDAP directory servers, and telecom switching infrastructure through the early 2000s.¹³ Another hint that Satoshi had far more experience in infrastructure design and implementation than in software conventions.

An academic would have reached for SQLite. A modern web developer would have reached for a relational database. Berkeley DB implies a developer who cared about raw disk I/O performance and was willing to accept the ergonomic cost of a low-level API in exchange for speed.

wxWidgets and the Windows Release

Bitcoin v0.1 was Windows-only. Distributed as a .rar file.¹⁴ No installer, just an archive format beloved by Windows users in the 2000s. For the GUI, Satoshi used wxWidgets, a cross-platform UI toolkit that was notoriously clunky for amateurs and standard among professional Windows tool developers. Linux support did not arrive until v0.2 in December 2009, and it came from Martti Malmi, not from Satoshi.¹⁵

Pause on that fact for a second. Every cypherpunk Satoshi cited in the whitepaper, every cryptographer he respected, every security researcher who would later review the code, ran Linux. The cypherpunks were Linux purists by reputation. Satoshi shipped a Windows binary.

Increasingly, we are looking at a Satoshi who worked at the machine level in highly secure, high-performance infrastructure systems, and who seemed almost completely unaware of the conventions that governed more typical software development circles.

The Poker Table and the Marketplace

Here is where the profile gets strange.

Inside the pre-release and early release versions of Bitcoin, researchers poking through the source code have found working fragments of two features that never shipped. Not features Satoshi discussed on the forum. Features he wrote code for, included in the release, and removed later; silently.

The first is a peer-to-peer poker lobby. Lines 1573 through 1731 of the original source tree contained scaffolding for a multi-player card game running inside the Bitcoin client.¹⁶ The code was added around April 16, 2008, fully six months before the whitepaper dropped. It was removed in Bitcoin v0.8.2 after sitting unused in the codebase for years.

The second is more ambitious. A decentralized eBay-style marketplace. Inventory management. On-chain product reviews. Advertising slots purchasable with Bitcoin. Mike Hearn has confirmed that Satoshi had intended to integrate a peer-to-peer marketplace directly into the protocol but never finished the code.¹⁷

Stop and think about what that tells you about the man.

The mythology of Satoshi is a macroeconomic philosopher. A refugee from the banking system. A visionary who read Mises and Hayek and decided to build sound money. That is the story the 2015-era Bitcoin community built around him, and it is the story that made bitcoin into digital gold.

The actual first drafts of his source code contained a decentralized casino and a decentralized marketplace.

Which suggests a very different possibility. He built the chips first. He was not thinking about money in the abstract. He was thinking about what money was for. And the first two applications he reached for were a poker lobby and a commerce platform. Not a vault. Not a macro hedge. Not a protest against the Fed. A place to gamble and a place to buy things.

Or, to state the iceberg question out loud, was the payment network always the point and the poker table was just the first test application he could think of? A casino is the perfect testbed for a payment system. High transaction volume. Small amounts. Peer-to-peer settlement. Clear win/lose outcomes. If your system cannot handle a poker table, it cannot handle commerce.

Or, crazier still, did he work for a casino when he was writing bitcoin; building bitcoin adjacent to an iGaming job and forgot to scrub the evidence before publishing to SourceForge?

I cannot answer those questions. Neither can anyone else. But the code is in the record. You can download the v0.1 archive from the GitHub mirror right now and read the removed sections for yourself.

The Three-Week Window

So, there's a lot to digest from Satoshi's digital record, but there is also quite a bit to learn about how he spoke in conversation and how he dealt with day-to-day operations in bitcoin. Forget everything the mythology told you about "code is law" and "the immutable ledger" and the sacred inviolability of Satoshi's design. In the space of nineteen days in the summer of 2010, Satoshi himself demonstrated that the network he built was not a cathedral, it was a working prototype, and he was very much willing to break the walls down if the walls were wrong.

July 28, 2010: The OP_RETURN Bug

Users on the early bitcoin network discovered a catastrophic bug. Anyone could spend anyone else's bitcoin.¹⁸

Holy smokes!

The mechanism was subtle. In the original Bitcoin scripting language, the opcode OP_RETURN halted script execution and returned the value on top of the stack as the result. If you prepended any locking script with OP_1 OP_RETURN, the script would halt immediately and return true, regardless of the actual spending conditions underneath. The lock was irrelevant. You could empty any address on the network.

Satoshi patched the bug within hours. The fix changed OP_RETURN to immediately return false, neutralizing the bypass. The patch was pushed to the network. The immediate danger was contained.

Now draw the implication out slowly.

The Bitcoin architecture, as shipped, treated scripting as a flexible primitive that could be modified when it misbehaved. Satoshi did not hold an open forum debate about whether to change the opcode. He did not propose a BIP. He did not wait for community consensus. He patched the opcode and pushed the fix. One person. Consensus-level behavior change.

The "immutable" ledger was nineteen months old and its creator had already rewritten how its scripting language worked.

August 11, 2010: "Imagine If Gold Turned to Lead"

Fourteen days after the OP_RETURN patch, Satoshi posts to the Bitcoin forum in a thread titled "Escrow." Post number 340 in the Satoshi Nakamoto Institute archive. The timestamp is August 11, 2010.¹⁹

He is discussing escrow mechanisms. And he offers a thought experiment.

"Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again."

Read that quote in context. Two weeks earlier, the network had just experienced a bug that let anyone spend anyone else's coins. The creator of the network, in the middle of a public discussion about escrow, pauses to describe the theoretical appeal of a digital asset that could be rendered useless to a thief and restored when returned.

Whether this is coincidence or commentary is for the reader. Whether Satoshi was floating a design philosophy or just spit-balling in a thread is for the reader. The timestamp is the timestamp. The quote is the quote.

Thieves and recoverability were on his mind. That is a fact you cannot un-know once you have seen the date.

August 15, 2010: The Integer Overflow

Four days later, someone broke the network harder than anyone had ever broken it.

At block 74,638, a transaction created 184,467,440,737.09551616 BTC.²⁰ One hundred eighty-four billion (with a B!) bitcoin. More than eight thousand times the total supply the protocol would ever allow. The number is not random. It is 2^64 divided by 100 million, the maximum value of an unsigned 64-bit integer expressed in Bitcoin's base units. The transaction code failed to catch outputs so large they overflowed when summed.

Jeff Garzik spotted it first. He posted to the forum. Satoshi was awake and online.

Within five hours, Satoshi had written, tested, and released Bitcoin v0.3.10 with a patch. The new client rejected the overflow transaction and adopted the "good" chain. By block 74,691, fifty-three blocks later, the network had reorganized around the patched chain. The overflow was erased from the ledger. The transaction that created 184 billion bitcoin had never happened, as far as the network was concerned.

A small technical correction for precision. The fix was a fork. The new consensus rule rejected the overflow transaction, but older clients could still accept it. The practical effect, though, was a reorg and a reversal. A confirmed transaction, recorded on the blockchain, was undone by a patch released less than a day after it was mined.

Stop and hold that against the modern mythology.

"Code is law." A confirmed transaction is sacred. The ledger is immutable. One of the most foundational claims of modern bitcoin culture is that the protocol cannot be changed to reverse a transaction. And yet, nineteen months after launch, the creator of the network pushed a consensus change that reversed a confirmed transaction in five hours. Unilaterally. No BIP. No committee. No forum debate.

A pragmatist.

A man building a payments system who acted the way a pragmatist building a payments system would act when his system had a catastrophic bug.

August 15, 2010: OP_CAT and the Disabled Opcodes

On the same day he fixed the integer overflow, Satoshi disabled a set of powerful scripting opcodes. OP_CAT, which concatenated two stack values. OP_SUBSTR, OP_LEFT, OP_RIGHT for string manipulation. OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD for arithmetic. Others.²¹

The public reason was denial of service. An attacker could use OP_DUP combined with OP_CAT to exponentially increase the data size on the stack, exhausting node memory and crashing the network. This was a real concern. It was also a conservative choice. The opcodes were not removed from the codebase. They were commented out, with an implicit note that they could be re-enabled once scaling protections were in place.

That decision would echo for a decade. Those opcodes, particularly OP_CAT, are the building blocks of a more expressive scripting language that would enable smart contract functionality. Their absence is one reason the BTC network cannot do things other chains can do. Their absence is also one of the central fights happening in 2025-2026 in the BTC community with renewed interest in smart contracts and tokens, and the BSV network turned all of these opcodes back on in rolling updates between 2020 and 2026, because Satoshi's original design included them. So far, no catastrophes.

Nineteen days. Three consensus-level changes. All pushed by one person. None debated in public before deployment.

The "immutable" system was nothing of the sort in 2010. It was a live product, maintained by its author, who shipped patches the way any software engineer shipped patches. Quickly. Unilaterally. With a mind to keeping the thing running.

The Panicked Pragmatist

The mythology describes a Zen master who built a world-changing system and walked away with serene detachment. The record describes a man with a short fuse, a fragile sense of his own project's survival, and design instincts that were occasionally terrible.

"I Don't Have Time to Try to Convince You"

On July 29, 2010, Satoshi was in a thread archived on Bitcointalk titled "Scalability and transaction rate." Dan Larimer, using the handle bytemaster, was questioning Bitcoin's scalability. Particularly the ten-minute block time. Larimer argued that ten minutes was too slow for real payments.

Satoshi was explaining how payment processors could verify transactions within about ten seconds using Simplified Payment Verification. And then, in post number 287, he ran out of patience.²²

"If you don't believe me or don't get it, I don't have time to try to convince you, sorry."

That sentence has been quoted a thousand times as a statement of Zen confidence. Read it in context. That is not Zen. That is impatience. Satoshi is annoyed. He is explaining the architecture for the hundredth time, and a guy who would later build a major competing blockchain is pushing back, and Satoshi is telling him to get lost.

It is also, incidentally, the posture of someone who believes the scaling question is already solved and is frustrated that the objectors cannot read his documentation. Not a philosopher. An engineer who has written the answer down and is tired of repeating it.

The WikiLeaks Panic

In December 2010, WikiLeaks published State Department cables and saw its financial rails cut off by Visa, MasterCard, and PayPal. Julian Assange started asking for bitcoin donations. Bitcoin Twitter avant la lettre lit up. "Let them come. This is what Bitcoin is for."

Satoshi did not agree. On the forum, he wrote

"No, don't 'bring it on.' The project needs to grow gradually so the software can be strengthened along the way. I make this appeal to WikiLeaks not to try to use bitcoin."

Sit with that response. The person who had just published a system explicitly designed to route around financial censorship was, the first time a real censorship event tested his product, actively asking the censored party not to use it.

Why? Because he knew the software was not ready. He knew the infrastructure was fragile. He knew that putting WikiLeaks on the network would attract state attention his project could not yet survive. This is not the posture of a revolutionary arming the resistance. This is the posture of a product manager protecting a beta. A pragmatist.

Send to IP Address

One of the features Satoshi fought for hardest, and the one that died the fastest after he left, was the ability to send bitcoin directly to an IP address.²⁴

He loved this feature. He thought it was more "peer-to-peer" than sending to an address. You would open your client, type the IP, and the payment would route directly to the recipient's machine.

It was a privacy disaster. The IP revealed the recipient's location. The transaction was vulnerable to man-in-the-middle attacks, because there was no cryptographic authentication of the IP endpoint. The feature was removed from Bitcoin Core in v0.8.0 in 2011, after Satoshi was gone.

The man who built the electronic cash system cited by every cypherpunk manifesto wanted you to type an IP address into a text box to send money. That is not the design instinct of a privacy researcher like Sassaman, a cryptographer like Finney, or an activist like Back.

That is the design instinct of someone who thought peer-to-peer meant "direct endpoint connection," the way a TCP socket works.

The Benevolent Dictator

The mythology says Satoshi was a quiet collaborator who gently handed his project to the community and slipped away like a forest spirit. The record says something very different. He was a control freak whose management style caused friction the moment other serious developers showed up.

The Gatekeeper

In a 2010 IRC discussion, Gavin Andresen, who would later inherit the reference client, wrote the following about the project's development structure:

"I just wish I could convince Satoshi to switch to a more collaborative development model. Satoshi is the gatekeeper right now, all code flows through him."²⁵

Jeff Garzik, a veteran Linux kernel contributor who joined the project in 2010 and knew exactly what professional open-source collaboration looked like, described Satoshi's process as "mostly closed." Bitcoin only moved to GitHub after Satoshi left. Satoshi insisted on maintaining control via SourceForge and email patches, acting as the sole arbiter of what code was "official."

In a 2025 interview with CryptoNews, Garzik characterized Satoshi directly. "Not a great coder but absolutely a genius." And, separately, "a really good project leader." The same interview describes Satoshi as lacking understanding of "modularity," "unit testing," and other basics that "computer science majors learn."²⁶

A genius project leader who did not use modularity or unit tests. A product visionary who was not a great coder. A gatekeeper who would not let other serious developers commit without his sign-off.

That is the posture of a secure-systems or infrastructure CEO from 2003, not a cypherpunk commune member from 1996 or 2008.

The Drop-and-Run Release Pattern

Satoshi's release style was a signature all its own. He would disappear from the forum for weeks. He would work in isolation. And then he would upload a massive new version to SourceForge with little warning.

This was the opposite of modern open-source practice. No pull requests. No code review. No documented change logs in the commit messages. Just a new tarball on the download server and a short announcement that the new version was available.

It worked because he was the only person anyone trusted to make those decisions. It also forced the community to trust Satoshi's judgment instead of a transparent process. The very opposite of the "trustless" ethos that would later be retrofitted onto Bitcoin as a philosophy. In practice, early Bitcoin development was entirely based on trust in one person.

The GPU Arms Race Suppression

In 2010, a Florida programmer named Laszlo Hanyecz, who we will cover in the next article, figured out how to mine Bitcoin on a graphics card. He wrote GPU mining software. He started posting about it on the forum.

Satoshi's first response was a private message asking Laszlo to slow down. "Hey, can you go slow with this?"²⁷

Then he went public with a forum post arguing for a gentleman's agreement. "We should have a gentleman's agreement to postpone the GPU arms race as long as we can for the good of the network. It's much easier to get new users up to speed if they don't have to worry about GPU drivers and compatibility."

When Laszlo emailed Satoshi apologizing for "creeping up" on his project, Satoshi told him to let the forum thread die quietly.

Now here is the part that shows Satoshi's values, and more frankly, his guile.

Satoshi had already built his own GPU mining software. Privately. He had written it, allegedly, to defend the network against potential 51 percent attacks. The public single-threaded CPU miner he shipped was not the miner he was using himself. His own miner was more advanced than anything on the public client.²⁸

Read that fact against the Laszlo suppression. Satoshi asked the community to hold back on GPU mining while he himself already had the capability. He published the reference implementation and kept the production-grade tools for himself.

That is a pattern worth naming. Open source for you. Closed source for me.

It maps to something we are about to examine directly.

The Patoshi Pattern

In 2013, Sergio Demian Lerner, the chief scientist at RSK Labs, published research identifying a distinctive mining fingerprint in the early Bitcoin blockchain.²⁹ He called it the Patoshi pattern.

The fingerprint is visible in the ExtraNonce field of early blocks. ExtraNonce is a variable that miners increment to keep trying new hashes when the main nonce space is exhausted. A single-threaded miner produces a predictable sawtooth pattern as it increments ExtraNonce linearly. A multithreaded miner produces a different pattern, because the threads are scanning the nonce space in parallel.

The early Bitcoin blockchain contains two distinct mining fingerprints. One, which dominates the rest of the network, is the expected single-threaded pattern from the public client. The other, which appears consistently in roughly one out of every two blocks for the first year, is a multithreaded miner scanning the ExtraNonce field in parallel across multiple CPU cores.

Lerner's conclusion has been refined over the years. Patoshi, almost certainly Satoshi, mined approximately 1.1 million BTC in the first year of the network. He used a custom miner that was not available to the public. Multithreaded mining was not integrated into the public Bitcoin client until 2010, well after Patoshi had been using it privately for months.

There is more to the pattern. Patoshi reduced his hashrate in steps over the first year, appearing to throttle down as new miners joined. And he seems to have paused for five-minute intervals after mining each block. As if he did not want to win too many blocks in a row. As if he was deliberately not hogging the network.

Some researchers have argued this was Satoshi trying to protect the network from concentration. Others have argued he was simply watching for competitors. The exact motivation is not recoverable from the pattern. What is recoverable is the fact.

Satoshi shipped a single-threaded CPU miner as the reference implementation, while he ran a multithreaded optimized miner privately. He suppressed community efforts to develop GPU mining while already having the capability himself. He accumulated 1.1 million BTC in the first year, using software he did not share.

That is the behavior of a commercial builder, not a communitarian cypherpunk. He shipped the reference implementation and kept the production engine internal. The Laszlo suppression and the Patoshi pattern are the same story told twice.

Open source for you. Closed source for me.

The Archetype

Pull all the evidence into one frame.

A naive cryptographer who assembled three simple primitives and did not cite the debates around them. A codebase written in Hungarian notation with MFC class prefixes, signature grammar of 1990s Windows development. A monolithic main file with no unit tests. Berkeley DB as the storage engine. A Windows binary distributed in a .rar file. wxWidgets for the GUI. Struct-and-pointer heavy C++ that avoids modern abstractions. Dead code for a poker lobby and a decentralized marketplace. A willingness to push consensus-level changes when he felt it was necessary, and never asking permission. A custom multithreaded miner kept private while the public ran a single-threaded reference. A release pattern of working in isolation and dropping massive updates. A governance model of one person controlling code, website, forum, domain, and messaging. A preference for sending money to IP addresses because that felt more peer-to-peer and infrastructural. A panic at state attention. An impatience with critics. A thought experiment about stolen gold turning to lead.

Line the evidence up next to the mythology and ask which profile fits.

The mythology: an elite cryptographer. A Linux purist. A privacy researcher. A cypherpunk revolutionary. A macroeconomic philosopher. An immutability absolutist. A Zen founder who walked away.

The evidence: a 1990s commercial Windows systems engineer. A pragmatic product lead. A builder of payment infrastructure. A commercially minded CEO who shipped and iterated. A control-focused gatekeeper. A man whose background looks like a high-frequency trading shop, a legacy financial software firm, or a security company in the pre-cloud era. Someone who spent the 1990s writing matching engines for stock exchanges or routing logic for telecom switches or transaction systems for casinos.

He did not care about "pretty" code. He cared about the system not crashing.

When he sat down in 2008 and tried to solve the double-spending problem that had defeated professional cryptographers for two decades, he did not reach for the latest academic tools or industry standards. He reached for the boring, ugly, indestructible C-style patterns he had used his entire career. Hungarian notation. Monolithic main file. Berkeley DB. Windows binary. wxWidgets. Struct-and-pointer C++. Ship it. Patch it when it breaks.

Which brings us back to the Kaminsky paradox at the start of this article.

The cryptographer Satoshi was naive, as Gavin said. The coder Satoshi wrote in an out-of-date style that looked, to the academic eye, like something from the wrong decade. And yet Kaminsky could not find a vulnerability he could exploit, because every bug he chased had already been closed two lines further down.

The answer to that paradox is not that Satoshi was a cryptography savant. The answer is that he was a production systems engineer who knew, from scar tissue, that every unhandled edge case would crash a payment system at 3 AM, and he wasn't in the mood to deal with that. He thought like an adversary because he had spent a career building systems that adversaries attacked. He did not need to know the latest academic techniques. He seemingly didn't even care. He knew what a bug looked like. He had been shipping defensive code for at least fifteen years.

He may not have known how to solve the double-spending problem the way an academic cryptographer would have solved it. So he solved it the way a systems engineer solves things. With economic incentives, a ledger, a proof-of-work race, and a back-end that assumed every input was trying to break his code.

Cryptography did not save him from the double-spending problem. Battle-tested instinct did.

The Ghost in the Code

Every "we found Satoshi" documentary wants you to look at a cryptographer. The code is screaming "systems engineer."

The community has spent seventeen years building a mythology around a cypherpunk genius. The primary sources describe a pragmatic, impatient, commercially minded builder who shipped a poker lobby in his source code, preferred Windows, panicked about WikiLeaks, patched consensus-breaking bugs in five hours, and wrote code that looks like it came from the back office of a 1990s stock exchange or the risk desk of an early iGaming operation.

He was not a revolutionary. He was a product guy. A senior engineer. A man whose career trained him to ship, ship, ship, and to assume the users would be idiots and the attackers would be brilliant.

That profile does not match Hal Finney. It does not match Len Sassaman. It does not match Adam Back. It does not match any of the famous cypherpunks. It matches a very different kind of professional, and that professional was almost certainly working in a specific sector in the late 1990s and early 2000s where performance, security, and transactional integrity were all non-negotiable.

Which sector he was in, and which individual he turned out to be, is a different question. We are not answering it in this article. We are answering a narrower one. The profile everyone has been hunting is the wrong profile. The record points somewhere else entirely.

The ghost is not in the conference. He is not in the mailing list. He is not in the whitepaper footnotes.

The ghost is in the code. And he left fingerprints everywhere.

Next Time

We return to chronology. 2010 was the year Bitcoin grew up the hard way. A Florida programmer buys two pizzas for 10,000 BTC and makes history. Gavin Andresen walks into the project with an IRS auditor's eye for procedure. A Japanese exchange called Mt. Gox launches on July 18 and starts quoting bitcoin in dollars. A line of code is quietly added to the reference client limiting blocks to one megabyte. Satoshi calls the limit temporary. He says it will come out later.

And in the background, the man we just profiled is starting to notice that his project has gotten big enough to attract the kind of attention he was terrified of. Within months, he is going to disappear.

Next installment: "The Year of the Pizza."

Footnotes

¹ Kurt Wuckert Jr., "The Written History of Bitcoin: 2008-2009, Satoshi Emerges," kurtwuckertjr.com, 2026.

² "Finding Satoshi," documentary film, 2026. Thesis argues Hal Finney and Len Sassaman as bitcoin's co-creators.

³ Kurt Wuckert Jr., "Finding Satoshi: Not Even a Fresh Guess," kurtwuckertjr.com, 2026.

⁴ Hal Finney, "Bitcoin and me," forum post, March 19, 2013, bitcointalk.org thread 155054.

⁵ Nathaniel Popper, "Digital Gold," Harper, 2015. See also Popper's reporting for the New York Times during research for the book.

⁶ Gavin Andresen, "What Satoshi Did Not Know," invited keynote, Financial Cryptography and Data Security conference, 2015. Published by Springer. PDF at IFCA. Key quotes archived at Cointelegraph coverage.

⁷ Dan Kaminsky, interview with CoinDesk, "Security guru confesses: I couldn't hack Bitcoin," April 23, 2013, CoinDesk archive. See also Boing Boing coverage.

⁸ Bitcoin v0.1 source code, main.cpp and util.h, Trottier mirror on GitHub.

⁹ Bitcoin v0.1 class definitions, Trottier mirror, main.cpp.

¹⁰ Mike Hearn, analysis quoted in Blockworks, "50 clues about Satoshi Nakamoto's age," Blockworks.

¹¹ Bitcoin v0.1 main.cpp, roughly 2,600 lines. Trottier mirror.

¹² Bjarne Stroustrup, comment in "Finding Satoshi" documentary, 2026. Reported in The Block.

¹³ Berkeley DB in Bitcoin v0.1, Trottier mirror, db.cpp. Industry context from Oracle Berkeley DB documentation and contemporary reviews.

¹⁴ Bitcoin v0.1 release announcement and binary format, cryptography mailing list, January 9, 2009, Satoshi Nakamoto Institute archive.

¹⁵ Bitcoin v0.2 release notes, December 16, 2009. Linux port by Martti Malmi. Satoshi Nakamoto Institute archive.

¹⁶ Removed poker lobby code in Bitcoin v0.1, analysis at news.bitcoin.com. See also Hacker News discussion and BSV Blockchain analysis.

¹⁷ Removed marketplace code, analysis at news.bitcoin.com. Mike Hearn confirmation in public interviews and Bitcoin developer archives.

¹⁸ Bitcoin CVE list, OP_RETURN/OP_1 bug, July 28, 2010. Bitcoin Wiki CVE list.

¹⁹ Satoshi Nakamoto, post 340 in thread "Escrow," August 11, 2010, Satoshi Nakamoto Institute.

²⁰ Value Overflow Incident, August 15, 2010, block 74,638. CVE-2010-5139. Bitcoin Wiki Value overflow incident. See also Jean Cvllr technical analysis and Decrypt coverage.

²¹ OP_CAT and opcode disabling, August 15, 2010. Trust Machines history of OP_CAT. Nexio analysis.

²² Satoshi Nakamoto, post 287, "Scalability and transaction rate," July 29, 2010, Satoshi Nakamoto Institute.

²³ Satoshi Nakamoto, WikiLeaks appeal, December 2010, Satoshi Nakamoto Institute post 551.

²⁴ Bitcoin IP transaction feature and removal history, Bitcoin Wiki IP transaction. Removed in Bitcoin Core v0.8.0.

²⁵ Gavin Andresen, 2010 IRC quote on Satoshi as gatekeeper. Discussed in Bitcoin Magazine. See also River Financial profile.

²⁶ Jeff Garzik, interview with CryptoNews, 2025, "Satoshi Nakamoto was not a great coder but an absolute genius and a leader," CryptoNews exclusive.

²⁷ Laszlo Hanyecz, GPU mining correspondence with Satoshi Nakamoto, recounted in Bitcoin Magazine profile.

²⁸ Satoshi's private GPU mining capability, reported in Cointelegraph interview with early developer.

²⁹ Sergio Demian Lerner, Patoshi pattern research. Cointelegraph coverage. CoinDesk analysis. CoinCodex explainer.

Be good to each other. And pay attention to what people leave behind when they think nobody is looking.