[hashcash] Re: status of hashcash version 1?
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Wed, 28 Jul 2004 15:13:25 -0400
Adam Back wrote:
And the last and probably biggest issue is how to deal with CPU
inflation. I was thinking this could be implemented using the
extension mechanism. One way is to pass around p2p the largest
required-hash definition seen so far, and have someone / some
group changing this over time using some pre-agreed criteria.
I advocate using a "who you communicate with" peering arrangement for
setting postage rates. the idea is knowing the postage rates of your
neighbors is far easier in terms of knowing what to set for your own
postage rates. One problem to defend against is a sudden spike in
inflation rippling through the entire system. For example a spammer
triggering 32-bit stamps as the norm.
One problem I've had is I don't quite know how to model this system
quite yet. Partly because I haven't really have the time but something
in my intuition says it's worthwhile.
It's a form of cellular automaton. A simple form of which is John
Conway's life game. So the trick is developed some rules, and test the
rules by model with hostile entities.
Anybody game?
Proposed rules:
Distribution of information:
1) with every mail message (i.e. passive distribution)
2) on every change to everyone on your white list (i.e. active distribution)
3) on every change to only the top X percent active white list entries
4) on every change to a percentage of randomly selected white list entries
trigger mechanisms:
1) average of scores seen from white listed entries
2) 80 percent of maximum score seen from white listed entries
3) one bit higher than stamp on spam with stamp
limits on change:
1) absolute limits
2) relative limits
3) time changing limits
the trigger mechanism controls how fast your rates go up. The
distribution mechanism controls how fast you communicate that increase
to others. A spammer would target the trigger mechanism because that's
the gateway to propagating an erroneous rate increase. My sense of the
problem says that the average score of what you see from white listed
entries plus a weighted factor for any spam with stamps set your local
postage. I would also limit any increases to at most two bits above
what you currently are using as a stamp value. It may be necessary to
use a time changing limits as well to minimize damage if we figured wrong.
anyway, that's about as far as my thoughts have gone. I do believe it's
a reasonably decent way of handling the CPU inflation issue. On the
edge of this is how to handle a challenge response mechanism with people
sending you stamps but are of insufficient value. One question is can a
spammer use this mechanism to identify and target specific folks with
spam at a higher rate?
More later
---eric
Other related posts:
