Proof of work
A Proof-of-work ("POW") system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spams on a network by requiring some work from the service requester, usually meaning processing time by a computer. A key feature of these schemes is their dissymmetry: the work must be moderately hard (hard but feasible) on the requester side but easy to check for the service provider.
One popular system is Hashcash which uses partial hash inversions to prove that work was done, as a good-will token to send an e-mail. For instance the
following header represents about 240 hash computations (that's big) to send a message to hobbes@comics
on March 19, 2017:
X-Hashcash: 1:40:170319:hobbes@comics::eb9a45d0eac8b65a:159b56eb15c
It is verified with a single computation by checking the its SHA1 hash begins with 40 binary zeros, that is 10 hexadecimal zeros: 00000000009f0b34697d40bf80d000a3a0646cd9
Whether POW systems can actually solve a particular denial-of-service issue such as the spam problem is subject to debate[1][2]: on the one hand the system must make sending spams massively quite unbeneficial for the spammer, but on the other hand it should not prevent legitimate users to send their messages. Another issue specific to e-mail systems is the management of lists.
Proof-of-Work variants
There are two classes of proof-of-work protocols.
- Challenge-response protocols assume a direct interactive link between the requester and the provider. The provider choses a challenge, say a item in a set with a property, the requester finds the relevant response in the set, which is sent back and checked by the provider. As the challenge is chosen on the spot by the provider, its difficulty can be adapted to its current load. The work on the requester sided is bounded and its variance is low.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/55/Proof_of_Work_challenge_response.svg/459px-Proof_of_Work_challenge_response.svg.png)
- Solution-verification protocols do not assume such a link: as a result the problem must be self-imposed before a solution is sought by the requester, and the provider must check both the problem choice and the found solution. Most such schemes are unbounded probabilistic iterative procedures with high variance such as Hashcash.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/2/24/Proof_of_Work_solution_verification.svg/459px-Proof_of_Work_solution_verification.svg.png)
Moreover the underlying functions used by these schemes may be:
- cpu-bound where the computation runs at the speed of the processor, which greatly varies in time following Moore's law, as well as from high-end server to low-end portable devices.
- memory-bound [3][4][5] where the computation speed is bound by main memory accesses (either latency or bandwidth), the performance of which is expected to be less sensitive to hardware evolution.
Finally, some POW systems offer shortcut computations which allow participants who know a secret, typically a private key, to generate cheap POWs. The rationale is that mailing-list holders may generate stamps for every recipient without incurring a high cost. Whether such a feature is desirable depends on the use scenario.
List of Proof-of-Work Functions
Here is a (preliminary) list of Proof-of-Work functions.
- integer square root modulo a large prime [6]
- weaken Fiat-Shamir signatures [6]
- Ong-Schnorr-Shamir signature scheme broken by Pollard [6]
- hash sequences [11]
- puzzles... [12]
- Diffie-Hellman based puzzle [13]
- Moderate [3]
- Mbound [4]
- Hokkaido [5]
Reusable Proof of Work
The computer scientist Hal Finney has built on the proof-of-work idea, yielding a system called reusable proof of work ("RPOW").
The easiest way to understand RPOW is to view it as a form of token money. It is in fact the only form of digital token money invulnerable to inflation caused by a greedy or untrustworthy mint's issuing more tokens than they said they would issue.
In this aspect it resembles the gold coin: an issuer of gold coins cannot unfairly profit by minting extra gold coins because in a well-run gold-coin currency, obtaining the gold to make the extra coins has a cost approximately equal to the revenue or benefit to be gained by the minting of the coins. Moreover, this cost (i.e., the price of gold) is knowable or predictable by anyone.
Just as a gold coin's value is in an important sense guaranteed by the value of the raw gold needed to make it, the value of a RPOW token is guaranteed by the value of a POW token. (In Finney's version of RPOW, that POW token is a piece of hashcash.)
The property that makes the gold coin and the RPOW token invulnerable to cheating by the nominal issuer of the currency also of course makes it invulnerable to counterfeiting.
Since the cost of creating a POW token decreases as a function of time in a fairly predictable way, e.g., by a steady logarithmic decay sometimes called Moore's law, it is impractical to hold onto a POW or RPOW token for years as a form of savings. Still, these tokens are quite useful and stable when used as a form of exchange.
If one operates a web site that offers some benefit or service that many people are highly motivated to use, then one can demand a POW token in exchange for this benefit, and in fact there will often be good reasons for doing so. The benefit offerred will almost always entail the consumption of certain resources, like bandwidth to the Internet, computation or disk space, that have a definite cost. Demanding a POW token will prevent Internet users from making frivolous or excessive use of the service (and consequently of the resources underlying the service).
Parenthetically, most people do not yet have software installed on their computer to mint POW tokens, but this could easily change in the near future.
An RPOW system differs from a POW system in that after someone has "spent" a POW token at my web site, I have the option of exchanging that "spent" POW token for a new, unspent RPOW token, which I can then spend at some third party's web site (provided of course that that web site has been set up to accept RPOW tokens). This saves me the computational resources I would have otherwise needed to mint a POW token.
That third party can in turn exchange that spent RPOW for a new, unspent one of equal value.
The anti-counterfeit/anti-inflationary property of the RPOW token is guaranteed by a technique called remote attestation. In particular, the "RPOW server", the Internet server at which one exchanges a used POW or RPOW token for a new one of equal value, uses remote attestation to allow any sufficiently knowledgeable and interested party to verify what software is running on the RPOW server. Since the source code for this software has been published (under a BSD-like license), any sufficiently knowledgeable programmer can by inspecting this source code satisfy himself that the software, and by extension the RPOW server, never issues a new token except in exchange for spent token of equal value.
Finney's system is the only RPOW system to have been implemented so far, and it has not yet seen economically significant use. It is implemented as 12,000 lines of C code.
References
Stuff about proof-of-work functions: [6] [7] [14] [11] [8] [12] [9] [10] [3] [4] [1] [13] [5] [2] [15]
- ^ a b Ben Laurie and Richard Clayton. proof-of-work proves not to work. In WEAS 04, May 2004.
- ^ a b Debin Liu and L Jean Camp. Proof of Work can Work. In Fifth Workshop on the Economics of Information Security, June 2006.
- ^ a b c Martín Abadi, Mike Burrows, Mark Manasse, and Ted Wobber. Moderately hard, memory-bound functions. In 10th Annual Network and Distributed System Security Symposium (NDSS), San Diego, CA, USA, February 2003. Also in ACM Trans. Inter. Tech., 5(2):299-327, 2005.
- ^ a b c Cynthia Dwork, Andrew Goldberg, and Moni Naor. On memory-bound functions for fighting spam. In Advances in Cryptology - CRYPTO 2003, volume 2729 of Lecture Notes in Computer Science, pages 426-444. Springer, 2003.
- ^ a b c Fabien Coelho. Exponential memory-bound functions for proof of work protocols. Cryptology ePrint Archive, Report 2005/356.
- ^ a b c d Cynthia Dwork and Moni Naor, "Pricing via Processing, Or, Combatting Junk Mail, Advances in Cryptology" – CRYPTO’92, Lecture Notes in Computer Science No. 740, Springer, 1993, pp. 139–147. (PDF)
- ^ a b Adam Back. HashCash Popular proof-of-work system. First announce in March 1997.
- ^ a b Eran Gabber, Markus Jakobsson, Yossi Matias, and Alain J. Mayer. Curbing junk e-mail via secure classification. In Financial Cryptography, pages 198-213, 1998.
- ^ a b Markus Jakobsson and Ari Juels. "Proofs of Work and Bread Pudding Protocols", In B. Preneel, ed., Communications and Multimedia Security, pages 258-272, Kluwer Academic Publishers, 1999. This paper formalizes the idea of a proof of work (POW) and introduces "the dependent idea of a bread pudding protocol", a "re-usable proof of work" (RPOW) system.
- ^ a b XiaoFeng Wang and Michael Reiter. Defending against denial-of-service attacks with puzzle auctions. In IEEE Symposium on Security and Privacy 03, May 2003.
- ^ a b Matthew K. Franklin and Dahlia Malkhi. Auditable metering with lightweight security. In Financial Cryptography 97, 1997. Updated version May 4, 1998.
- ^ a b Ari Juels and John Brainard. Client puzzles: A cryptographic defense against connection depletion attacks. In NDSS 99, 1999.
- ^ a b Brent Waters, Ari Juels, John A. Halderman, and Edward W. Felten. New client puzzle outsourcing techniques for DoS resistance. In 11th ACM Conference on Computer and Communications Security, 2004.
- ^ Matthew K. Franklin and Michael K. Reiter. Fair exchange with a semi-trusted third party (extended abstract). In CCS '97: Proceedings of the 4th ACM conference on Computer and communications security, pages 1-5, New York, NY, USA, 1997. ACM Press.
- ^ Fabien Coelho. An (almost) constant-effort solution-verification proof-of-work protocol based on Merkle trees. Cryptology ePrint Archive, Report 2007/433.
External links
- Bit gold. Describes a complete money system (including generation, storage, assay, and transfer) based on proof of work functions and the machine architecture problem raised by the use of these functions.