用 hashcash 打击垃圾邮件

核心提示： 校验 CPU 能力的方法是，要求在短期间内得到高比特值，用 hashcash 打击垃圾邮件(9)，只有 足够快的 CPU 才能回答这个质询，为此，有一个“hashcash”的 Python 实现，使用了一个与 bashcash 有一点类似的质询协议（可能对加密价值而

校验 CPU 能力的方法是，要求在短期间内得到高比特值。只有 足够快的 CPU 才能回答这个质询。为此，必须半交互式地提供资源名。否则，参与者完全可以迟签他们的日期戳的日期，制造出创建速度很快的假象。

例如，一个快速的 Pentium III 或者 G4 可以在不到一秒钟之内生成一个 20-比特的戳记，但是 Pentium-II 或者 G3 做不到。我们可以假定一个 32-比特的质询，试运行的候选机器必须在一个小时之内回答它。请求者可能会发一封电子邮件，说：“向我发送一个质询”；协同服务器作出响应：“时间是 040927124732；质询资源是 a37tQk。”如果服务器在当天下午的 1:47 之前得到了一个正确的散列，那么该请求者将获得访问该资源的资格。

显然，我所建议的协议不能确保在每个节点上都能真正地完成工作。即使是最快的机器，也可能会出现断电的意外情况。用户可能会改变他们运行分布式软件的想法。不过，至少可以证明其具备似乎可信的资格。

通用的 hashcash 以及我的贡献

从 hashcash 概念整体来看，具体域和分隔符的使用从某种程度上说是任意的。实际上，hashcash 版本 0 使用了与版本 1 不同的域。这些选择都很好，不过，我认为“实际的 hashcash”只是某个家族的一名成员，我们可能会称这个家族为“通用 hashcash”。也就是说，只要给定任何质询字符串，都可以合理地提出以下要求：“给我一个后缀，一旦 challenge+suffix 被散列，它将生成 b 比特的碰撞”。真正的 hashcash 只不过是这种通用质询的一个实例。

现在， 确实存在过于通用的问题。创建很多不兼容的、近似 bashcash 的协议实际上对谁都没有好处。例如，有一个“hashcash”的 Python 实现，使用了一个与 bashcash 有一点类似的质询协议（可能对加密价值而言也是如此），但是几乎不能使用它生成 hashcash 戳记。