Proof of work: Difference between revisions
→List of proof-of-work functions: add link to Merkle tree |
add other names for proof of work from literature, fix incorrect claim that interactive protocols are significantly lower variance, also explain how variance is controlled, and explain existence of fixed-cost functions |
||
| Line 1: | Line 1: | ||
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 [[spam (electronic)|spam]] 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 asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also |
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 [[spam (electronic)|spam]] 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 asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known has a CPU cost function, [[Client Puzzle Protocol|client puzzle]], computational puzzle or CPU pricing function. It is distinct from a [[CAPTCHA]], which is intended for a human to solve quickly, rather than a computer. |
||
One popular system is [[Hashcash]], which uses partial hash inversions<!-- *not* hash collisions... --> to prove that work was done, as a good-will token to send an [[e-mail]]. For instance the following header represents about 2<sup>52</sup> hash computations to send a message to <code>calvin@comics.net</code> on [[January 19, 2038]]: |
One popular system is [[Hashcash]], which uses partial hash inversions<!-- *not* hash collisions... --> to prove that work was done, as a good-will token to send an [[e-mail]]. For instance the following header represents about 2<sup>52</sup> hash computations to send a message to <code>calvin@comics.net</code> on [[January 19, 2038]]: |
||
| Line 14: | Line 14: | ||
| title = Proof of Work can work |
| title = Proof of Work can work |
||
| journal = Fifth Workshop on the Economics of Information Security | month = June | year = 2006 |
| journal = Fifth Workshop on the Economics of Information Security | month = June | year = 2006 |
||
}}</ref> the system must make sending spam emails obtrusively unproductive for the spammer, but should also not prevent legitimate users from sending their messages. Proof-of-work systems are being used as a primitive by other more complex cryptographic systems such as [[Bitcoin]]. |
}}</ref> the system must make sending spam emails obtrusively unproductive for the spammer, but should also not prevent legitimate users from sending their messages. Proof-of-work systems are being used as a primitive by other more complex cryptographic systems such as [[Bitcoin]] which uses the [[Hashcash]] system. |
||
==Proof-of-work variants== |
==Proof-of-work variants== |
||
There are two classes of proof-of-work protocols. |
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 chooses a challenge, say an 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 side |
* '''Challenge-response''' protocols assume a direct interactive link between the requester and the provider. The provider chooses a challenge, say an 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 side may be bounded if the challenge-response protocol has a known solution (chosen by the provider), or known to exist within a bounded search space. |
||
[[Image:Proof of Work challenge response.svg|center]] |
[[Image:Proof of Work challenge response.svg|center]] |
||
* '''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 |
* '''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 such as [[Hashcash]]. |
||
[[Image:Proof of Work solution verification.svg|center]] |
[[Image:Proof of Work solution verification.svg|center]] |
||
Known-solution protocols tend to have slightly lower variance than unbounded probabilistic protocols, because the variance of a [[Uniform distribution (continuous)|rectangular distribution]] is lower than the variance of a [[Poisson distribution]] (with the same mean). A generic technique for reducing variance is to use multiple independent sub-challenges, as the average of multiple samples will have lower variance. |
|||
There are also fixed-cost functions such as the time-lock puzzle. |
|||
Moreover, the underlying functions used by these schemes may be: |
Moreover, the underlying functions used by these schemes may be: |
||
Revision as of 09:38, 27 November 2012
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 spam 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 asymmetry: the work must be moderately hard (but feasible) on the requester side but easy to check for the service provider. This idea is also known has a CPU cost function, client puzzle, computational puzzle or CPU pricing function. It is distinct from a CAPTCHA, which is intended for a human to solve quickly, rather than a computer.
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 252 hash computations to send a message to calvin@comics.net on January 19, 2038:
X-Hashcash: 1:52:380119:calvin@comics.net:::9B760005E92F0DAE
It is verified with a single computation by checking that the SHA-1 hash of the stamp (omit the "X-Hashcash:" portion) begins with 52 binary zeros, that is 13 hexadecimal zeros: 0000000000000756af69e2ffbdb930261873cd71
Whether POW systems can actually solve a particular denial-of-service issue such as the spam problem is subject to debate;[1][2] the system must make sending spam emails obtrusively unproductive for the spammer, but should also not prevent legitimate users from sending their messages. Proof-of-work systems are being used as a primitive by other more complex cryptographic systems such as Bitcoin which uses the Hashcash system.
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 chooses a challenge, say an 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 side may be bounded if the challenge-response protocol has a known solution (chosen by the provider), or known to exist within a bounded search space.
- 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 such as Hashcash.
Known-solution protocols tend to have slightly lower variance than unbounded probabilistic protocols, because the variance of a rectangular distribution is lower than the variance of a Poisson distribution (with the same mean). A generic technique for reducing variance is to use multiple independent sub-challenges, as the average of multiple samples will have lower variance.
There are also fixed-cost functions such as the time-lock puzzle.
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, as well as from high-end server to low-end portable devices.[3]
- Memory-bound [4][5][6] 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.
- Network-bound [7] if the client must performs few computations but must collect some tokens from various remote servers before querying the final service provider. In this sense the work is not actually performed by the requester, but it incurs delays anyway because of the latency to get the required tokens.
Finally, some POW systems offer shortcut computations that 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 usage scenario.
List of proof-of-work functions
Here is a list of known proof-of-work functions:
- Integer square root modulo a large prime[8]
- Weaken Fiat–Shamir signatures[8]
- Ong–Schnorr–Shamir signature broken by Pollard [8]
- Partial hash inversion[9][10][11][12] as Hashcash
- Hash sequences[13]
- Puzzles[14]
- Diffie–Hellman-based puzzle[15]
- Moderate[4]
- Mbound[5]
- Hokkaido[6]
- Merkle tree based[16]
- Guided tour puzzle protocol[7]
Reusable proof-of-work as e-money
Computer scientist Hal Finney built on the proof-of-work idea, yielding a system that exploited reusable proof of work ("RPOW").[17] The idea of making proofs-of-work reusable for some practical purpose had already been established in 1999.[11] Finney's purpose for RPOW was as token money. Just as a gold coin's value is thought to be underpinned by the value of the raw gold needed to make it, the value of an RPOW token is guaranteed by the value of the real-world resources required to 'mint' a POW token. In Finney's version of RPOW, the POW token is a piece of hashcash.
A website can demand a POW token in exchange for service. Requiring a POW token from users would inhibit frivolous or excessive use of the service, sparing the service's underlying resources, such as bandwidth to the Internet, computation, disk space, electricity and administrative overhead.
Finney's RPOW system differed from a POW system in permitting random exchange of tokens without repeating the work required to generate them. After someone had "spent" a POW token at a website, the website's operator could exchange that "spent" POW token for a new, unspent RPOW token, which could then be spent at some third party web site similarly equipped to accept RPOW tokens. This would save the resources otherwise needed to 'mint' a POW token. The anti-counterfeit property of the RPOW token was guaranteed by remote attestation. The RPOW server that exchanges a used POW or RPOW token for a new one of equal value uses remote attestation to allow any interested party to verify what software is running on the RPOW server. Since the source code for Finney's RPOW software was published (under a BSD-like license), any sufficiently knowledgeable programmer could, by inspecting the code, satisfy himself that the software (and, by extension, the RPOW server) never issued a new token except in exchange for a spent token of equal value.
Until 2009, Finney's system was the only RPOW system to have been implemented; it never saw economically significant use. In 2009, the Bitcoin network went online. Bitcoin is a proof-of-work crypto currency that, like Finney's RPOW, is also based on the hashcash POW. But in bitcoin, double-spend protection is provided by a decentralized P2P protocol for tracking transfers of coins rather, than the hardware trusted computing function used by RPOW. Bitcoin has better trustworthiness because it is protected by computation, RPOW is protected by the private keys stored in the TPM hardware, and manufacturers holding TPM private keys (or hackers who stole a TPM manufacturer key) could subvert that assurance. Bitcoins are "mined" using the hashcash proof-of-work function by individual nodes and verified by the decentralized P2P bitcoin network. The other novel aspect of bitcoin is that it dynamically varies the hashcash size required to create a coin to avoid inflation due to computers getting faster, and due to more users mining.
References
- ^ Laurie, Ben; Clayton, Richard (2004). "Proof-of-work proves not to work". WEIS 04.
{{cite journal}}: Unknown parameter|month=ignored (help) - ^ Liu, Debin; Camp, L. Jean (2006). "Proof of Work can work". Fifth Workshop on the Economics of Information Security.
{{cite journal}}: Unknown parameter|month=ignored (help) - ^ How powerful was the Apollo 11 computer?, a specific comparison that shows how different classes of devices have different processing power.
- ^ a b Abadi, Martín; Burrows, Mike; Wobber, Ted (2005). "Moderately hard, memory-bound functions". ACM Trans. Inter. Tech. 5 (2): 299–327.
- ^ a b Naor, Moni (2003). "On memory-bound functions for fighting spam". Advances in Cryptology: CRYPTO 2003. 2729. Springer: 426–444.
- ^ a b Coelho, Fabien. 2005/356 "Exponential memory-bound functions for proof of work protocols". Cryptology ePrint Archive, Report.
{{cite web}}: Check|url=value (help) - ^ a b Abliz, Mehmud; Znati, Taieb (2009). "A Guided Tour Puzzle for Denial of Service Prevention". Proceedings of the Annual Computer Security Applications Conference (ACSAC) 2009. Honolulu, HI: 279–288.
{{cite journal}}: Unknown parameter|month=ignored (help) - ^ a b c Dwork, Cynthia; Naor, Moni (1993). "Pricing via Processing, Or, Combatting Junk Mail, Advances in Cryptology". CRYPTO’92: Lecture Notes in Computer Science No. 740. Springer: 139–147.
- ^ Back, Adam. "HashCash". Popular proof-of-work system. First announce in March 1997.
- ^ Gabber, Eran; Jakobsson, Markus; Matias, Yossi; Mayer, Alain J. (1998). "Curbing junk e-mail via secure classification". Financial Cryptography: 198–213.
- ^ a b Jakobsson, Markus; Juels, Ari (1999). "Proofs of Work and Bread Pudding Protocols". Communications and Multimedia Security. Kluwer Academic Publishers: 258–272. 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.
- ^ Wang, Xiao-Feng; Reiter, Michael (2003). "Defending against denial-of-service attacks with puzzle auctions". IEEE Symposium on Security and Privacy '03.
{{cite journal}}: Unknown parameter|month=ignored (help) - ^ Franklin, Matthew K.; Malkhi, Dahlia (1997). "Auditable metering with lightweight security". Financial Cryptography '97. Updated version May 4, 1998.
- ^ Juels, Ari; Brainard, John (1999). "Client puzzles: A cryptographic defense against connection depletion attacks". NDSS 99.
- ^ Waters, Brent; Juels, Ari; Halderman, John A.; Felten, Edward W. (2004). "New client puzzle outsourcing techniques for DoS resistance". 11th ACM Conference on Computer and Communications Security.
- ^ Coelho, Fabien. "An (almost) constant-effort solution-verification proof-of-work protocol based on Merkle trees". Cryptology ePrint Archive, Report.
- ^ "Reusable Proofs of Work". Archived from the original on December 22, 2007.
See Also
External links
- Finney's system
- 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.