Re: [Asrg] My take on e-postage

> > > Have you read the taugh whitepaper?  Some of the points it raises
> > > apply to your sketched design.
> > No - do you have a link?
> http://www.taugh.com/epostage.pdf - or at least that's where I found it
> when I fetched it, and there's still something there now; I haven't
> checked that it's the same, but have no reason to think it's not.
At least some of it's objections seem to hinge on stamps being 
anonymous.  Unlike e-coins, that need not be the case.  As I mention 
below, some problems are more easily solved with identified stamps.
> > I'm afraid the micropayment argument doesn't hold water, because you
> > can always pay for blocks of, say, a thousand stamps at a time, and
> > exactly how hard is it to keep track of one counter per paying
> > customer?
> It's a lot more than that that the stamp vendor needs to keep track of.
> The first thing that comes to mind is that recipients need a way to
> check that a stamp hasn't already been used - and even if the sender
> sends them in order, the recipients won't necessarily check them in
> order.
Not necessary, if the stamp cryptographically includes both the sender 
and recipient addresses.  If the recipient doesn't recognise the 
address the stamp was made for delivery to, it's invalid.
> > > Furthermore, the money paid for stamps goes to the wrong place, ie,
> > > not to the recipients.  (Stamp vendors could in principle pay
> > > recipients who get mail with their stamps.  This involves creation
> > > of _another_ micropayment infrastructure per stamp vendor.)
> > Good point.  There's a way around this, though - how about the
> > recipient's stamp vendor collects a portion of the stamp's value from
> > the sender's stamp vendor, and credits it to the recipient's account?
> Sounds superficially plausible, but what do you do for fraud
> prevention (that is, how can each tell that the other is reporting
> honest totals)?  This gets an awful lot of regulatory entities
> involved, especially when (say) one of them is in China and the other
> is in Nigeria.
I don't have a strong solution to that.  However, it should be a simple 
matter to at least list the actual stamps being claimed, and check them 
against stamps issued.
In the event of a dispute - for example, two vendors try to claim the 
same stamp - we start wanting to prove which claiming vendor actually 
has the stamp's addressed recipient as a customer.
One way of doing that, which should be cheap enough to deal with small 
disputes, is to send a special stamp to the recipient and see which 
vendor it comes back from.  Since the revenue from the stamp belongs to 
the recipient, it doesn't matter if he switched vendors in the 
meantime.  It also doesn't particularly matter if the test stamp never 
comes back.
For wider disputes, when measurable amounts of money get involved, you 
start bringing humans in to negotiate.  At some point, you might need 
to downgrade disputing vendors' reputation, or even start legal 
proceedings.  That last, however, is way beyond any reasonable 
technical measures, and indicates (alleged) fraud on the order of 
hundreds of thousands of stamps.
> > This ignores mailing lists and the like, however.  [...]
> Very true.
>
> > Another solution is to use a proof-of-work stamp,
> There really is no such thing.  Hashcash is not something that can be
> attached to a message; it requires an interactive protocol.  (There may
> be some way to do proof-of-work in an open-loop form, but I haven't
> seen it yet.)
Why is this?  Is it because the validity threshold of the recipient 
isn't a priori known to the sender?  If so, then a variation on the 
usual "delivery failed" mechanism (insufficient hashcash for delivery, 
please send 30 bits) should handle it.  If for some other reason, 
please expand.
> > Recipients can whitelist the trustworthy [stamp vendors] and
> > blacklist the others - which is a much easier problem than the
> > present practice of blacklisting individual senders.
> For a little while, until spammers start creating throwaway stamp
> vendors, the way they create throwaway domains now.
Which is why I said whitelists as well as blacklists.  It does mean 
there will be some barrier to entry for new stamp vendors, but I don't 
know if that will be a serious problem.
> Still, it may be worth trying.  Most of this - on both our parts - is,
> fundamentally, speculation, at present.  After all, none of this stops
> people who mutually feel like it from continuing to use SMTP the way we
> all have been so far.
Naturally.  This is also why the proprietary systems being proposed by 
certain large corporations may not succeed, however much money is 
behind them.
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg