Subject: Re: [Asrg] Re: "HashStamp" == hashcash? (Re: Stamping)

From: Jamie Lawrence <[email-masked]>
Date: Sun, 23 Mar 2003 18:28:13 -0500

On Sat, 22 Mar 2003, Vernon Schryver wrote:

> There are reasons why after at least 6 months the hashcash proposals
> are still only ideas.

Hashcach is fundamentally flawed. Cool and interesting, but doomed.

Authenticating headers opportunistically can work. Baby steps. 

-j

-- 
Jamie Lawrence                                        [email-masked]
"What empires lavish abroad, they cannot spend on good republican 
government at home: on hospitals or roads or schools. A distended 
military budget only aggravates America's continuing failure to 
keep its egalitarian promise to itself."
   - John Quincy Adams

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 Mar 2003 07:51:53 -0800

> Authenticating headers opportunistically can work. Baby steps. 

Hashcash is essentially an authorization step, the authorization 
is implicit in spending the time required to send the email.

There is a hierarchy of approaches here.

Authentication 			- Simplest, lowest cost
Authentication + Whitelists	- more maintenance
Non-convertible cash schemes	- require state maintenance
Convertible cash schemes	- require settlements

Convertible cash schemes are very complex as they require settlements
and that is expensive - none of the existing settlement systems in use
today can manage trades for less than tens of cents per transaction.
Convertible cash schemes also involve a new fraud incentive.

The problem I have believing the cash schemes is that the spam senders 
appear to be willing to spend more to create garbage than many users.

Rememberthat 'Authentication' here could involve moving to a pull
protocol rather than a push protocol FOR CERTAIN APPLICATIONS. Here 
NNTP with limited posting rights is a posibility, although its 
failure to manage spam on Usenet means that many will dismiss it, 
probably unfairly. Another possibility is RSS.

There is only a subset of messaging that can be managed that 
way unfortunately. Mailing lists, alerts, newsletters, etc. But
we are not going to find a silver bullet, we need to address each
use independently and accept that there will be need for different 
approaches.

One interesting approach would be to combine RSS with a notification
pig via UDP. So the user subscribes to a stream, the stream says 
something like 'i update every 15 minutes, hour, day, whatever'. The
user can poll, or the user can wait for a UDP packet that gives the 
serial number of the last update, thus allowing updates earlier than
the indicator says.

This system can be made quite robust, unsolicited packets are simply
ignored as there is no point unless there is a subcription. If a user
stops downloading the feed for some time the sender can simply delete
the user's account and stop sending the udp packets.

This type of scheme could operate in parallel as a feature of a 
traditional mailing list agent.

		Phill