Well I put up some source that implements one proposed version 1 format here: http://www.hashcash.org/source/current/ it does not come with multiple sub-puzzle support which could be added. The other part missing from the implementation is the hooks to make use of extensions. ie I was thinking for extension a (syntax X-Hashcash: 1:20:040430:kyle@xxxxxxxxxxx:mac-key=0123456789abcdef01234 56789abcdef:35385ea2086e2b12:15003 then this would be invoked as: hashcash-ext-mac-key 0123456789abcdef0123456789abcdef $stamp where $stamp would be the full stamp also. So if the extension was missing it would be ignored. If the extension handler program returns failure the stamp would be rejected, and if the extension handler program returns success the stamp would be accepted (if it was otherwise valid). Plus need to integrate Chromatix fast hashcash code. Think main issue there is to have a way to know which code to run on a machine based on eg some CPU properties code so it is fast, or a very short trial of the set of alternatives that run on the CPU to measure which is best. And the last and probably biggest issue is how to deal with CPU inflation. I was thinking this could be implemented using the extension mechanism. One way is to pass around p2p the largest required-hash definition seen so far, and have someone / some group changing this over time using some pre-agreed criteria. Adam On Tue, Jul 27, 2004 at 08:13:03PM -0400, Hubert Chan wrote: > I'm just wondering how close we are to having a new hashcash using the > new token format. As the Debian package maintainer for hashcash, I'd > like to get hashcash into the next stable release of Debian, and I've > been holding ver. 0.32 back due to the format change. Debian is > entering a freeze for the base and standard packages soon, which > probably means that a freeze for the whole system is about a month away.