[hashcash] Re: Thanks for the replies

  • From: Adam Back <adam@xxxxxxxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Tue, 30 May 2006 04:07:18 -0400

On Sat, May 27, 2006 at 01:34:02AM +0200, Mate Soos wrote:
> >I think you identified the problem with the hash of email address for
> >Bcc -- a guess can be confirmed.  To expand on that also note that a
> >"guess" can mean hashing a database of 1 billion email addresses to
> >see which it is -- hashcash shows us this will take just an hour or
> >so.
> I actually thought about this possiblity but I thought that guessing
> would be hard if we have no clue about the possible the address of the
> other person. I still think it is, though guessing easy addresses (like
> bob@ and tom@ with easy domains like @hotmail.com, @aol.com, +domains we
> frequently email) can be trivial. I will think hard about this :D

Yes but what I am saying is you dont need to guess, you just buy or
harvest with a search spider addresses from web pages, newsgroups and
mailing lists.  Then you try all of the addresses.  Of course if the
user doesnt appear on those types of forums you wont find it without
guessing which has the problem you mentioned.

> >Something like each sender sends
> >their highest received hashcash bits requirement. We can have some
> >transparent process for deciding the current (some formula on current
> >hardware say), and update it say once a year.
> Then different machines with different recieved emails and different
> partners will set different limits (this is like agreeing on time in a
> distributed environment - everybody will think it's something
> different). From a practical point of view: with distributed things,
> cheating is always too easy, no matter how good the idea. And then I
> might be able to convince the other that my computation limit is low. Or
> put a lot of nodes in which I control, and set the computation limit
> low, forcing everybody to put it down.

It would be like a ratchet, you could never reduce the limit, only
increase it.  And not anyone can increase it, they have to have the
authenticated token from the authority saying it must increase.

But I think the problem could be closed communities, a small group of
people who dont upgrade their software, and never communicate with
anyone outside that group.  They will never see updates.

They might send messages to someone outside their group with too small
stamps, after an update they have not seen.

Potentially you could mix it so that say the stamp never upgrades more
than once per year.  After six months if no update is seen at some
random time between 6months and 1 year to spread out the load, the
client can fetch the current stamp limit from a web site or DNS.


Other related posts: