[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
- [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] 3. Proof-of-work analysis Barry Shein
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- RE: [Asrg] 3. Proof-of-work analysis Hallam-Baker, Phillip
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- Re: [Asrg] 3. Proof-of-work analysis Alan DeKok
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] 3. Proof-of-work analysis Alan DeKok
- Re: [Asrg] 3. Proof-of-work analysis der Mouse
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- RE: [Asrg] 3. Proof-of-work analysis grsa
- RE: [Asrg] 3. Proof-of-work analysis Bill Cole
- Don't blame the list, blame me (was RE: [Asrg] 3.… Bill Cole
- RE: [Asrg] 3. Proof-of-work analysis Bill Cole
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Tony Finch
- Re: [Asrg] 3. Proof-of-work analysis Seth Breidbart
- Re: [Asrg] Re: 3. Proof-of-work analysis Jonathan Morton
- Re: [Asrg] Re: 3. Proof-of-work analysis Barry Shein
- Re: [Asrg] 3. Proof-of-work analysis Jonathan Morton
- [Asrg] Re: 3. Proof-of-work analysis Philip Miller
- Re: [Asrg] 3. Proof-of-work analysis Jon Kyme
- Re: [Asrg] Re: 3. Proof-of-work analysis Mark Baugher
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. About hashcash v1 (was: Proof-o… Jonathan Morton
- [Asrg] Re: 3. Proof-of-work analysis Adam Back
- Re: [Asrg] Re: 3. Proof-of-work analysis william(at)elan.net
- Re: [Asrg] Re: 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. Proof-of-work analysis Richard Clayton
- Re: [Asrg] Re: 3. Proof-of-work analysis william(at)elan.net