Probabilistic Analysis

The Bayesian Model

A full reproduction of Eric Ringger's likelihood ratio analysis, plus three code-based evidence items drawn from our own analysis of hashcash, Bitcoin v0.1, and Adam Back's post-2013 public code record.

The Setup

Ringger's approach treats each piece of evidence as a likelihood ratio: how much more likely is this evidence if Back is Satoshi compared to if he isn't? Multiply them together. Apply Bayes' theorem. The result is a posterior probability conditioned on your chosen prior.

The key advantage over the NYT's qualitative framing: you're forced to put numbers on your beliefs and show your work. The key limitation: every LR is a judgment call, and the independence assumptions encoded in the DAG structure are arguable.

Formal definition. For evidence E and hypothesis H (Back = Satoshi):
  
    Bayes factor (LR): P(E | H) / P(E | ¬H)

    Posterior odds: prior odds × ∏ LRᵢ

    Posterior probability: posterior odds / (1 + posterior odds)
  
  LR > 1 supports H. LR < 1 undermines H. Conditional dependencies between evidence items are encoded in the DAG.

DAG Structure

Ringger models four conditional dependencies. Evidence items that are causally downstream of others are not independent — their LRs must be evaluated conditional on their parents.

E13 (code absence) is not shown; it connects directly to H like the other independent nodes. The four conditional edges — E1→E2, E2→{E4,E5,E7} — encode Ringger's judgment that background knowledge makes the blueprint more probable, and that blueprint makes rhetoric/citation/linguistic evidence more probable.

Ringger's Evidence: E1–E10

All ten likelihood ratios from Ringger's Substack post, reproduced exactly. The combined LR of 165,110,400 is verified.

ID	Evidence	Condition	LR	Assessment
E1	Background: British academic, cypherpunk, crypto 1990s	H	90	Generous but defensible. Extremely rare combination.
E2	Blueprint posts (b-money reference + hashcash integration)	E1	7	Given the background, writing the blueprint documents is still unusual.
E3	Combined key citations in whitepaper (hashcash + b-money)	H	20	Both cited explicitly; hashcash is rare, b-money nearly unknown.
E4	Rhetorical patterns matching Satoshi's forum writing	E2	13	Almér writing stylometry. Back ranks 4th of 48 candidates.
E5	b-money citation (Wei Dai contact)	E2	4	Satoshi emailed Dai before whitepaper publication. Back knew Dai.
E6	Whitepaper technical writing style (academic register)	H	30	The most generous LR in the model. Back's academic credentials match the whitepaper register precisely.
E7	Linguistic fingerprint (vocabulary, phrasing)	E2	6	Conditional on blueprint, still distinctive.
E8	Behavioral signals (El Salvador interview evasiveness)	H	4	Claimed not to have received the Satoshi email. Pattern of specific denials.
E9	Timing gap (Back denied prior Satoshi contact publicly)	H	0.5	Weak counter-evidence. Denial could be false or cover.
E10	Email metadata inconsistency in original exchange	H	0.7	Minor anomaly. Weak counter-evidence.

Combined LR (point estimate):
90 × 7 × 20 × 13 × 4 × 30 × 6 × 4 × 0.5 × 0.7

= 165,110,400 ✓ exactly matches Ringger

Prior: Uniform 1/620

99.9996%

Posterior probability

Prior: Short-list 1/50

>99.9999%

Posterior probability

Prior: Broad CS 1/10,000

99.9939%

Posterior probability

Code Evidence: E11–E13

Ringger's model covers writing, behavior, and background. It does not include any code comparison. We add three items from our own analysis. They are independent from each other and from Ringger's evidence (no DAG edges needed).

ID	Evidence	LR (point)	Range	Direction
E11 NEW	Code stylometry: Back matches 1 of 12 Bitcoin v0.1 style traits	0.15	0.05–0.40	Counter
E12 NEW	MSVC environment: hashcash shipped with Visual C++ project file — same as Bitcoin v0.1	2.0	1.0–4.0	Positive
E13 NEW	Post-2013 code absence: adam3us GitHub has zero public C++ despite CEO of C++ crypto company	2.0	1.0–4.0	Weak positive

Net code evidence LR: 0.15 × 2.0 × 2.0 = 0.60 (slight counter)

Full model LR: 165,110,400 × 0.60 = 99,066,240
Change from Ringger: −40% — real movement, but still ~99M

Note on E13. The code absence finding is the most interpretively loaded of the three. A rational person who knows they are being investigated would avoid producing public C++ code. But "technical CEO who delegates coding" is also a plausible explanation. The LR of 2.0 reflects weak positive evidence — meaningful enough to include, not strong enough to drive the result.

Hashcash Code Analysis

Adam Back's hashcash (released 1997, updated through 2011) is the best available sample of his C code prior to Bitcoin. The GitHub mirror confirms Back (adam3us) as a contributor. The cypherspace.org distribution explicitly includes a Visual C++ project file. Here is what the code shows when compared against Bitcoin v0.1.

Matching traits

✓	4-space indentation — both use exactly 4 spaces throughout
✓	MSVC development environment — VC++ project file shipped with hashcash; Bitcoin v0.1 built in Visual Studio
✓	Return style — `return x;` without parentheses in both
✓	Cross-platform #ifdef — both handle Windows/Unix conditionals explicitly

Diverging traits

✗	Spaces inside parens — hashcash uses `if ( x )`; Bitcoin uses `if (x)`
✗	Function naming — hashcash uses `parse_period`; Bitcoin uses `ProcessMessage`
✗	Variable naming — hashcash uses `validity_period`; Bitcoin uses `nValue` (Hungarian)
~	Language — C vs C++; some differences are expected and don't carry strong signal

The spaces-inside-parens divergence is the most notable, since it's a deliberate stylistic choice (/* c-file-style: "stroustrup" */ is declared at the top of hashcash.c). Bitcoin v0.1 consistently omits those spaces. Naming convention differences are partially explained by the C→C++ transition, but Hungarian notation in Bitcoin is a Windows-centric choice that doesn't appear in Back's C code.

/* hashcash.c — Adam Back, 2002–2011 */
/* -* Mode: C; c-file-style: "stroustrup" -* */

while ( (opt=getopt(argc, argv, "-a:b:c...")) >0 ) {  /* spaces inside parens */
    if ( bits_flag ) { multiple_bits = 1; }           /* lowercase_underscore names */
    return 0;                                          /* return without parens — matches Bitcoin */
}

/* Bitcoin v0.1 — main.cpp, Satoshi Nakamoto, 2009 */

bool ProcessMessage(CNode* pfrom, string strCommand, CDataStream& vRecv)  /* UpperCamelCase */
if (mapBlock.count(hashPrev))                               /* no spaces inside parens */
    int64 nValue = 0;                                       /* Hungarian notation */
    return true;                                            /* return without parens — matches hashcash */
}

The divergences account for E11's LR of 0.15. A programmer writing new code 7 years after their previous public project will drift stylistically — but the spaces-inside-parens pattern is stable enough to be informative. If Back wrote Bitcoin, he either changed this habit deliberately or the Bitcoin code represents a different working style than his personal projects.

Monte Carlo Results

Point-estimate LRs carry false precision. Ringger's numbers involve real judgment calls. Monte Carlo sensitivity analysis samples each LR log-uniformly over a ±2× range (±10× for E11, given higher uncertainty) and reports the distribution of posteriors across 1 million draws.

Prior	Model	Median	1st Pctile	P(>99%)	P(>99.9%)
Uniform 1/620	Ringger E1–E10	100.000%	99.993%	100.00%	100.00%
Uniform 1/620	+ Code E11–E13	99.999%	99.977%	100.00%	99.96%
Broad CS 1/10,000	Ringger E1–E10	99.994%	99.889%	100.00%	98.74%
Broad CS 1/10,000	+ Code E11–E13	99.989%	99.624%	99.88%	92.36%

The meaningful shift is in the broad CS prior's "P(>99.9%)" column: 98.74% → 92.36%. Under conservative assumptions about who could have written Bitcoin, the code evidence puts a non-trivial probability mass in the tail. That 7.6 percentage point drop represents real uncertainty the writing-only model doesn't capture.

What Would Break the Model

Taking the full model (Ringger + code evidence, combined LR = 99,066,240), what would it take to push the posterior probability below 99% from a uniform prior?

Combined positive LR (excl. E11): 165,110,400 × 2.0 × 2.0 = 660,441,600
Needed E11 to hit 99% (uniform): LR ≤ 0.000094
What that requires: P(style mismatch | Satoshi) ≤ 0.007%

For broad CS prior (1/10k): LR ≤ 0.0015
What that requires: P(style mismatch | Satoshi) ≤ 0.12%

To push below 99% with a uniform prior, you'd need to believe that if Back is Satoshi, the probability of his public code not matching Bitcoin's style is less than 0.007% — essentially that he couldn't have deliberately changed his coding conventions. That's indefensible. Deliberate stylometric obfuscation — different naming conventions, spacing choices, language selection — is trivially easy.

The broad CS prior breakeven (0.12%) is harder to dismiss but still very low. An LR(E11) of 0.0015 requires believing there's a 99.88% probability that Back's code, if he wrote Bitcoin, would match Bitcoin's style. No stylometric tool works that reliably.

The one thing that would actually matter. The calculation above treats the code comparison as fixed. What would genuinely move the probability is a direct forensic comparison of Back's post-2013 Blockstream C++ against Bitcoin v0.1 — using quantitative tools, not a 12-trait checklist. If a rigorous comparison found high similarity (top 5%), that updates E11 to LR > 1 and the model strengthens. If it found consistent dissimilarity, it confirms E11's counter-evidence. The problem: Back has no public C++ code post-2013 (E13). That absence is either the answer, or evidence of deliberate footprint management.

Verdict

The code evidence as a whole is slightly negative — net LR 0.60 — but doesn't change the headline. The full model puts the posterior at 99.9994% (uniform prior) and 99.9899% (broad CS prior) at point estimates, with Monte Carlo medians close to both.

The code-style divergence between hashcash and Bitcoin v0.1 is real. The spaces-inside-parens difference is consistent. The naming convention shift can be partially explained by C→C++ but not fully. These are genuine counter-signals that belong in any honest model.

They don't break the case because the positive evidence (165M combined LR) is simply too heavy. Code stylometry would need to be essentially perfect — LR < 0.001 — to tip the balance. That requires believing Back, if he is Satoshi, couldn't have chosen different spacing habits for a different project in a different language seven years later.

The more interesting finding is E13: Back has produced essentially no public C++ since 2013. Given that Blockstream's entire codebase is C++ (Elements, Lightning, libsecp256k1), this absence is conspicuous. Whether it's OPSEC or simply a CEO who stopped committing to public repos — that's the question the model can't answer, and the one that matters most.

All calculations are reproducible. The Ringger combined LR of 165,110,400 is exact. Monte Carlo uses 1,000,000 draws with log-uniform sampling over the stated ranges.