On Wed, Dec 3, 2008 at 5:06 PM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
the 1000 recipient stamps. Each of the 1000 recipients recognize
a coin wrapped in their own stamp and opens the coin and attempts
to redeem it with the bank, which only redeems the first such coin,
but is alerted to attempted fraud and revokes the sender's account.
OK, that sounds like the usual micropayment token cancelling
bottleneck that nobody knows how to scale.
Actually, micropayment cancelling isn't the part of the story I'm
advocating, I'm advocating for a standard for transmission of coins.
I really don't care how they're franked, what their value is, or how
they are verified. What I provided above is only a single "bank"
example as an extension to your question, please don't
forget there is the trivial example where the coin is NULL, i.e.,
the recipient chooses to accept stamped mail without coins.
Thus there is only the initial sender presentation of identity and
the recipient "stamp-generator" issues a stamp (or not) based
solely on the identity and properties of the TCP session.
The NULL coin example may not be very interesting, but it's
pretty close to what Barry's talking about with SSL-type
issue of identities. Where is that scaling problem when
no "bank" is involved in individual mail transactions,
only the initial set-up of identities?
Gerald
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg