[hashcash] Re: blacklist to Brown list conversion
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx, camram-development@xxxxxxxxxxxxxxxxxxxxx
- Date: Thu, 18 Jan 2007 10:16:08 -0500
Eric S. Johansson, who definitely talks too much, wrote:
to bring it back on topic, a blacklist repair service based on proof of
work systems could be quite useful. Especially if we can make it
something that doesn't have to change the message recipient. For
example, make it a transaction between blacklisted site and blacklist
database. Something like "I have been blacklisted from..., I want to
send one message, how much?" and after they received the price, the
sender can either generate the stamp or throw away the message. After
some threshold or number of times of generating stamps, the stamp price
declines as long as there are no hits reinforcing the pricing level. Or
something like that. Yes, I am a fan boy for dynamic pricing systems
because that lets us get around Moore's law inflation and reward people
for doing good things.
thinking some more on this, I do believe the key to dealing with
blacklists is a Brown list CBL type system driven by tokens from blocked
sites.
on the sender side, there should be some form of proxy intercepting
traffic between the sending MTA and the receiving MTA. The proxy should
be on the sending MTA side of the transaction. If the proxy detects a
blacklist block, it takes the message that had been sent and stuffs it
in a queue. The queue consumer queries the CBrL for pricing, generates
the appropriate size token, and then delivers the message. The CBrL
then gives one "not blocked" response for a query about the token
generating address.
On the other side of the equation is the number of reports of bad
behavior. As the number reports climb, the cost of postage goes up. As
the number of reports drop and the number of tokens generated go up, the
cost of postage goes down.
Pricing for stamps in this context should be reasonably large. I think
that something like a 16 minute stamp would not be unrealistic in the
very beginning. It's large enough that it will dissuade spammers from
sending a single message but it's small enough to make it possible for
someone to get a "hey, something's broken" message. And, as the pricing
model describes, it will get better with time if you clean up your act.
I think the "easiest" way to implement this would be to take advantage
of modern firewall rules to intercept traffic and redirect it to a proxy
program. The proxy front-end should be something written in something
like C/C++ so that it will run reasonably fast for the 99% case. The
backend can be cobbled together out of twopenny blue pieces because,
quite frankly, you don't care about performance when you are generating
eight or 16 minute stamps.
The threat model is the same as other proof of work systems, i.e.
overwhelming force applied to the problem. Using the zombie calculator
13 billion spam baseline and 16 minutes stamps, you'd need 441 million
zombies. with proper feedback, the number of zombies needed would
increase significantly as individual zombies are identified and priced
out of the market. The other advantage is that stampers can't send
anywhere near as many spam messages.
A couple of challenges involve scaling. How does one scale such a
service. How does one communicate pricing information across a network
in such a way that it can't be double spent?
I don't think the problems should dissuade one from trying because this
is another good example of how proof of work stamps can be used in a
positive fashion to repair a broken system.
anyway, that's my thoughts on the subject.
---eric
--
Speech-recognition in use. It makes mistakes, I correct some.
Other related posts:
