Reusable Proofs of Work, or RPOW, was Hal Finney’s experimental system for exchanging Hashcash proofs of computation for transferable digital tokens. Each token could be exchanged only once at its designated server, the service that processed users’ requests, but the recipient received a fresh replacement with the same computational value. An IBM 4758 card and remote verification of the running program were intended to protect the exchanges. This was neither a decentralised network nor bitcoin.
On 15 August 2004, Hal Finney invited participants in a cryptography email discussion to try his new experiment. It built on Adam Back’s Hashcash: a computer tries different inputs until it finds a result meeting a specified condition. Finding it takes computing time; checking the result is quick. This is Proof of Work, evidence of computational effort. In email spam prevention, it can act like a computational postage stamp. Finney wanted to know whether that evidence could circulate between people instead of losing its usefulness after one use. That is what the name RPOW means: reusable proofs of work. [1] [2] [4]
Imagine Anna has a valid digital token and sends it to Peter. If all she sent was a file, she could have kept a copy. Peter therefore presents the token to the RPOW server and requests an exchange. The server checks that it has not been used, marks it consumed and signs a new token prepared by Peter’s software. Anna’s copy of the old token can no longer pass another exchange. Peter can later send the new token to Eve, who repeats the process. What is reused is the transferred value, not the same valid file over and over. Until the recipient successfully completes the exchange, the sender might spend the original first. [2] [11]
The input could be freshly computed Hashcash or an unused RPOW token. The output was a new token bearing an RSA digital signature: a mathematically verifiable endorsement by the server. RSA is a method for calculating such a signature: creating it requires a secret signing key, while checking it requires the corresponding public key. It is verifiable numerical data, not an image of a handwritten signature. The signature let someone check the token’s origin, but did not by itself show whether it had already been exchanged. That required a record of consumed inputs. Later transfers did not have to repeat the original expensive Hashcash search each time; a new signature was issued in return for invalidating an old proof. This was neither recycling electricity nor a way to multiply claims on past work for free. [2]
Value here meant a level of computational difficulty, not a price in dollars or crowns. Historical Hashcash used SHA-1, a function producing a short numerical fingerprint of data, and searched for a fingerprint with a required number of leading zero bits. A bit is one binary digit. Each additional required zero bit roughly doubles the average number of attempts. A level-21 token therefore represented the same expected work as two level-20 tokens and could be split into them. Splitting or combining had to preserve the total computational value. This was not a fixed exchange rate or a purchasing-power guarantee: faster computers could create the same kind of token more cheaply. [2] [10]
A double spend means spending the same value twice. To prevent it, RPOW needed a list of previously exchanged proofs. Crucially, the whole database did not sit inside the protected card: an ordinary host computer stored it. The card kept a fingerprint of its state and checked cryptographic proofs when querying it. This used the Merkle Tree principle, a tree of fingerprints that lets a portion of the data be checked against one shared fingerprint. The goal was to detect both changed records and a rollback to an older database in which a just-spent token was still absent. Without that protection, an operator could turn the same input into new tokens repeatedly. [3]
The server performed sensitive operations inside an IBM 4758, a self-contained computer card installed in an ordinary PC. It was intended to protect signing keys and sensitive state even from the owner of the surrounding machine. On detecting physical tampering, it could erase secret information. The host computer relayed messages and stored the database, but the design did not trust it. That was central to Finney’s approach: operating the server should not give someone the ability to issue tokens at will. These protections nevertheless depended on correct hardware, software and key security. They were not an unconditional promise of invulnerability. [3] [9]
Publishing source code is not enough. An operator can show one program while running another. RPOW therefore used remote attestation, a signed report of the software configuration. The card reported which program it was running. Someone could build the published source with matching tools and compare the resulting program image’s fingerprint with the reported one. This was not merely a comparison of source-file text. Certificates linked the signatures back to an IBM key. The check helped establish which program the server ran, but did not prove that the program was bug-free or that the manufacturer and its certification procedures could never fail. [3] [9]
RPOW resembles eCash in exchanging digital tokens, but the original documented operation did not protect privacy through blind signing. Finney relied on encryption all the way to the protected card and on an inspectable program that did not retain links between issued and received tokens. The host should therefore not see their plaintext contents. It could still observe the client’s network address, the time and the amount of traffic. Presenting the same token again could also link certain events. The preserved documentation already describes support for Tor, a network that routes connections through several relays and hides the user’s original network address from the server. Blind signing, by contrast, is presented as a possible later addition. That planned feature should not be described as part of the operation documented at the time. [8] [10]
Unlike a paper proposal alone, RPOW had a working server and available client software. Finney nevertheless warned from the start that it was an early test version: a necessary server-code change could invalidate previously issued tokens. The project designated them for personal, experimental and non-commercial use, not as money with a guaranteed value. Nor could a secure card force the operator to keep the server running. The original project has ended, and its preserved pages and code are historical material. Descriptions of its SHA-1, RSA and hardware choices are therefore not recommendations for building a payment service today. [1] [4] [5] [7]
Finney wanted to demonstrate part of Nick Szabo’s Bit Gold idea in practice: a digital object can be expensive to create and then passed between people. RPOW’s documentation also allowed for multiple cooperating servers, so the design should not be dismissed as necessarily one computer forever. A particular token nevertheless designated the server where it could be exchanged; adding machines did not itself remove that dependence. Bitcoin took another route. Independent nodes—computers running verification software—check shared rules and public history. Miners compete to add further valid blocks: batches of transactions linked to the preceding record. RPOW therefore helps explain what Proof of Work alone does not settle: how everyone establishes a valid order of transfers, and whom they must trust along the way. [1] [6] [11]
For the clearest picture, read this entry together with Hal Finney, Adam Back, Hashcash, Nick Szabo, Bit Gold, Proof of Work. The reverse links also lead from b-money, Bit Gold, Hal Finney.