[hashcash] Re: Hashcash vs. Time?
- From: "Eric S. Johansson" <esj@xxxxxxxxxx>
- To: Adam Back <adam@xxxxxxxxxxxxxxx>
- Date: Tue, 20 Apr 2004 18:18:23 -0400
Adam Back wrote:
> Could you explain what you mean in 4 and 8?
I probably should explain all of them to reduce unspoken assumptions.
> Not sure of terminology -- which of those corresponds to my "include
> an extra header in email which authenticates the update. Users send
> around the latest update in emails they send, so that clients learn in
> a p2p fashion from other people, from new clients (which would start
> with latest version) and so on", and what the other type of broadcast
> entails?
that's actually type 4b. I was floating the concept of type 4a in the
days of izzy and I wasn't sure if it got lost in the chatter. sounds
like you came up with the same idea (and I really don't care who was
first). Let's make sure it's a good one and go forward with it
> Do you find the above "good enough" -- ie simple, generally likely to
> be effective.
don't know yet. Haven't had any time/energy to run a model.
> On Tue, Apr 20, 2004 at 05:03:05PM -0400, Eric S. Johansson wrote:
>
>>maybe we should create a small page about the trade-offs of the four
>>different techniques we know about today for managing postage?
>>
>>1) challenge response (nobody's favorite)
you send me some amount of postage that is less than what I need (down
to 0) and I send you a postage to notice asking for the new higher amount.
Benefits: most direct propagation of the postage amounts. Is really
annoying if you aren't using camram at all and see these postage due
notices.
Downsides: Joe jobbing. Spammers can send e-mail with valid return
address and no postage which floods valid address with postage due
notices. Worse yet, they spread the return addresses out so that there
is a chance that people will just fill in the postage due notice and
allow Spam through.
>>2) increase by the clock
as the days tick by, increase postage according to some formula.
benefits: easy to implement, completely decentralized
downsides: cannot adapt to attacks from spammers or changes in Moore's Law.
>>4) passive broadcast (my favorite)
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.
benefits: the passive technique will notify more slowly and it seems
that it will be a more stable/less disruptive process for propagating
rate increases.
downsides: the rate of propagation of information is only as fast as a
given user sends e-mail to other users. Its entire possible that the
flow of notifications of rate increases could slow or stall based on the
users activity level.
>>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:
