<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash">
    <title>gmane.mail.spam.hashcash</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1019"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1018"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1017"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1016"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1015"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1014"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1013"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1012"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1011"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1010"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1009"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1008"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1007"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1006"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1005"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1004"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1003"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1002"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1001"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.mail.spam.hashcash/1000"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1019">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1019</link>
    <description>&lt;pre&gt;
lgpl.  hope that works. it's on launchpad, look for twopenny blue.

I'm trying to get out the door so I don't have time to dig through the 
repository right now but it's in the stamper process. If you can't find it, let 
me know and I will try to dig into it tomorrow.



&lt;/pre&gt;</description>
    <dc:creator>Eric S. Johansson</dc:creator>
    <dc:date>2011-08-31T17:05:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1018">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1018</link>
    <description>&lt;pre&gt;
Found it. https://launchpad.net/2pblue

Thanks,

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-08-31T17:22:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1017">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1017</link>
    <description>&lt;pre&gt;
Do you have a link to your source? Doing a quick Google search isn't
pulling up anything for me. I'd like to read over your source, and
possibly implement your ideas (if it will work well with Mutt), provided
the source code license is liberal enough.

Thanks,

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-08-31T17:00:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1016">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1016</link>
    <description>&lt;pre&gt;
there is apparently something in the standard about no duplicate headers. I 
haven't tracked it down but I saw discussion of it on the Python e-mail module 
mailing list. In twopenny blue, I generate one mail message copied per token.  
why?, First off, it really doesn't matter anymore. We have more than enough 
capacity on most servers/systems to handle it. Second, when I send messages out 
to multiple people (i.e. mailing list), they're not on the same server as a 
rule. So they're gonna get duplicated anyway. Third, you don't need to add any 
additional complexity for blind carbon copy.  if you need to split on a message 
for blind carbon copy, it the same code only simpler to split all messages into 
one message per token model.

seriously, one token, one message, in my experience, made my code and design 
much simpler


&lt;/pre&gt;</description>
    <dc:creator>Eric S. Johansson</dc:creator>
    <dc:date>2011-08-31T16:54:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1015">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1015</link>
    <description>&lt;pre&gt;
Unfortunately, I don't have administrative acces to the Exchange server, so
I'm at the mercy of the admins. I guess I can request that they configure
Exchange to not change that specific header, but I'm sure that would come
off as an odd request.

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-08-31T15:07:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1014">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1014</link>
    <description>&lt;pre&gt;Could it be the Exchange 2010 Address Rewriter agent messing with the
header?

http://technet.microsoft.com/en-us/library/aa996806.aspx#SMTP

You can check out the rewriter rules for your server;
http://technet.microsoft.com/en-us/library/aa997185.aspx

But if this is the default behaviour of Exchange, then a more robust
solution would be... a workaround!

John.

On 31 August 2011 15:47, Aaron Toponce &amp;lt;aaron.toponce&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:




&lt;/pre&gt;</description>
    <dc:creator>John Honan</dc:creator>
    <dc:date>2011-08-31T15:02:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1013">
    <title>Re: Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1013</link>
    <description>&lt;pre&gt;
I guess thinking about this a little further, I could put every token under
one "X-Hashcash" field, separated by semicolons, or something similar.
Thoughts on this approach?

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-08-31T14:55:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1012">
    <title>Exchange mucking with the headers</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1012</link>
    <description>&lt;pre&gt;I've come to the knowledge that Exchange is mucking with the mail headers,
stripping out any duplicate fields. This is troublesome for me, as sending
a mail to multiple recipients, means minting many Hashcash tokens, and
placing each token in the header with "X-Hashcash". There may be more than
one present. However, Exchange changes "X-Hashcash" to "x-hashcash", and
removes any dupe "x-hashcash" fields.

I could stamp each mail upon delivery, rather than mail creation, but that
would meach changing the way I handle SMTP with Mutt, and that's not
something I'm really interested in persuing. AFAIK, there is no "standard"
against duplicate header fields, so my multiple "X-Hashcash" tokens should
be just fine.

Has anyone else noticed this? Is there a server-side setting on Exchange
that prevents Exchange from mucking with the headers?

Thanks,

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-08-31T14:47:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1011">
    <title>Re: ways of integrating into Thunderbird</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1011</link>
    <description>&lt;pre&gt;

You have to know that TB has its problems when reloading messages,
saved as draft, for further editing, as it then strips off all custom
headers.  So an HC stamp created on the fly during editing and stored
in an X-Hashcash header would also get lost and had to be recreated
over and over again.

That's an ugly bug, well-known for years and documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=195716, which makes the
development of header modifying add-ons much more complicated than it
should be and imho has to be fixed asap.  Up to then you might
consider pooling tokens separately and adding them to message headers
not before the message actually gets sent.

Kind regards

Christian
&lt;/pre&gt;</description>
    <dc:creator>Christian Danner</dc:creator>
    <dc:date>2011-07-10T16:38:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1010">
    <title>Re: hashcash-sendmail breaks up long stamps</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1010</link>
    <description>&lt;pre&gt;Hello,

thanks for getting back.

You're effectively saying that splitting the stamp into short portions on
individual lines is not a bug but a feature. Having read the source you
quoted and having run a few more checks I strongly agree with you.

But why is procmail then not verifying the stamp? Well, it's apparently
the way procmail deals with line breaks in header lines. If I set up a
trivial provmail recepie

VERBOSE=yes
#hashcash
:0 Hfh 
* ^X-Hashcash: 
* $? cat &amp;gt; /tmp/zzz
|sed 's/\(^Subject:\)\(.*\)/\1&amp;lt;HC OK&amp;gt; \2/'

it should, one would assume, simply pipe the complete header into a file.
The content is however

&amp;lt;SNIP&amp;gt;

Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Hashcash: 1:20:110629:lvzwlcykh5uctsy5.t.hadvabvobs&amp;lt; at &amp;gt;antichef.net::MukaRTmGN+xq        J5RO:00000000000000000003lEb
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 0 (Mail was not recognized as spam);    Detail=5D7Q89H36p6hEpf6ttqws02bSs/CL6nBCZcAzW/pD0kbT/BaZcLmAWMxrJq35NjII8ZYU   X6M6dwR&lt;/pre&gt;</description>
    <dc:creator>Andreas Mattheiss</dc:creator>
    <dc:date>2011-06-30T17:24:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1009">
    <title>Re: ways of integrating into Thunderbird</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1009</link>
    <description>&lt;pre&gt;
that looks interesting.

Also looks interesting as does: 
http://email.about.com/od/mozillathunderbirdtips/qt/Add_an_Arbitrary_Custom_Header_to_Mozilla_Thunderbird.htm

we also want to grab messages inbound to check for valid stamps and handle it in 
some hand-waving appropriate method.

After I sent my message, it occurred to me that maybe we want to start stamp 
generation when the user starts creating a message and if the person sends the 
message before the stamp is done, then use the queuing and send later technique 
suggested above.  maybe I'll ask him about a mechanism for adding a plug-in that 
does some filtering/competition a work and sends the message when it's done. We 
would also need some sort of an alert indicator to say that the message hasn't 
been set yet.


&lt;/pre&gt;</description>
    <dc:creator>Eric S. Johansson</dc:creator>
    <dc:date>2011-06-30T15:32:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1008">
    <title>Re: ways of integrating into Thunderbird</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1008</link>
    <description>&lt;pre&gt;Would a hashcash plugin do the stamping as a background task, transparently?
- Or do we need to invoke a dialog and make it foreground? (imo hashcash
stamping should be as transparent as possible, in fact the only thing the
user should see is a checkbox on the thunderbird preferences screen to
enable it, and perhaps a 'number of bits' textbox value)

Anyway, here are a couple of links;

http://www.unsignedbyte.com/?page_id=4
Here's one called the 'send later' extension, it allows you to schedule
outgoing emails to be sent later. I think it's relevant as it uses a method
of moving the email to drafts, then monitors the drafts folder until a
certain time, and then moves it to outbox.

http://stackoverflow.com/questions/162057/how-do-you-insert-email-headers-with-a-thunderbird-extension
Uses js to intercept the outgoing email and insert headers.

Regards,
John.

On 30 June 2011 15:10, Eric S. Johansson &amp;lt;esj&amp;lt; at &amp;gt;harvee.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>John Honan</dc:creator>
    <dc:date>2011-06-30T15:20:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1007">
    <title>ways of integrating into Thunderbird</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1007</link>
    <description>&lt;pre&gt;http://sourceforge.net/apps/mediawiki/attachreminder/index.php?title=Main_Page

it seems to me that we could repurpose this plug-in as a way of adding proof of 
work stamps. One potential problem might be the time it takes to generate stamps 
and how long we get in the user's way.

Have folks seen better Thunderbird plug-ins we could repurpose?


&lt;/pre&gt;</description>
    <dc:creator>Eric S. Johansson</dc:creator>
    <dc:date>2011-06-30T14:10:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1006">
    <title>Re: hashcash-sendmail breaks up long stamps&lt; at &gt;&lt; at &gt;sig</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1006</link>
    <description>&lt;pre&gt;
For me, I created my own Python Hashcash script for use with Mutt[1]. The
command I issue is thus:

    hashcash -m [resource] -X -Z 2

The result is something like this:

    X-Hashcash: 1:20:110629:foo::NAOejG1BIDG75As8:ATi0

As per the documentation, stripping the zeros and adding compression adds
to the mint time, but it's never problematic. I've sent mails to family
members with 10-15 in the Cc: line, and every token is minted in a second,
or two, and added to the headers, and the end result is arguably cleaner.

    1. https://github.com/atoponce/Penny-Red

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-06-29T21:56:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1005">
    <title>Re: hashcash-sendmail breaks up long stamps&lt; at &gt;&lt; at &gt;sig</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1005</link>
    <description>&lt;pre&gt;
[...]
[...]

If you read the source for hashcash you find that `-Z' option
corresponds to compression. If the compression is set then hashcash
generats shortest possible stamps, otherwise it inserts some zeros to
align the input for the hash function and make calculations faster
(that's what I've read in a FAQ or somewhere else).

Try running this bash script and notice the stairs it produces

--8&amp;lt;---------------cut here---------------start-------------&amp;gt;8---
for f in `seq 11 64`; do \
    hashcash -b4 -qm $(seq -w 11 $f | tr -d '\n'); \
done | less -S
--8&amp;lt;---------------cut here---------------end---------------&amp;gt;8---

then add -X to hashcash.

The newline and the space characters are means to split long mail headers
into several lines reasonable of reasonable length. Take a look at
Received headers in any mail you receive and the RFC[1]

[1] http://tools.ietf.org/html/rfc2822#section-3.2.3
&lt;/pre&gt;</description>
    <dc:creator>Łukasz Stelmach</dc:creator>
    <dc:date>2011-06-29T12:41:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1004">
    <title>hashcash-sendmail breaks up long stamps&lt; at &gt;&lt; at &gt;sig</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1004</link>
    <description>&lt;pre&gt;Hi,

hashcash-sendmail appears to struggle with long stamps.

When i issue

hashcash -m -b20 -r andreas.mattheiss&amp;lt; at &amp;gt;xxxxx.xxxxxx.xxx

I get 

hashcash stamp: 1:20:110628:andreas.mattheiss&amp;lt; at &amp;gt;xxxxx.xxxxxx.xxx::LvM42IeOvGyF8fIY:0000000000000000000000000000v3E

(The xxx are not what was used for minting the stamp) 

So far so good. If I have hashcash-sendmail do that for me, I check the
logfile

Tue Jun 28 22:11:09 2011 hashcash-sendmail[6304]: made token X-Hashcash:
1:20:110628:andreas.mattheiss&amp;lt; at &amp;gt;xxx.xx::ZD6WiVAJVEPAJCs6:0000000000000
0000000000000000000000005QGb

This displays awkward here; in fact there are two spaces after the group
"0000000000000" and "0000000000000000000000005QGb" in the logfile; maybe
you want to try it with a slightly longish email adress and
check the logfile yourself. At least it displays like that, and there must
be something amiss, since procmail gets back to me with

------ pipe to |/overspill/sekundaer/bin/procmail /home/andreas/.procmailrc
       generated by andreas&amp;lt; at &amp;gt;localhost ------  &lt;/pre&gt;</description>
    <dc:creator>Andreas Mattheiss</dc:creator>
    <dc:date>2011-06-28T21:30:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1003">
    <title>passthrough mode, feature request</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1003</link>
    <description>&lt;pre&gt;Hi.

I started using hascash quite recently and as it happens I already have
found one missing feature: passthrough mode. It is a mode of operation
found in the Bogofilter software. A programme in this mode acts as
a filter and inserts a header that holds information that can later be
used by an MDA (e.g. procmail). For example Bogofilter headers look like
these:

 X-Bogosity: Unsure, tests=bogofilter, spamicity=0.887269, version=1.1.5
 X-Bogosity: Spam, tests=bogofilter, spamicity=1.000000, version=1.1.5
 X-Bogosity: Ham, tests=bogofilter, spamicity=0.157896, version=1.2.0

Hashcash could insert X-Hashcash-Info (e.g.) for every X-Hashcash
found. The header might contain

* actual number of bits "spent"

* "double spend" test results

* stamp's age (this is redundant but makes filtering with procmail
  easier)

* all the information from the X-Hashcash except the rand and counter
  fields

The difference between X-Hashcash and X-Hashcash-Info is that the latter
can be truested by MDA during classification a&lt;/pre&gt;</description>
    <dc:creator>Łukasz Stelmach</dc:creator>
    <dc:date>2011-06-22T11:13:19</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1002">
    <title>[MS-OXPSVAL]: E-Mail Postmark Validation Protocol Specification</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1002</link>
    <description>&lt;pre&gt;Curious if anyone has read over this, and what their thoughts are. This is
Microsoft's implementation of a proof-of-work system, similar to Hashcash
(I hesitate to call it a "derivative").

http://msdn.microsoft.com/en-us/library/cc433493%28v=exchg.80%29.aspx

From what I can tell, the protocol is covered by a royalty-based patent,
which will prevent any Free Software implementations. What I find
interesting, is the recipients, sender and subject are encoded into a
base-64 string. What's the purpose of this? base-64 encoding doesn't add
any significant time to the processing, and it's trivial to reverse getting
the original data.

Anyway, just curious.

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-06-19T21:16:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1001">
    <title>Re: hashcash on wordpress</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1001</link>
    <description>&lt;pre&gt;

Reading through that code, I see the server side doing at least as much work as the client in order to generate the code the client must execute.

Unless I'm missing something, that's not proof-of-work, it's just an attempt to prove the client is running a JavaScript interpreter.  It's certainly not even *similar* to hashcash aside from the misleading name.

David

&lt;/pre&gt;</description>
    <dc:creator>David Schneider-Joseph</dc:creator>
    <dc:date>2011-06-18T20:42:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/1000">
    <title>Re: hashcash on wordpress</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/1000</link>
    <description>&lt;pre&gt;
Indeed, and the Wordpress Hashcash plugin does more than hash obfuscated
JavaScript, and check for a match. The plugin is a proof-of-work system
which requires JavaScript to solve. Lines 363 through 484 of the
wp-hashcash.php contain the algorithm he uses to expense CPU time. It is
proof-of-work, it's just not Hashcash.

--
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
&lt;/pre&gt;</description>
    <dc:creator>Aaron Toponce</dc:creator>
    <dc:date>2011-06-14T20:34:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.mail.spam.hashcash/999">
    <title>Re: hashcash on wordpress</title>
    <link>http://permalink.gmane.org/gmane.mail.spam.hashcash/999</link>
    <description>&lt;pre&gt;

A single hash is not proof-of-work.

David


&lt;/pre&gt;</description>
    <dc:creator>David Schneider-Joseph</dc:creator>
    <dc:date>2011-06-14T20:04:51</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.mail.spam.hashcash">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.mail.spam.hashcash</link>
  </textinput>
</rdf:RDF>

