David Chaum is a cryptographer who developed ways to verify a message, payment or entitlement without automatically creating an interconnected record of a person’s entire life. His contribution starts with an everyday wish: you want to pay for something without revealing all your other purchases.
Imagine a journalist receiving sensitive information. Encryption hides the message, but an observer may still see who is communicating with whom. Chaum’s 1981 proposal addresses this distinction. Messages pass through a computer called a mix, which removes an outer encryption layer and sends them out in a different order. Recipients then open the inner encrypted part. The aim is not just to conceal words, but to make it harder to connect a particular sender to a particular recipient. [1]
If a single message arrived at an intermediary and immediately left, its route would be easy to infer. The 1981 design therefore handles batches of equally sized items. A mix must reject repeats too: otherwise an attacker could submit the same item several times and look for the corresponding pattern at the output. Changing the order and appearance of messages is part of a specific procedure. Sending traffic through another computer alone does not provide the same protection. [1]
In 1981 Chaum also described a chain of mixes. A message has several encryption layers, removed in turn by successive nodes. Within the proposed model, even one uncompromised mix can conceal the connection between the whole chain’s inputs and outputs. This conclusion depends on assumptions about encryption and correct execution of the protocol. It is not a guarantee of anonymity in every real network. Our journalist’s compromised phone, for example, would remain a problem even if message transmission worked correctly. [1]
Payments raise a related question: can money be authenticated without its issuer connecting every purchase to a withdrawal? In his 1985 article Chaum explains Blind Signatures, signatures made on a concealed form of a message. A user prepares a digital note, mathematically blinds it and asks the bank to sign that form and debit the corresponding amount from the account. The user then removes the blinding; the signature on the original note remains valid. The note can be verified, but this signature alone does not tell the bank which withdrawal produced the note later presented for payment. [2]
A digital file can be copied. If Peter paid a shop with a note and then offered it again, the signature would look valid on both copies. In the online version described in 1985, the bank therefore keeps a list of note numbers already accepted and rejects reuse. A recipient needs this check as well as signature verification. A valid signature does not prove a token is unspent: it answers who issued it, while the reuse check establishes whether it has already been redeemed. [2]
This payment model retains an issuer. The bank signs notes and is expected to redeem them; protection against tracing does not itself guarantee that the bank will meet its obligation. Bitcoin addresses another part of the problem: a network verifies the history of BTC transfers under shared rules and Proof of Work, a computational proof of effort, without a central note issuer. A blindly signed token is therefore not automatically BTC. Compare payment privacy separately from the question of whose performance you depend on. [3] [2]
Chaum’s 1985 article extends beyond payments. It also considers proving an entitlement or attribute under different pseudonyms, without organizations readily linking every record about a person. Think of a membership discount: a shop needs to verify eligibility, not necessarily obtain a history of every previous visit. Such an attestation is called a credential. The design does not remove verification or service rules. It aims to separate proof of a necessary fact from information that the transaction does not require. [2]
Surrounding operations can weaken a strong mathematical procedure. In 1985 Chaum pointed out that immediate, opposite balance changes could link accounts even when the signature revealed no connection. In our example, Peter might also give his name for delivery. Timing, accounts and information disclosed to a merchant therefore belong in the same analysis as signatures. Chaum’s contribution includes this question: which information does a service actually need, and which does it collect simply because its system was designed that way? [2]
For the clearest picture, read this entry together with Nick Szabo, Ralph Merkle, Blind Signature, Chaumian eCash. The reverse links also lead from DigiCash, Chaumian eCash, The Crypto Anarchist Manifesto, Blind Signature.