[hashcash] Re: Hashcash vs. Time?

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: