[1] Hashcash fails on inspection because attackers control vastly more computing resources than defenders, by several orders of magnitude.
The idea behind Hascash is *not* that it will *stop* the flow: it, by itself, most certainly will not. However, no successful security strategy relies on any single modality for successful coverage of any issue.
Hascash is another of the various forms of tarpitting, which also does not stop anyone, but it does slow it down, and every little bit helps.
I realise I may well be just another "stupid newbie" in your eyes, so please explain why something that can enforce a fixed amount of work to each and every transaction on the SENDER's side is a bad idea by itself.
Currently, almost 100% of the cost of protecting yourself falls to your own machines and systems. On the scale of a modern spam run (tens of millions to hundreds of millions of emails per run) the offloading of even a minor workload onto the sender would be a significant overhead transferred to the spammer.
Like everything else in the security mileiu, hascash is yet another layer.
But more importantly, it is a layer than can be provably shown to affect
Mallory more than it will Jane.
No matter how many stolen cycles are used to bypass a hascash like scheme, those cycles still *must* be expended by the spammers resource pool.
This can *only* be a Good Thing.
-- Yours, J.A. Terranson sysadmin_at_mfn.org 0xpgp_key_mgmt_is_broken-dont_bother
"Never belong to any party, always oppose privileged classes and public plunderers, never lack sympathy with the poor, always remain devoted to the public welfare, never be satisfied with merely printing news, always be drastically independent, never be afraid to attack wrong, whether by predatory plutocracy or predatory poverty."
Joseph Pulitzer 1907 Speech