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

[David Nicol <davidnicol at gmail.com>]

On Mon, Feb 16, 2009 at 3:22 PM, John Levine <johnl at taugh.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.