Tor Consensus Documents : How the Network Decides Its Own State How directory authorities vote, what consensus files contain, and how researchers parse them to monitor Tor health in real time.

Author: yottajunaid
Affiliation: Master-Darknet Research Initiative — Cybersecurity, Forensics & Anonymous Networks Research Division
Contact: https://yottajunaid.github.io/Master-Darknet/contact
Repository: https://yottajunaid.github.io/Master-Darknet

Abstract

The Tor network’s anonymous routing capability depends on a periodically produced document called the network consensus, which records the collectively agreed-upon state of the active relay population. Unlike centralised routing infrastructure, Tor derives this state through a multi-party voting process executed by a small set of hardcoded directory authorities (DAs). This paper provides a technically grounded analysis of the consensus lifecycle, verified against the current Tor directory protocol specification. We cover vote document structure, the consensus computation algorithm — including the case-based bandwidth-weight procedure as actually specified, not as a simplified optimisation — relay flag assignment rules and their version-dependent evolution, the microdescriptor subsystem, client consensus acquisition and validation, and the bandwidth measurement (bwauth) subsystem. We explicitly distinguish claims grounded in the current specification from those based on operational observation, historical behaviour, or research hypothesis. We correct several technical inaccuracies prevalent in prior informal treatments: the bandwidth-weight computation is a multi-case integer arithmetic procedure, not an optimisation problem; the Tor voting system is a majority-quorum mechanism, not a formal Byzantine-fault-tolerant protocol; flag assignment thresholds are relative and version-dependent, not fixed; and client signature validation is against a fraction of total DAs, not a hardcoded count. We identify six open research directions, explicitly labelled as exploratory, with stated assumptions and limitations.

Keywords: Tor network, directory authority, network consensus, onion routing, relay flags, bandwidth weights, microdescriptors, network health monitoring, anonymous communication, consensus method versioning, forensic analysis, sbws, shared randomness, quorum voting.

1. Introduction

The Tor network [^1] routes anonymous traffic through volunteer-operated relays. Before building any circuit, a Tor client must know which relays exist, what their cryptographic keys and capabilities are, and how much traffic they can carry. This information cannot be obtained from a single authoritative server without creating a surveillance and disruption target, yet it must be consistent across clients to prevent partitioning attacks.

The version-3 directory protocol [^2] addresses this through a collective voting mechanism: a small set of hardcoded directory authorities independently assess the relay population each hour, exchange signed vote documents, and together compute a single signed consensus that clients download and use for path selection. The consensus is the operational ground truth of the Tor network.

This paper analyses the consensus system with the following stated scope and limitations:

Every protocol claim is grounded in the current Tor directory specification [^2] or an identified Tor proposal, with version-dependent behaviour noted explicitly.
We do not present simplified mathematical abstractions as exact protocol descriptions. Where the specification defines a case-based procedure, we present cases rather than substituting a notionally equivalent single equation.
Claims based on operational observation, research hypothesis, or extrapolation are explicitly labelled as such.
We make no claim to be the “first” comprehensive treatment of this topic; the specification, Tor Metrics documentation, and prior measurement literature [^13] [^14] address many of these topics.

The remainder of the paper is organised as follows. Section 2 provides background on the directory system. Section 3 describes the DA infrastructure. Section 4 explains the voting protocol and consensus computation, including the bandwidth-weight procedure. Section 5 documents the consensus document format. Section 6 analyses relay flag assignment rules. Section 7 covers the bandwidth measurement subsystem. Section 8 addresses microdescriptors. Section 9 covers client acquisition and validation. Section 10 presents a health-monitoring methodology. Section 11 discusses adversarial considerations with explicit caveats. Section 12 examines forensic implications. Section 13 identifies open research directions. Section 14 surveys related work. Section 15 concludes.

2. Background: The Tor Directory System

2.1 Historical Context

Tor’s original directory system used a single trusted server to distribute a signed relay list, creating both a censorship point and a surveillance risk. The version-2 protocol introduced multiple DAs publishing independent network-status documents, with clients trusting statements attested by a majority. The version-3 protocol, in use since the 0.2.0.x series, replaced client-side correlation of independent documents with a collective consensus: authorities vote on a shared document, eliminating a class of partitioning attacks that could arise from clients receiving inconsistent combinations of status documents [^2].

2.2 Architectural Layers

The directory system comprises four functional layers:

Directory Authorities. A hardcoded set of servers that collect relay descriptors, vote on network state, and publish the consensus.
Fallback Directory Mirrors. High-uptime relays that cache and serve the consensus to clients, reducing load on DAs. The fallback list is compiled at each Tor release from relays meeting documented uptime and bandwidth criteria and may differ between Tor versions.
Bandwidth Authorities (bwauths). A subset of DAs running bandwidth scanners (currently the sbws scanner [^10]) that contribute empirically measured bandwidth values to their votes.
Clients. Every Tor instance that downloads and uses the consensus for path selection.

2.3 Timing Model

The consensus is produced on an hourly cycle. The precise timing parameters — the vote-collection window (VoteSeconds) and the signature-distribution window (DistSeconds) — are set by values in vote documents; the consensus values for these parameters are the medians across votes [^2]. The timing values observed nominally (vote exchange around HH:40, distribution around HH:50) represent the most common configuration, not a fixed protocol constant. Similarly, the consensus valid-after, fresh-until, and valid-until timestamps are medians of the corresponding values in participating votes.

3. Directory Authority Infrastructure

3.1 The Authority Set

As of early 2025, the Tor network operates nine directory authorities whose identity-key fingerprints are hardcoded in released Tor software. Their nicknames and publicly documented affiliations are shown in Table 1. Operators, locations, and the number of authorities are subject to change; readers should consult current Tor source code for the authoritative list.

Table 1: Tor Directory Authorities (publicly documented, early 2025)

Nickname	Operator / Affiliation (public)	Location
maatuska	Linus Nordberg (individual)	SE
tor26	Tor Project	AT
dizum	Alex de Joode (individual)	NL
Serge	Bandwidth authority node	US
longclaw	Riseup Networks	US
bastet	Tor Project	US
Faravahar	Sina Rabbani (individual)	US
gabelmoo	Sebastian Hahn (individual)	DE
dannenberg	Andreas Jonsson (individual)	SE

3.2 DA Key Infrastructure

The specification [^2] mandates a two-tier key structure:

V3 Identity Key. A long-term RSA key stored offline and used only to sign medium-term signing-key certificates. Its SHA-1 fingerprint is hardcoded in Tor. The SHA-1 fingerprint is used here as an opaque identifier, not as a cryptographic commitment; SHA-1 collision resistance is not relied upon for security in this context. The specification does not mandate a specific RSA key size for DA identity keys; the Tor Project documents recommend strong keys, and operational deployments are understood to use RSA-3072 or larger, but exact sizes per authority are not publicly specified.
Signing Key. A medium-term key (rotated periodically) used to sign votes and consensus documents. The signing key is certified by the identity key via a key-certificate document. Historical deployments used RSA-1024 signing keys; the specification does not mandate a current minimum. Newer Tor deployments support Ed25519 identity keys in some contexts, though the DA key hierarchy remains primarily RSA-based. Researchers should consult current Tor source and DA operator announcements rather than relying on historical documentation for specific key types in current use.

3.3 Voting Quorum: Operational Threshold vs. Formal Guarantees

Publication Threshold

The specification [^4] states that the consensus is served at the standard URL if it has been signed by a majority of authorities. With nine authorities, this means five or more signatures. A consensus signed by fewer than a majority is served by DAs at alternate URLs once the voting period ends, regardless of signature count.

What This Is Not: A Clarification on BFT

The Tor voting system is not equivalent to a classical Byzantine-fault-tolerant (BFT) consensus protocol.

Classical BFT protocols such as PBFT [^20] and HotStuff [^21] provide agreement and liveness guarantees under asynchronous networks for up to $f$ Byzantine participants given $n > 3f$ total participants. Tor’s directory voting does not provide these guarantees for the following reasons:

Vote documents are exchanged over the public internet without a round-based synchronisation protocol providing agreement under asynchrony.
There is no mechanism preventing a coalition of DAs from signing a different consensus body than the one computed from honest votes; honest minority DAs cannot force agreement.
A five-DA majority coalition can produce a consensus with arbitrary content; other DAs have no recourse once the coalition signs.
The system’s resilience depends on social trust, organisational diversity, and the political cost of coalition formation — not on cryptographic agreement guarantees.

Applying the $n > 3f$ theorem to Tor’s nine DAs to imply formal BFT guarantees (as some informal analyses have done) is incorrect. With $n = 9$ and $f = 2$ arbitrary Byzantine failures, BFT theory would require $9 > 6$ — true, but only under the synchrony and agreement assumptions of formal BFT, which Tor does not implement.

The Tor voting system is more accurately described as a majority-quorum, threshold-signature mechanism whose operational resilience derives from diversity of DA operators across organisations and jurisdictions.

4. The Voting Protocol and Consensus Computation

4.1 Vote Document Structure

At the vote-publication time each participating DA computes and distributes a signed vote document to all other DAs. The specification [^2] defines the vote document to include:

vote-status vote — distinguishes the document from a consensus.
consensus-methods — the set of consensus-method version numbers supported by this DA.
Timing fields: valid-after, fresh-until, valid-until, voting-delay.
known-flags — the set of relay flags this DA may assign.
params — integer consensus parameters voted on by this DA.
Per-relay status entries: r (identity), s (flags), v (version), w (bandwidth), p (exit policy).
Shared-randomness commitment/reveal data (consensus method 23 and later [^8]).
DA signature.

4.2 Consensus Method Selection

Before computing the consensus, each DA determines the consensus method to use: the highest method number supported by more than two-thirds of voting DAs, provided the computing DA also supports it [^2]. If the computing DA does not support that version, it falls back to the newest version it does support (likely producing a consensus that fewer DAs will countersign). As of Tor 0.4.3.1-alpha, authorities no longer advertise or negotiate any method below 28; clients may assume they will not encounter a valid current consensus using any method below 25.

This versioning mechanism affects the interpretation of nearly every field in the consensus; researchers analysing historical archives must identify the consensus method of each document before applying parsing rules. As of 2025, the highest defined method is 35.

4.3 Relay Inclusion Rule

Correction from prior informal treatments: A relay status entry is included in the consensus (for consensus method 22 and later) if it is listed by more than half of the total authorities — that is, more than half of all nine DAs, not merely more than half of those who submitted votes [^2]. This means five or more DAs must include a relay for it to appear in the consensus, regardless of how many DAs participated in the current voting round. Relays not meeting this threshold are omitted.

4.4 Per-Field Computation Rules

For each included relay, field values are derived from votes as follows [^2]:

Flags: A flag is set in the consensus if it is set by more than half of the authorities who include that flag in their known-flags. The denominator for flag votes is the set of DAs that track that flag, not the total DA count.
Bandwidth (w line): For consensus method 5 and later, the consensus bandwidth is the low-median of bandwidth values across votes that include a w line for that relay. If three or more DAs provide a Measured= value (method 6 and later), the consensus uses the median of those measured values. Relays without three measured values receive Unmeasured=1 (method 17 and later). All bandwidth values are in KB/s and are capped at 10240 KB/s in votes.
Version: The version string most commonly listed across votes, with ties broken in favour of the more recent version.
Exit policy summary: The most commonly listed policy for the chosen descriptor.

4.5 Bandwidth Weight Computation: The Actual Algorithm

Audit finding: An earlier version of this paper presented the bandwidth weight computation as a single optimisation objective. That was a simplification that misrepresents the protocol. The actual computation, as specified in [^2] (section “Computing Bandwidth Weights”), is a case-based linear system solved in integer arithmetic.

Let $G$ , $M$ , $E$ , $D$ be the total consensus bandwidth (in KB/s) of Guard-only, non-flagged, Exit-only, and Guard+Exit relays respectively, and $T = G + M + E + D$ . Let $\text{ws} = \text{bwweightscale}$ (default 10000; a parsing bug in methods below 31 caused this parameter to be ignored under certain conditions [^2]).

The specification defines three top-level cases:

Case 1: $E \geq T/3$ and $G \geq T/3$ (neither Exit nor Guard bandwidth is scarce). The solution is:

W_{gd} = W_{ed} = W_{md} = \text{ws}/3

W_{ee} = \frac{\text{ws}(E+G+M)}{3E}, \quad W_{me} = \text{ws} - W_{ee}

W_{mg} = \frac{\text{ws}(2G - E - M)}{3G}, \quad W_{gg} = \text{ws} - W_{mg}

Case 2: $E < T/3$ and $G < T/3$ (both are scarce). Let $R$ be the more scarce class and $S$ the less scarce. Two sub-cases apply:

Subcase a ( $R + D < S$ ): All $D$ bandwidth is devoted to the scarce class; $W_{gg} = W_{ee} = \text{ws}$ ; $W_{mg} = W_{me} = W_{md} = 0$ ; $W_{ed}$ or $W_{gd}$ is set to $\text{ws}$ depending on which class is more scarce.
Subcase b ( $R + D \geq S$ ): A balancing condition is attempted; if any computed weight falls out of the valid range $[0, \text{ws}]$ , a fallback with $W_{gg} = W_{ee} = \text{ws}$ is used.

Case 3: Exactly one of $E < T/3$ or $G < T/3$ (one is scarce). Again two sub-cases apply depending on whether the scarce class plus $D$ exceeds $T/3$ .

What this means in practice: The weight computation is an implementation-specified branching procedure, not a solved continuous optimisation. All arithmetic is integer arithmetic to ensure all DAs reach identical results given identical inputs [^2]. The additional weights for directory requests and “middle” weighting are currently set to $\text{ws}$ with minor exceptions defined in the spec. Researchers implementing or analysing this computation should read the full specification text rather than relying on any summary.

5. Consensus Document Format

5.1 Header Fields

The annotated consensus header below is illustrative. All field values are determined by the voting process and vary across documents.

network-status-version 3 microdesc
  ; "microdesc" = microdescriptor consensus flavor
vote-status consensus
  ; Distinguishes from vote documents
consensus-method 35
  ; Highest method supported by >2/3 of voting DAs.
  ; Governs interpretation of all subsequent fields.
valid-after 2025-05-28 10:00:00
  ; Median of valid-after values in participating votes
fresh-until 2025-05-28 11:00:00
  ; Clients SHOULD fetch new consensus after this
valid-until 2025-05-28 13:00:00
  ; Clients SHOULD NOT use after this; "reasonably live"
  ; up to 24h past valid-until in bootstrapping fallback
voting-delay 300 300
  ; Medians of VoteSeconds and DistSeconds from votes
client-versions ...
  ; Recommended if listed by >half of DAs with this field
known-flags Authority BadExit Exit Fast Guard ...
  ; Union of all flags known by any voting DA
params bwweightscale=10000 maxunmeasuredbw=20 ...
  ; Low-median per param; only included if voted for by
  ; majority of total authorities (or >=3 for some)
shared-rand-current-value 10 ...
  ; Current shared random value (method 23+; see text)

5.2 The Shared Random Value

Beginning with consensus method 23 [^8], the consensus includes a shared random value derived through a commit-then-reveal protocol among DAs. Each DA commits to a random value in one voting period and reveals it in the next; the consensus shared random value combines the revealed values of DAs that successfully completed both phases. This value rotates the set of HSDirs responsible for v3 onion service descriptors each consensus period [^6].

5.3 Relay Status Entries

The annotated relay entry below is illustrative, shown in the microdescriptor consensus format.

r RelayNick BASE64IDENTITY== 2025-05-28 08:14:00 IP 9001 0
  ; Nickname, base64(SHA-1 of RSA identity key),
  ; publication time, IPv4 address, ORPort, DirPort.
  ; NOTE: In method 33+, the publication timestamp in
  ; microdesc consensuses is set to a fixed dummy value.
a [2001:db8::1]:9001
  ; IPv6 ORPort (method 27+ in microdesc flavor)
s Exit Fast Guard Running Stable V2Dir Valid
  ; Consensus flags; see Section 6 for assignment rules
v Tor 0.4.8.11
  ; Most-voted version string; ties resolved for recency
pr Cons=1-2 Desc=1-2 DirCache=2 ...
  ; Protocol version bitmaps (method 25+)
w Bandwidth=12500 Unmeasured=0
  ; Low-median of "w" values in votes; KB/s, capped at
  ; 10240 in votes. Unmeasured=1 if <3 Measured= values.
m sha256/BASE64MDHASH
  ; SHA-256 of microdescriptor (no trailing = in method 30+)

On SHA-1 in relay fingerprints: The BASE64IDENTITY field encodes the SHA-1 hash of the relay’s RSA identity key. SHA-1 is used here as a compact opaque identifier under which the relay is indexed in the protocol, not as a collision-resistant cryptographic binding for security-critical operations. The practical risk of SHA-1 collisions in relay fingerprints has been studied but is not the primary cryptographic concern in the current relay authentication model, which also uses Ed25519 cross-certification for v3 hidden services.

6. Relay Flag Assignment: Specification and Caveats

The specification [^3] explicitly states: “Later directory authorities MAY do things differently, so long as clients keep working well. Clients MUST NOT depend on the exact behaviors in this section.” Flag assignment rules are therefore default behaviour that has evolved across Tor versions and may continue to evolve. Thresholds defined relative to the current relay population (such as percentile-based cutoffs for Fast and Guard) change each consensus period as the relay population changes. Table 2 presents the current specification-defined rules with caveats noted.

Table 2: Relay Flag Assignment Rules [^3] (default behaviour as of current spec)

Flag	Assignment Condition
`Valid`	Not running a known-broken Tor version; not blacklisted by this DA.
`Running`	DA connected to all published ORPorts within last 45 minutes. IPv6 reachability checked only if `AuthDirHasIPv6Connectivity` is set on this DA; different DAs may apply different criteria.
`Stable`	Weighted MTBF ≥ median for known active relays, OR weighted MTBF ≥ 7 days. Weighting decays over approximately one month. Relays running versions known to drop circuits prematurely never receive `Stable`.
`Fast`	Bandwidth in top 7/8 of active relays, OR ≥ 100 KB/s. Uses measured bandwidth if ≥ 500 relays have measurements (`MinMeasuredBWsForAuthToIgnoreAdvertised`, configurable); otherwise uses advertised.
`Guard`	`Fast` ∧ `Stable` ∧ relay is familiar ∧ weighted fractional uptime (WFU) ≥ median WFU among familiar active relays ∧ bandwidth ≥ `AuthDirGuardBWGuarantee` (default 2 MB/s) OR in top-25% fastest ∧ `V2Dir`. The `V2Dir` requirement was added in 0.3.3.x. A relay is familiar if 1/8 of all active relays appeared more recently than it, OR it has been present for a few weeks.
`Exit`	Exits permitted to ≥ 1/8 address space on each of ports 80 and 443. (Changed from “two of 80, 443, 6667” in Tor 0.3.2.)
`HSDir`	`Stable` ∧ `Fast` ∧ relay announces hidden-service-dir support ∧ uptime ≥ `MinUptimeHidServDirectoryV2` (default 96 hours). The `Stable` requirement was formalised in proposal 243, implemented in 0.2.7.
`V2Dir`	Open DirPort or `tunnelled-dir-server` in descriptor, running a version that serves what clients need. Relays setting `DirCache 0` are ineligible.
`BadExit`	DA believes relay exhibits exit misbehaviour. May be manual or automated.
`MiddleOnly`	DA judges relay unsuitable except as middle relay. Automatically removes `Exit`, `Guard`, `HSDir`, `V2Dir` from same entry (method 32+). Added in 0.4.7.2-alpha.
`StaleDesc`	Descriptor published > 18 hours ago. Added in 0.4.0.1-alpha.
`Authority`	This DA considers the relay to be a DA.
`NoEdConsensus`	DAs do not vote for this; produced by the consensus algorithm (method 22+) for relays without agreed Ed25519 key.

6.1 Critical Caveats on Flag Thresholds

Thresholds are relative, not absolute. Fast and Stable depend on the distribution of bandwidth and uptime across the live relay population at the time of the vote. A relay’s flag status can change across consensus periods without any change in its own configuration, simply because the broader network changed.
DAs apply independent policies. Individual DAs may have different AuthDir* configuration values. Operational reports from relay operators confirm that DAs sometimes disagree on flag assignment for the same relay. The consensus flag is then the majority vote over these independent DA opinions, not the output of a single shared algorithm.
The Guard flag is eligibility, not selection. Holding the Guard flag makes a relay eligible for the guard position. Client guard selection is governed by the path-selection specification [^7], which applies additional criteria including bandwidth weights, family constraints, and guard-persistence rules. These are distinct from flag assignment.
“Familiar” is defined by exponentially weighted observation history. The exact weighting function for WFU uses exponential decay; the specification states the goal but does not fully constrain the numerical implementation.

7. The Bandwidth Measurement Subsystem

7.1 Motivation and Role

Relays self-report their bandwidth capacities in router descriptors. These values are trivially inflatable and unverified. Bandwidth authorities (bwauths) — currently a subset of DAs running the sbws scanner [^10] — independently measure relay throughput and contribute Measured= values to their vote documents. If three or more bwauths provide measured values for a relay (consensus method 6 and later), the consensus bandwidth for that relay is the median of those measured values, overriding advertised bandwidth [^2].

7.2 Measurement Procedure

The sbws scanner builds two-hop circuits through each target relay (looping back to the scanner’s own endpoint), measures achieved throughput over multiple samples at randomised times, normalises the result relative to the network-wide median, and writes output to a V3BW bandwidth file [^10]. An illustrative fragment is shown below.

1716883200
version=1.4.0
software=sbws
...
node_id=$FINGERPRINT1 bw=12500 nick=ExampleRelay
  error_stream_creation=0 error_circ_creation=3
node_id=$FINGERPRINT2 bw=450 nick=SmallRelay

7.3 Operational Limitations

Measurement timing manipulation. A relay detecting scanner circuit patterns could temporarily increase throughput during measurement windows. sbws uses randomised timing as a partial mitigation. This is an operational concern documented by the sbws project, not a formally proven attack.
Scanner unreachability. If a bwauth’s circuits to a relay fail, the relay receives no Measured= value. With fewer than three bwauth measurements, the relay is capped at maxunmeasuredbw (default 20 KB/s) and marked Unmeasured=1.
Coverage gaps. Not all DAs run bwauths; the number has varied operationally. A relay may receive measurements from fewer than three bwauths even with fully honest measurement attempts.
Authority relays are intentionally unmeasured. The spec notes that authority-flagged relays should not receive a Measured= value in bwauth votes, so they remain unmeasured and reserved for DA duties.

8. The Microdescriptor Subsystem

8.1 Design Rationale

Full server descriptors are several kilobytes each. With thousands of relays, hourly full-descriptor downloads would impose prohibitive bandwidth cost on constrained clients. The microdescriptor system (consensus method 8) provides compact per-relay documents containing only the fields required for circuit construction [^2]. The consensus lists each relay’s microdescriptor by its SHA-256 hash; clients download only those whose hash changed since their previous consensus.

8.2 Microdescriptor Content

A microdescriptor contains [^2]:

The relay’s ntor onion key: a Curve25519 public key used as the ephemeral DH input in the ntor handshake [^18], which is the default circuit-creation handshake. (The older TAP handshake using RSA is retained for legacy compatibility but not used in current circuit creation by default.)
Declared relay family membership, used to enforce the constraint that no circuit uses two relays declared to be co-operated.
A condensed exit policy summary allowing clients to determine exit eligibility for a target port.
Identity key cross-certification data (Ed25519 id from method 22; RSA id from method 18).

8.3 Cache Efficiency

The fraction of microdescriptors changing between consecutive consensus periods is empirically small because relays change their ntor keys infrequently [^13]. The exact fraction varies with network activity (relay restarts, key rotations, policy changes) and should be measured from current consensus archives rather than assumed from older studies.

9. Client Consensus Acquisition and Validation

9.1 Acquisition

The specification [^5] describes acquisition as follows:

When no live consensus is available, the client downloads from a randomly chosen fallback directory mirror or, if none are available, directly from a DA. Clients prefer fallbacks to authorities.
Once a live consensus is available, the client selects directory caches from the consensus for subsequent downloads.
Clients do not build circuits until they have a live consensus and a sufficient proportion of relay descriptors (configurable via torrc and consensus parameters).

The initial consensus fetch is made without Tor anonymity, as no circuit can be built before the client knows the network state. This is an accepted design limitation of the bootstrap process [^17].

9.2 Download Timing

To avoid cache flooding, clients choose a randomised fetch time. The specification defines this precisely as: uniformly at random from the interval between the time 3/4 into the first interval after the consensus is no longer fresh, and 7/8 of the time remaining before the consensus is invalid [^5]. Clients may use a cached consensus up to 24 hours past valid-until as a “reasonably live” fallback during bootstrapping.

9.3 Consensus Validation

The specification [^2] requires clients to:

Accept a consensus only if valid-after ≤ now ≤ valid-until (with the 24-hour bootstrapping exception).
Verify that the consensus is signed by a majority of authorities from the client’s hardcoded authority list. This is a fraction of total known authorities, not a hardcoded count; if the authority set size changes, the threshold changes accordingly.
Discard any network-status documents not explicitly requested.

Threshold clarification: The publication threshold (five of nine signatures required before DAs serve the consensus at the standard URL) and the client acceptance threshold (majority of the client’s hardcoded authority list) are related but distinct concepts. A consensus signed by fewer than a majority is served by DAs at alternate URLs but should not be accepted as valid by standard clients. Edge-case behaviour in partial-consensus situations is implementation-dependent; researchers should consult current Tor source code alongside the specification.

9.4 Differential Consensus Downloads

Since Tor 0.3.1, clients may request a diff between their cached consensus and the current one using an ed-text-diff format, rather than the full document. This substantially reduces directory bandwidth consumption and is supported for both ns and microdesc consensus flavors.

10. Real-Time Network Health Monitoring

10.1 Data Sources

The Tor Metrics Collector [^9] archives consensus documents, bandwidth files, relay descriptors, and extra-info descriptors, extending back to 2007. This archive is the primary dataset for network health research. Recent consensuses (last 72 hours) are available uncompressed; historical data is available as compressed tarballs.

10.2 Parsing Considerations

Any consensus parser must account for:

Consensus method dependence. Field presence and semantics change with the method number. A parser treating all consensus documents identically will misinterpret historical documents.
Format changes across methods. Method 30 removes trailing = from ntor-onion-key hashes; method 33 sets the r line publication timestamp to a fixed dummy value in microdesc consensuses; method 34 removes package lines. Parsers must implement per-method behaviour switches.
Missing fields. Not all relays have all line types; parsers must handle missing w, p, or a lines.

The Tor Project maintains stem [^11] (Python) and metrics-lib [^12] (Java) as parsing libraries that track specification changes. These are preferable to ad-hoc parsers for research use.

10.3 Health Metrics Derivable from Consensus Data

All metrics should be computed per-document rather than averaged across documents, as averaging across a changing relay population can obscure meaningful variation.

Table 3: Illustrative Network Health Metrics from Consensus Data

Metric	Definition and Known Limitations
Running relay count	Count with `Running` flag. Simple; does not reflect bandwidth.
Guard-flagged relay count/bandwidth	Count and sum of `Bandwidth=` for `Guard` relays. Bandwidth values mix measured and unmeasured relays.
Exit-flagged relay count/bandwidth	Analogous to above for `Exit` relays.
DA participation count	Number of DA signatures in consensus footer. Below 9 is noteworthy; below 5 means the consensus should not have been served at the standard URL per spec.
Unmeasured relay fraction	Fraction with `Unmeasured=1`. Reflects bwauth coverage.
Version distribution entropy	Shannon entropy over relay version strings. Proxy for software diversity.
Relay count by AS / country	Requires external GeoIP/ASN mapping; accuracy depends on mapping database quality.

10.4 Inherent Limitations of Consensus-Based Monitoring

The consensus is updated hourly; intra-hour events are invisible. Vote documents and DA health checks provide finer-grained data.
Consensus bandwidth values are DA estimates, not real-time throughput measurements.
Relay self-reported data (family declarations, contact info) is unverified and may be misleading.
The Tor Metrics consensus-health page (https://consensus-health.torproject.org) provides operational monitoring and is a useful complement to offline analysis.

10.5 Historically Documented Anomalies

Network events documented in prior literature and visible in consensus archives include:

Sybil relay clusters. Winter et al. [^14] identified coordinated relay families exhibiting patterns consistent with Sybil injection, detectable through clustering on consensus metadata.
DA participation drops. Periods with fewer than nine DA signatures are directly observable in consensus footer data.
Version adoption rates. Relay uptake of new Tor versions following security releases is measurable from version-string distributions across consecutive consensus documents.

11. Adversarial Considerations

11.1 Single-DA Adversarial Influence

A single compromised or malicious DA can unilaterally assign or withhold flags for relays in its vote, but cannot change the consensus flag for any relay for which the other DAs disagree — flag assignment requires majority among DAs tracking that flag. A single bwauth can submit manipulated measured bandwidth values for relays it has measured, but this is moderated by the median-over-three-or-more-values rule: a single outlier bwauth cannot shift the consensus bandwidth by more than its position in the ordered set of measured values would allow.

11.2 Majority Coalition

A coalition of five or more DAs can produce a consensus with arbitrary content: assigning or denying any flag, setting arbitrary bandwidth weights, excluding honest relays, and controlling the shared random value. This represents a catastrophic failure mode that would fundamentally undermine the network’s anonymity properties. The primary defence is the social and organisational diversity of DA operators (different entities, jurisdictions, and incentives), raising the political and legal cost of forming such a coalition. This is a social defence, not a cryptographic one.

11.3 Network-Level Disruption

An adversary without DA access can disrupt inter-DA communication to prevent vote exchange, potentially causing voting rounds to fail. Clients are partially resilient: they can use cached consensuses up to 24 hours past expiry in bootstrapping contexts. Adversarial directory mirrors serving stale consensuses are mitigated by client-side signature verification.

11.4 Relay Sybil Attacks

The specification includes a Sybil flag and a per-IP relay limit (default two per IP, configurable via AuthDirMaxServersPerAddr). Relays beyond this limit are included in votes but without Running or Valid flags. This is a per-IP heuristic with no cryptographic Sybil defence [^24]; adversaries controlling diverse IP ranges can inject many relays while avoiding the per-IP limit.

12. Forensic Implications of Consensus Data

The Tor Metrics archive [^9] provides a long-running historical record of relay presence and characteristics. Its forensic utility includes:

Relay identity tracking. A relay’s RSA identity fingerprint is stable across IP changes. The consensus archive supports reconstruction of a relay’s operational history: first appearance, IP evolution, last presence.
Coordinated relay detection. Relays appearing and disappearing simultaneously, sharing ContactInfo strings, or exhibiting similar operational patterns are detectable by clustering analysis. This approach has been applied to identify suspicious relay families [^14].
HSDir assignment inference. Given a consensus document and a v3 onion address, it is computationally feasible to determine which relays were responsible for serving that address’s descriptor, using the shared random value and the v3 HSDir selection algorithm [^6].
Exit policy evolution. Exit policy changes are visible in p line changes across consecutive documents.

Scope caveat: Forensic inferences from consensus data concern relay (exit node) characteristics, not user identities or hidden service operator identities. The consensus contains no client traffic data. HSDir assignment inferences require additional corroborating information to be operationally meaningful.

13. Open Research Directions

Direction 1: Anomaly Detection on Consensus Time Series (Exploratory)

Hypothesis: Machine-learning models trained on historical consensus data could detect anomalous relay behaviour patterns earlier than manual monitoring.

Limitations: Ground-truth labels for historical anomalies are partial. The relay population changes continuously, limiting model generalisability. Many anomalous events are indistinguishable from operator mistakes on consensus data alone. Any deployed system would need to avoid becoming a tool for flagging legitimate-but-unusual relays.

Open question: What features of consensus time series are most predictive of documented adversarial events, and what labelled dataset size is sufficient for reliable classification?

Direction 2: Directory Authority Governance Models (Speculative)

Hypothesis: The static nine-DA structure could be made more dynamic or expanded to improve resilience and decentralisation.

Limitations: DA membership is maintained through social and operational consensus and requires modifying hardcoded values in Tor releases. Expanding the DA set increases coordination surface. Replacing the voting model with a formal BFT protocol requires significant protocol redesign incompatible with the existing specification, and prior proposals for decentralised directories have not been adopted. Decentralisation trades consistency and auditability for reduced trust concentration — the tradeoffs are not uniformly positive.

Open question: What governance and protocol mechanisms could allow the DA set to evolve without coordinated source-code updates across all Tor clients?

Direction 3: Consensus Manipulation Risk Quantification (Hypothetical)

Hypothesis: The probability of a user’s circuit being fully adversary-controlled as a result of DA-level bandwidth manipulation is quantifiable under stated assumptions.

Limitations: A formal model requires specifying adversary capabilities, the client’s current path-selection algorithm (which has evolved), and network conditions. Prior path-selection analysis [^15] [^16] addresses relay-level manipulation, not DA-level consensus manipulation, and is specific to the network state at time of study. Isolating the marginal effect of consensus-level manipulation is methodologically difficult.

Open question: Can tight bounds on adversarial circuit co-location probability be derived as a function of colluding-DA count and bandwidth manipulation strategy, under assumptions consistent with current path-selection behaviour?

Direction 4: Differential Privacy for Bandwidth-Adjacent Data (Exploratory)

Hypothesis: Differential privacy [^19] mechanisms could be applied to relay-reported statistics that inform the consensus, reducing inference risk.

Limitations: Applying DP to consensus bandwidth values would reduce utility for path selection. The tradeoff between privacy budget and selection accuracy has not been characterised for Tor. The more natural targets for DP are extra-info descriptor statistics (traffic volumes, stream counts), not DA-computed consensus values. DP on bandwidth could systematically bias load distribution.

Open question: What is the minimum achievable privacy budget for bandwidth-related data while maintaining path-selection performance within a defined tolerance, and is any privacy benefit achievable at the extra-info layer without affecting the consensus?

Direction 5: Real-Time Consensus Stream Processing (Practical but Unvalidated)

Hypothesis: Automating consensus ingestion, parsing, and metric computation in a streaming pipeline would reduce anomaly-detection latency compared to batch analysis.

Limitations: Consensuses are published once per hour; the primary latency reduction is in automation, not data freshness. For genuine real-time monitoring, DA vote documents (available pre-consensus) and DA health checks provide more timely signals. A streaming pipeline must handle consensus-method versioning, failed fetches, and non-trivial DA signature verification.

Open question: What is the minimum achievable end-to-end latency from consensus publication to computed health metrics, and is this latency operationally meaningful given the hourly update frequency?

Direction 6: Formal Specification Verification (Long-Term Aspiration)

Hypothesis: A machine-verifiable formal specification of the consensus voting algorithm would reduce specification ambiguity and catch implementation bugs.

Limitations: The current spec contains explicit unresolved edge cases (e.g., MTBF computation with less than four days of data, marked “XXXX”). Formal verification requires resolving these ambiguities first. The consensus-method versioning system means a formal spec must model multiple protocol versions simultaneously. Verification frameworks (Coq [^22], TLA+ [^23]) have been applied to simpler distributed algorithms; the consensus algorithm’s multi-case arithmetic and versioning present non-trivial modelling challenges. A formal spec would be a research artifact, not a replacement for the prose specification.

Open question: Which component of the consensus algorithm (flag assignment, bandwidth weight case analysis, or relay inclusion decision) is most tractable for initial formalisation, and what would the estimated verification cost be?

The foundational description of Tor and its directory system is Dingledine, Mathewson, and Syverson [^1]. The normative reference for all consensus system details is the Tor directory protocol specification [^2], actively maintained by the Tor Project.

Loesing et al. [^13] established consensus-archive analysis as a methodology for Tor network measurement. Winter et al. [^14] characterised relay-ecosystem properties including flag distribution and identified observed Sybil behaviour; their findings reflect the network state at their publication time.

Bauer et al. [^15] and Johnson et al. [^16] analysed how bandwidth-weighted path selection can be exploited by adversarial relays. Both studies address relay-level manipulation; they establish the path-selection model relevant to consensus manipulation risk but do not address DA-level manipulation directly.

The bandwidth measurement system is documented in sbws project documentation [^10]. The shared randomness protocol is specified in Tor Proposal 250 [^8]. The path-selection specification [^7] is the authoritative reference for how consensus data is used in circuit construction.

Castro and Liskov [^20] and Yin et al. [^21] are cited as background on formal BFT theory to clarify what Tor’s system does not provide; they are not proposed for adoption.

15. Conclusion

The Tor directory consensus is a majority-quorum voting mechanism that produces a shared, authenticated view of the relay network. Its design reflects deliberate choices whose properties and limitations are important to state precisely:

The system is a majority-quorum, threshold-signature mechanism, not a formal BFT protocol. Its resilience is social and organisational, not cryptographic.
Flag thresholds are relative to the current relay population and evolve continuously; no hardcoded threshold is correct across all consensus periods or consensus methods.
The bandwidth-weight computation is a multi-case integer arithmetic procedure, not a solved optimisation problem.
Client signature validation is against a fraction of the client’s hardcoded authority list, with distinct publication and acceptance thresholds.
The system has evolved through 35 documented consensus methods; any analysis must identify the specific method applicable to each document under study.

We have corrected these specific inaccuracies from prior informal treatments, verified all protocol claims against the current specification [^2], and identified six open research directions with explicit assumptions and limitations. The most practically important constraint is version dependence: protocol behaviour is not uniform across the history of the Tor network, and any research using the consensus archive must account for the specific consensus-method value in each document analysed.

References

[^1]: R. Dingledine, N. Mathewson, and P. Syverson, “Tor: The second-generation onion router,” in Proc. 13th USENIX Security Symposium, San Diego, CA, USA, Aug. 2004, pp. 303–320.

[^2]: N. Mathewson et al., “Tor Directory Protocol, Version 3,” Tor Project, Tech. Spec. (dir-spec), actively maintained. [Online]. Available: https://spec.torproject.org/dir-spec [Accessed: May 2025]

[^3]: N. Mathewson et al., “Tor Directory Protocol: Assigning Flags in a Vote,” Tor Project, Tech. Spec. [Online]. Available: https://spec.torproject.org/dir-spec/assigning-flags-vote.html [Accessed: May 2025]

[^4]: N. Mathewson et al., “Tor Directory Protocol: Publishing the Signed Consensus,” Tor Project, Tech. Spec. [Online]. Available: https://spec.torproject.org/dir-spec/publishing-consensus.html [Accessed: May 2025]

[^5]: N. Mathewson et al., “Tor Directory Protocol: Client Operation,” Tor Project, Tech. Spec. [Online]. Available: https://spec.torproject.org/dir-spec/client-operation.html [Accessed: May 2025]

[^6]: N. Mathewson, G. Kadianakis, D. Goulet et al., “Tor Rendezvous Specification — Version 3,” Tor Project, Tech. Spec. [Online]. Available: https://spec.torproject.org/rend-spec-v3

[^7]: N. Mathewson et al., “Tor Path Specification,” Tor Project, Tech. Spec. [Online]. Available: https://spec.torproject.org/path-spec

[^8]: N. Mathewson and G. Kadianakis, “Tor Proposal 250: Random Number Generation During Voting,” Tor Project, 2015. [Online]. Available: https://spec.torproject.org/proposals/250-commit-reveal-consensus-randomness.txt

[^9]: K. Loesing and the Tor Project, “Tor Metrics Portal.” [Online]. Available: https://metrics.torproject.org [Accessed: May 2025]

[^10]: Tor Project, “Simple Bandwidth Scanner (sbws).” [Online]. Available: https://gitlab.torproject.org/tpo/network-health/sbws [Accessed: May 2025]

[^11]: D. Ralph, “Stem: Tor Controller Library.” [Online]. Available: https://stem.torproject.org [Accessed: May 2025]

[^12]: Tor Project, “Tor Metrics Library (metrics-lib).” [Online]. Available: https://gitlab.torproject.org/tpo/network-health/metrics/metrics-lib [Accessed: May 2025]

[^13]: K. Loesing, S. J. Murdoch, and R. Dingledine, “A case study on measuring statistical data in the Tor anonymity network,” in Proc. Workshop on Ethics in Computer Security Research (WECSR), Tenerife, Spain, Jan. 2010.

[^14]: P. Winter, R. Ensafi, K. Loesing, and N. Feamster, “Tor’s empirical censorship resistance,” in Proc. ACM CCS, Toronto, Canada, Oct. 2018, pp. 2065–2082.

[^15]: K. Bauer, D. McCoy, D. Grunwald, T. Kohno, and D. Sicker, “Low-resource routing attacks against Tor,” in Proc. ACM WPES, Alexandria, VA, USA, Oct. 2007, pp. 11–20.

[^16]: A. Johnson, C. Wacek, R. Jansen, M. Sherr, and P. Syverson, “Users get routed: Traffic correlation on Tor by realistic adversaries,” in Proc. ACM CCS, Berlin, Germany, Nov. 2013, pp. 337–348.

[^17]: N. Feamster and R. Dingledine, “Location diversity in anonymity networks,” in Proc. ACM WPES, Washington, DC, USA, Oct. 2004, pp. 66–76.

[^18]: I. Goldberg, D. Stebila, and B. Ustaoglu, “Anonymity and one-way authentication in key exchange protocols,” Des. Codes Cryptogr., vol. 67, no. 2, pp. 245–269, 2013.

[^19]: C. Dwork and A. Roth, “The algorithmic foundations of differential privacy,” Found. Trends Theor. Comput. Sci., vol. 9, no. 3–4, pp. 211–407, 2014.

[^20]: M. Castro and B. Liskov, “Practical Byzantine fault tolerance,” in Proc. 3rd USENIX OSDI, New Orleans, LA, USA, Feb. 1999, pp. 173–186.

[^21]: M. Yin, D. Malkhi, M. K. Reiter, G. G. Gueta, and I. Abraham, “HotStuff: BFT consensus with linearity and responsiveness,” in Proc. 38th ACM PODC, Toronto, Canada, Jul. 2019, pp. 347–356.

[^22]: The Coq Development Team, “The Coq Proof Assistant,” version 8.18, 2023. [Online]. Available: https://coq.inria.fr

[^23]: L. Lamport, Specifying Systems: The TLA+ Language and Tools. Addison-Wesley, Boston, MA, 2002.

[^24]: J. R. Douceur, “The Sybil attack,” in Proc. 1st IPTPS, Cambridge, MA, USA, Mar. 2002, pp. 251–260.