[Asrg] Re: 3. Proof-of-work analysis

Adam Back <adam@cypherspace.org> Wed, 19 May 2004 03:08 UTC

Received: from optimus.ietf.org (www.iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08101 for <asrg-archive@odin.ietf.org>; Tue, 18 May 2004 23:08:21 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHQ0-0002Ix-4m for asrg-archive@odin.ietf.org; Tue, 18 May 2004 23:06:58 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4J36uSK008857 for asrg-archive@odin.ietf.org; Tue, 18 May 2004 23:06:56 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQHKc-0001ei-Mu for asrg-web-archive@optimus.ietf.org; Tue, 18 May 2004 23:01:23 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07856 for <asrg-web-archive@ietf.org>; Tue, 18 May 2004 23:01:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQHKZ-0001D3-5Q for asrg-web-archive@ietf.org; Tue, 18 May 2004 23:01:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQHJf-00015p-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 23:00:24 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BQHIg-0000yA-00 for asrg-web-archive@ietf.org; Tue, 18 May 2004 22:59:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQH9e-0008G4-Iq; Tue, 18 May 2004 22:50:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BQDbL-0007jy-4x for asrg@optimus.ietf.org; Tue, 18 May 2004 19:02:24 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26616 for <asrg@ietf.org>; Tue, 18 May 2004 19:02:18 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BQDbH-000526-S5 for asrg@ietf.org; Tue, 18 May 2004 19:02:19 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BQDaD-0004xq-00 for asrg@ietf.org; Tue, 18 May 2004 19:01:14 -0400
Received: from main.gmane.org ([80.91.224.249]) by ietf-mx with esmtp (Exim 4.12) id 1BQDZG-0004sW-00 for asrg@ietf.org; Tue, 18 May 2004 19:00:14 -0400
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1BQDZA-0006Fw-00 for <asrg@ietf.org>; Wed, 19 May 2004 01:00:08 +0200
Received: from client-82-2-92-5.mant.adsl.virgin.net ([82.2.92.5]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Wed, 19 May 2004 01:00:08 +0200
Received: from adam by client-82-2-92-5.mant.adsl.virgin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <asrg@ietf.org>; Wed, 19 May 2004 01:00:08 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: asrg@ietf.org
From: Adam Back <adam@cypherspace.org>
Lines: 103
Message-ID: <40AA92E7.4090907@cypherspace.org>
References: <LV1hjGBSmTqAFAry@highwayman.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
Cc: cypherpunks@minder.net, rah@shipwright.com, cryptography@metzdowd.com
X-Gmane-NNTP-Posting-Host: client-82-2-92-5.mant.adsl.virgin.net
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114
X-Accept-Language: en-us, en
In-Reply-To: <LV1hjGBSmTqAFAry@highwayman.com>
X-Enigmail-Version: 0.76.8.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Re: 3. Proof-of-work analysis
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/asrg/>
Date: Tue, 18 May 2004 23:49:11 +0100
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Here's a forward of parts of an email I sent to Richard with comments on
his and Ben's paper (sent me a pre-print off-list a couple of weeks ago):


One obvious comment is that the calculations do not take account of
the CAMRAM approach of charging for introductions only.  You mention
this in the final para of conclusions as another possible.


My presumption tho don't have hard stats to measure the effect is that
much of email is to-and-fro between existing correspondents.  So if I
were only to incur the cost of creating a stamp at time of sending to
a new recipient, I could bear a higher cost without running into
limits.

However the types of levels of cost envisaged are aesthetically
unpleasing; I'd say 15 seconds is not very noticeable 15 mins is
noticeable and 1.5 hrs is definately noticeable.


Of course your other point that we don't know how spammers will adapt
is valid.  My presumption is that spam would continue apace, the best
you could hope for would be that it is more targetted, that there are
financial incentives in place to make it worth while buying
demographics data.  (After all when you consider the cost of sending
junk paper mail is way higher, printing plus postage, and yet we still
receive plenty of that).

Also as you observe if the cost of spamming goes up, perhaps they'll
just charge more.  We don't know how elastic the demand curve is.
Profitability, success rates etc are one part of it.  There is an
interplay also: if quantity goes down, perhaps the success rate on the
remaining goes up.  Another theory is that a sizeable chunk of spam is
just a ponzi scheme: the person paying does not make money, but a lot
of dummy's keep paying for it anyway.




Another potential problem with proof-of-work on introductions only, is
that if the introduction is fully automated without recipient opt-in,
spammers could also benefit from this amortized cost.  So I would say
something like the sender sent a proof-of-work, and the recipient took
some positive action, like replying, filing otherwise than junk or
such should be the minimum to get white-listed.




On the ebiz web site problem, I think these guys present a problem for
the whole approach.  An ebiz site will want to send lots of mail to
apparent new recipients (no introductions only saving), a popular ebiz
site may need to send lots of mail.


Well it is ebiz so perhaps they just pass the cost on to the consumer
and buy some more servers.




Another possibility is the user has to opt-in by pre-white-listing
them, however the integration to achieve this is currently missing and
would seem a difficult piece of automation to retrofit.




One of the distinguishing characteristics of a spammer is the
imbalance between mail sent and mail received.  Unfortunately I do not
see a convenient way to penalize people who fall into this category.




Also because of network effect concerns my current hashcash deployment
is to use it as a way to reduce false positives, rather than directly
requiring hashcash.  Well over time this could come to the same thing,
but it gives it a gentle start, so we'll see how long it is before the
1st genuine spam with hashcash attached.

CAMRAM's approach is distinct and is literally going straight for the
objective of bouncing mail without some kind of proof (hashcash or
reverse-turing, or short term ability to reply to email
challenge-response).

Adam

Richard Clayton wrote:
> [...] Ben Laurie) and I have recently
> been doing some sums on proof-of-work / client puzzles / hashcash
> methods of imposing economic constraints upon the sending of spam...
> 
> Ben wanted to know how big a proof was needed for a practical scheme
> he was considering -- and I told him it wasn't going to work. We then
> carefully worked through all the calculations, using the best data
> that we could obtain -- and we did indeed come to the conclusion that
> proof-of-work is not a viable proposal :(

> Paper:
> 
>      http://www.cl.cam.ac.uk/~rnc1/proofwork.pdf



_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg