Prices two ways of delaying at a matched latency budget: the free-running clock
(batch at the tick) against an independent per-message draw. Measured by the
effective anonymity set of a release, and by MAP success -- how often the
observer single best guess is right -- because perplexity flatters a heavy tail.
The dominant result is that at the specified cover rate timing linkage is
essentially total under BOTH designs: the best guess is right 98-99% of the time.
That follows directly from the mixing~0 result of 3.10 -- a relay holds about one
message, and delay cannot manufacture ambiguity out of one message. Traffic buys
timing protection; delay does not.
Between designs the independent draw wins at equal cost, against the intuition
that batching should be safer: a tick is a hard boundary the observer can exclude
behind, whereas an exponential never excludes anything outright. But the margin is
a third of what the set size suggests (68% larger set, 19% better against the best
guess), so perplexity alone would have overstated the case for Poisson-style
mixing threefold.
A minimum release interval changes nothing, structurally: a zero-length gap is
instantaneous, so it never covers an arrival and is never sampled.
Section 5 updated -- the timing caveat is discharged, and the structural results
are now flagged as an upper bound on the anonymity a deployment actually gets.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
full_deanon counted any sender with an adversarial peer as identified. Capturing a
cascade tells the adversary WHICH message it is following, not WHO started it:
seeing an honest X transmit is equally consistent with X having received it from a
peer the adversary cannot watch. Separating the two gives
confidence = 1/(2 - a/d) = d/(2d - a)
for a adversarial peers of degree d. The path length does not enter -- the
conditioning event already fixes the relays as adversarial, so an honest X is not
one of them for this message.
The consequence is large. One peer of eight is worth 0.53, barely above the 0.5
prior, and 90% confidence needs a >= 8: every peer, which is the ECLIPSE condition
rather than the observation condition. Measured, attributable_frac_90 equals
eclipsed_frac exactly. At f_adv = 0.2, degree 8 that is 2.6e-6 against an
observed_frac of 0.83 -- the published figure overstates confident origination by
five orders of magnitude.
Stated in the report as a bracket rather than a replacement: full_deanon is the
upper bound on adversary capability, this is the lower bound, and the truth lies
between because the adversary also learns from the sender neighbourhood. Closing
that gap needs a k-hop observability model and is recorded as open in section 5.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The study started as a peering-degree question and grew well past it: propagation,
adversary exposure, deanonymization and time-to-link, reliability under uniform
and correlated churn, messaging redundancy, and cover traffic. The pd name no
longer describes it.
tools/simulators/blend/pd/ -> tools/simulators/blend/, package src/pd -> src/blend,
and reports/blend/pd/ -> reports/blend/. Moved with git mv so history follows.
The text substitutions are deliberately narrow. pd is also the conventional pandas
alias, and pandas genuinely has a pd.plotting submodule, so a blanket pd. -> blend.
rewrite would have corrupted four files. Only package-unambiguous forms were
changed: from pd.X, -m pd.X, pd.<our module>, PD_BYTES_BUDGET, src/pd, and the
pyproject name. All four import pandas as pd lines are untouched and verified.
Both READMEs reframed: peering degree is now presented as the primary axis that
ties the others together rather than as the subject, and the relative links, which
lost a directory level in the move, are corrected.
Verified after the move: ruff clean, 101 tests, 45 verify anchors, make targets,
the script shims, an end-to-end smoke run, and data/report_numbers.py still
reproducing the report tables from the checked-in evidence.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>