[hashcash] Re: blacklist to Brown list conversion

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: