A Blind Signature is a cryptographic procedure in which a requester hides a message from the signer, obtains a signature on the hidden form, then removes the hiding. A usable signature on the original message remains. David Chaum applied the idea to electronic cash. With a correct protocol, the signer cannot use the signing exchange and a later token to determine which issuance belongs to it. Other clues, such as timing, amount or network address, do not automatically disappear.
With an ordinary approval, an issuer can record a voucher’s unique number alongside the person receiving it. When a shop returns the voucher, those records can be connected. Chaum explained blind signing through an envelope lined with carbon paper: a stamp on the outside transfers to the slip inside, whose number the issuer cannot see. Once removed, the slip carries valid approval. This is a teaching analogy, not a secure paper-and-stamp procedure. The actual protocol uses numbers and mathematics to make this separation work between computers. [7] [1]
In a simple example, Anna wants a digital voucher worth 100 sats. Sats are small units of Bitcoin. Her wallet, the app she uses to manage and pay with these vouchers, generates an unpredictable secret value that distinguishes the voucher, then uses another random value to conceal it mathematically. This transformation is called blinding. The issuer receives the hidden message, not the original secret. The wallet keeps what it needs to remove the hiding later. Blinding is more than renaming a file or removing a person’s name: it must satisfy precisely defined cryptographic properties. We use a single voucher to keep the example simple; a real wallet may combine several vouchers of different values to make up the amount. [8] [2]
Blind signing does not mean signing anything for anyone free of charge. The issuer can first verify Anna’s payment or deduct the corresponding balance. It knows the requested value of 100 sats but need not know the hidden voucher number. A signing key is a secret numerical value that the issuer’s software uses to create signatures. The voucher’s value can be tied to a separate signing key for that denomination; editing a number in a file cannot simply create a higher-value voucher. The issuer signs the hidden input and returns the result. Two things are being separated: why Anna is entitled to a voucher and how that particular voucher will later be recognised. [7] [8]
Anna does not now need to reveal the original secret to the issuer. Her wallet removes the random hiding from the returned result on its own. This step is called unblinding. A well-designed procedure leaves a valid certification of the message the wallet prepared at the start, without giving it the issuer’s private signing key. The user sees a new amount in the wallet; the mathematical wrapping and unwrapping happen in the background. The resulting digital proof is often called a token. It is not a separate bitcoin on the blockchain, the shared record of Bitcoin transactions, but a claim against its issuer. [2] [8]
Verification asks whether the certification matches the message and the correct issuer key. For blind signatures based on the RSA cryptographic system, the public key suffices; other constructions can require an additional proof or the issuer’s involvement. None of this proves that the voucher is unspent, that nobody else copied it or that the issuer holds enough reserves to honour it. Those are three further questions. Just as a genuine ticket already used is not a second admission, a cryptographically valid proof can be unusable for another payment. [2] [10]
Anna sends the voucher to Peter. Because it is data, she may retain an identical copy. A blind signature cannot erase a file from her device. In a typical online system, the recipient’s wallet therefore submits the token to the issuer, which verifies validity and checks whether a token with the same secret has already been spent. If accepted, it marks the old token as used and can issue Peter a fresh token using the same blind-signing process. Anna does not know Peter’s new secret. A later attempt to spend the old copy is rejected by the records. Reusing the same funds is called a double spend; preventing it is another part of the payment system. [9] [8]
Protection is needed in the other direction too: a client must not turn permitted signing interactions into extra valid proofs with new secrets. This property is called unforgeability. Blind-signature research particularly examines one-more unforgeability: after a given number of signing interactions, can an attacker produce one additional new valid message-signature pair? Copying the same pair is a different problem, discussed above. Correct cryptography also does not replace server checks of entitlement, amounts and permitted token structure. Together, these checks can prevent unauthorised issuance of value. [2] [3]
The issuer may know when Anna obtained tokens and their value. At redemption, it may know the time, amount or recipient’s network address. These are metadata: information accompanying the payment proof itself. In a small user group, an unusual amount or an immediate follow-up payment can make connections easier to infer. Shared, verified keys matter too: a key assigned to just one person could mark that person. Protocol blindness protects a specific link between a signature and its issuance, not every surrounding detail. Nor does a signature repair a compromised wallet or make an issuer honour its obligations. [7] [2]
Chaum’s idea underlies electronic cash, historically associated with DigiCash. Cashu and Fedimint use it in today’s Bitcoin ecosystem, with Lightning Network (a network for fast Bitcoin payments) connections helping funds enter and leave. Their constructions are not RSA, however. Basic Cashu verifies a token using the secret key of the issuer, known as a mint; NUT-12 adds a proof allowing signature verification with public information, not proof that the token remains unspent. Fedimint distributes administration among a group of operators. In both cases, users hold claims against an issuer and depend on its custody and availability. Buyer privacy can be a goal elsewhere too: GNU Taler, for example, combines it with traceability of merchant income. [5] [6] [10] [4]
A simplified sketch takes a few equations. Securely encode the message as a number m; the public key contains n and e, while d denotes the private part. The requester chooses random r with a multiplicative inverse r⁻¹ modulo n and sends m′ = m·r^e mod n. The notation mod n means arithmetic using remainders after division by n. The signer returns s′ = (m′)^d mod n, and the requester obtains s = s′·r⁻¹ mod n. Verification gives s^e mod n = m. The factor r⁻¹ removes the hiding. These relations explain the mechanism but are not a complete secure program. RFC 9474 additionally specifies message preparation and the RSA-PSS signature scheme with secure encoding, input checks and separation of signing keys; randomness and the correct protocol variant matter. [2] [3]
For the clearest picture, read this entry together with David Chaum, Chaumian eCash, DigiCash, Cashu, Fedimint, Bitcoin Privacy. The reverse links also lead from DigiCash, Chaumian eCash, Reusable Proofs of Work, Fedimint.