[hashcash] Re: Hashcash vs. Time?
- From: Adam Back <adam@xxxxxxxxxxxxxxx>
- To: hashcash@xxxxxxxxxxxxx
- Date: Tue, 20 Apr 2004 18:54:29 -0400
A separate side of this discussion aside from how postage increases
are propogated, is how the postage increases are decided.
Clearly one needs to authenticate those increases, as an increase
straight up to 64 bits would be very disruptive.
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.
> >>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.
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.
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...)
Adam
>
> passive broadcast attaches current local postage rates to each mail
> message as it is being sent. As events trigger postage increases,
> subsequent mail messages reflect the higher postage rate in the rate
> tag.
> >>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.
>
> In the early days, this would probably be a good thing for camram
> because there won't be that many users but after a certain point,
> spammers could bring down a significant chunk of the e-mail ecology by
> sending out a small number of spam messages with stamps. After receipt
> of the spam, there would be a flurry of messages communicating the
> postage rate increase and much amusement would ensue (NOT!)
>
> therefore, a partial injection in the form of sending rate increase
> notices to a random selection of known camram users might be a
> reasonable compromise between the quick response of the full injection
> and the slow response of passive broadcast.
>
> benefits: fast response
>
> downsides: easy triggers of e-mail DOS
>
> ---eric
>
Other related posts:
