ietf-asrg
[Top] [All Lists]

Re: [Asrg] About that e-postage draft [POSTAGE]

2009-02-23 17:38:47
On Mon, Feb 16, 2009 at 3:22 PM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:

You probably don't want to do that, since the performance of book
entry transactions is worse than for bearer ones.

But bearer system cannot be done securely, implying book entry system
anyway, so let us hear no more on bearer systems.


If you're doing
book entry, you need at least a journalling system to log the entries
to be added to each account, if not locks on each account to maintain
the balance.

So what?

Imagine a coin minting/redemption protocol in which central
authorities issue book-entry tokens and associate them with value
which is transferrable.  The primitive operations available include

   mint  here is some value from my account into a coin account and
give me the coin.
   bite   here is a coin code, what if anything is it worth?
   melt  here is a coin code please transfer its value into my account

knowing a coin code implies a capability to melt it, but it can only
be melted once.
Scalability happens by creating as wide an array of mint operations as
is needed.

Minting/melting takes fewer read/write operations than delivering an
e-mail by several orders of magnitude, and even if a paid e-mail took
ten free e-mails to implement that would not be a problem.

The problems are political not technical.

So anyway in SMTP terms, toward e-postage drafts, I see senders,
spf-authenticated envelope return addresses (ERAs), so we can work
this all out prior to the DATA phase, using mint/melt to deliver value
in a form trusted by both the ERA and the recipient, to the receiving
MX, along with a concise statement of their payment policy.

There doesn't have to be any imposition or zero-day, just restriction
of access by the receivers of paid e-mail until senders adapt.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg