[hashcash] Re: Hashcash vs. Time?
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 20 Apr 2004 21:32:07 -0400
Adam Back wrote:
> A separate side of this discussion aside from how postage increases
> are propogated, is how the postage increases are decided.
exactly. This is what I call a rate increase event. I perceive there
to be at least three rate increase events we should worry about. Manual
increase, spam feedback, and peer feedback. Manual increase is
obviously someone increasing the local postage rate manually, spam
feedback is when your client tells the postage system that there was a
piece of spam with a stamp on it. Usually, it doesn't involve user
intervention other than saying "this e-mail is spam". The last is
collecting postage rates from inbound e-mail and if a certain proportion
of camram enabled neighbors have increased their rates, then your rates
go up.
on a side note, it dawns on me that we might want to define the baseline
as however long it takes the local machine to generate a stamp of at
least 15 seconds duration. As horsepower increases, so will the local
postage value and if we can work out a good postage due mechanism, this
will propagate outward to others gradually raising postage rates.
this way we can do Moore's law increases without having to decide on a
formula or a process.
> Clearly one needs to authenticate those increases, as an increase
> straight up to 64 bits would be very disruptive.
I agree. My gut feeling is that postage increases should be one bit per
trigger. A trigger is one of the events described above. So if you
have 15 neighbors that have increased their postage by three bits, and
event triggers a postage increase locally, the rate will only increase
by one bit and the clock will reset for the next trigger.
Yes, this will mean a slow increase to meet the local average postage
rate but it's a reasonable resistance against postage increase attacks.
Trying to calculate a reasonable threshold based on staff values is not
something I consider wise given that the collision in a stamp is a
probabilistic event and can be anything up to the full number of bits in
the hash. It's all luck. :-)
> Possible approaches:
>
> A) someone just decrees the current rate, takes input and periodically
> according to some policy increases it
>
> B) look at averages seen and let everyone collaboratively set the rate,
> somewhat locally
>
> B) seems a bit risky to me because it is based on the local view (the
> set of people you typically communicate with) and so if you step
> outside of that into other circles of communicants you may not send
> enough postage. Another risk is that someone could DoS you by sending
> you enough mails with high postage to convince an
> occasional-email-user that the average is very high.
>
> A) is simpler, lower risk, but if that person does something stupid,
> we're back to the DoS situation.
>
> I'm favoring A) at present, as pragmatic right now, in the absence of
> any other workable solutions.
actually, I'm in favor of B with a very draggy increase mechanism
(outlined above) and characterizing the kind of events that would
trigger a postage increase.
>>>>8) active broadcast (i.e. full and partial injection)
>>
>>active broadcasting is like passive broadcasting by each message has a
>>header are indicating the current rate for the message originator. But
>>unlike the passive broadcasting technique, the active technique sends
>>the shortest message possible to all of the known camram users to inform
>>them that a rate increase event happened.
>
>
> That sounds like it wouldn't scale that far, as there will be a huge
> flood of messages until everyone's MUAs eventually realise that
> everyone knows the postage has increased and there is no point further
> broadcasting that fact.
>
> Probably preferable to rely on slow change, overlapping creation /
> acceptance (create new, accept previous period), plus fact that people
> generally tend to communicate with people in a conversation type
> pattern so that they generally know the view according to the people
> they communicate with.
I agree. I think that most a partial injection mechanism that's
extremely limited might be appropriate. But again, we should model list
to see just how effective it would be in what kind of load we would
have. For example, would it makes sense to get everybody in your same
domain because you are all on the same mailserver or would you be better
off carrying the message to other domains and ignore your own.
don't forget also that people that you communicate with won't be getting
stamps. Well, least not hashcash stamps. After all, they are by
definition "friends".
> Another problem area might be scripted bot email senders, such as web
> page CGIs etc which don't as such receive email, and so may not learn
> that postage has increased. This suggests that current-postage should
> be system-wide, so that if one user learns of the increase, CGIs and
> other users benefit from that.
good point. Those might be sites that could use injection messages.
Maybe they should have a "postage rates go here" header option. Which
will be only used for postage rate increase messages.
> However still in the bot-sender scenario there are separate systems
> which just run web (www. server on different server to user mail
> accounts).
>
> It might be nice if there was a place to find out what the current
> rate is periodically (eg once every 3 months check DNS or a web page),
> but the scalability of that is a bit of a question. ie bandwidth at
> hashcash.org or anywhere is limited; DNS is widely cached but can you
> rely on DNS client / library in server environments to be correctly
> configured to not by-pass caching -- or to anyway go to the SOA...)
I would suggest that this is not the wisest approach. There are lots of
problems including denial of service and corruption of records not to
mention who the hell is going to keep updating this dammed record
through infinity. This is one albatross I do not wish around your or my
neck.
I'm beginning to think more and more that the identifying record and
injectable message might be the way to go. Denial of service attack
reduction could be the requirement of a stamp that is of the same value
as the postage increase notification. That way if any attacker tried to
force the standard to a 64-bit stamp, then they would have to generate
one first multiple times until the local postage increased to that level.
obviously, we need to work this out more but that's for another day.
---eric
Other related posts:
