Re: e-postage stamps, was Welcome to the new(ish) ASRG list

On March 19, 2013 at 01:49 [email protected] (John Levine) wrote:
 > 
 > Once again, this is a well known difficult problem for any digital
 > currency, one that has never been solved at scale.

I'm actually quite familiar with the double-spending problem.

One difference with e-postage is that the downside is different, some
email gets accepted with fraudulent postage. Not a big deal.

That's a very different failure mode than, for example, buying stuff
on Amazon with double-spent e-currency.

Large-scale Fraud should pretty easy to detect. Small scale fraud
isn't very interesting:

An e-postage stamp contains an authority server id.

You query the authority server, there could be many, much like you
would with DNS.

It returns yes/no, basically, and remembers the id of the stamp.

It won't return yes again for that exact stamp id.

There can be multiple layers of plausibility filtering, such as the
(sender,stamp-id) tuple.

To improve distribution you have two tools:

  1. The embedded stamp authority id can refer to any one of many
     different authority servers.

  2. Like DNS the id verification can be hierarchical and redirect to
     other servers.

Caching locally is a possibility, although not necessary, just like
DNS, again.

A large site might choose to watch for duplicates.

This of course does not improve or inform the id servers but might be
a practical trade-off particularly if one is likely to be bombarded by
a million fraudulent stamps if they are hit by any (e.g., large ISPs.)

That challenges the spammer to not send duplicates to any one site,
particularly if they suspect it is doing local caching.

I believe one can make it difficult to generate valid stamp-ids w/o
some cryptographic key.

Which, if true, leaves the spammer only having access to stamp-ids
which are valid and then re-spending them.

Stamp-ids should have a short life-span.

I think only valid more or less while they're actually moving from
server to server (including forwarding servers) but that requires
thought also.

I realize mail can be in transit perhaps about three days, or maybe
worst-case three days per hop. Ok absolute worst case is something
like 16 hops @ 3 days per hop, 48 days, but how common is that and
does it need to be covered?

But one only has to cover the 99% case not the outliers (another TBD,
what to do in those cases? How rare are they? Must all ids have the
same life span or can a sender anticipate slow paths?)

Assuming they have a short life span and a spammer can't generate
them, only copy them, how many valid stamp-ids could a spammer have
access to?

Interesting and crucial questions.

But the important point is that the failure mode isn't very serious,
some spam. If it works 99% of the time or even 95% that should be a
major improvement.

Particularly if it:

  a) Improves detection: Hey IP x.y.z.w is sending fraudulent stamps!

  b) Is likely to be punished.

  c) Creates an economy around this enforcement (postage income.)

I think (c) is why it could work. Sometimes you just have to send out
the flatfoots, but first you have to be able to pay the flatfoots.

-- 
        -Barry Shein

The World              | [email protected]           | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD        | Dial-Up: US, PR, Canada
Software Tool & Die    | Public Access Internet     | SINCE 1989     *oo*