Payments as an answer to spam

[Ian Grigg]

bear wrote:

> What happened to them, as I understand it, is that the
> per-ad revenue got driven down to the point where it was
> more expensive to process the payments than the payments
> were actually worth.

So, what you are saying is that people really
didn't appreciate the notion of advertising
on their screens, whether it was being paid
for or not...  I'd guess that the result here
is that the service offering was not accepted
by the public?

People need to read their mail without being
bombarded with spam;  that seems to be a
counter-proposal to optionally asking them
to be paid to see spam.

> Whenever anyone writes a check, it costs at least a nickel
> for the merchant to clear it.  Clearly you don't ordinarily
> use checks for such tiny purchases because (a), almost
> nothing can be sold for less than a nickel, and (b), it
> would be more time and bother for you to write the check
> than you probably consider a nickel's worth of trouble.

Right.  Hence one definition of micropayments,
being those payments that can efficiently be made
below the cost of the old infrastructure.

> If you posit a system for making very small payments,
> you've got basically three problems: (1), consumers
> will never make micropayments because a decision about
> whether to spend money on something involves stress -
> in this case stress that's out of all proportion to
> the payment itself - and will be resented.

Yep, this is a well known marketing phenomena.
However, it doesn't apply here, AFAICS, as the
user's mail client is expected to make all the
choices for the user without asking the user.

( Then, the user might have to top up the pot
for the client, occasionally, bringing up the
question of whether it is worthwhile...  and,
then, putting pressure on the ISP to deliver
an all-in-one package.  So that might be the
point where I contradict myself ;-)


> (2), Each
> and every consumer system will need configuration and
> a relationship with a "bank" somewhere to cash such
> tokens made to them - and that requires the attention of
> the consumer again to maintain a business relationship
> which he won't bother to do unless there's a significant
> (more than a few dollars a month) revenue stream.

See my other mail, I'd say that's an unmerited
assumption!

> (3),
> the cost of processing payments must be kept small
> relative to the payments themselves.

Yep.  Which is why I think the only way a
payments solution would stand a chance of
succeeding is if it is closely integrated
w.r.t. the mail system.



> I've seen half-a-dozen papers in the last year touting
> the ability to keep per-transaction costs on micropayments
> down to less than 20% of gross.  All of them did so at the
> expense of precision and accountability.  These "solutions"
> are non-starters because insofar as they operate without
> human attention at any part of the system, if they are not
> precise and accountable then they are subject to fraud.
> And insofar as they require human attention, people will
> ignore them in droves because the payments are too small
> to be worth the hassle.

The way I've always addressed this dilemma
is to do payments, not micropayments.  That
is, payments that can be used for very large
numbers and small numbers too.  Then, we've
worked to make them as efficient as possible,
stretching the payment down to as low a floor
of efficiency as possible.

In a business sense, it's often been observed
that it takes a lot of micropayments to make
a buck of revenue.  So, a pure micropayment
system is dead in the water.

Then you have a choice:  a micropayments
system that is also capable of doing some
larger payments, or a "macro"payments system
that can do some smaller ones.  The advantage
of the latter approach is that presumably
one *can* make revenues on large payments,
and as time goes on, Moores law and better
code gives you a lower floor.

> No paper, so far as I know, addresses the basic consumer
> psychology issue, that payments of less than ~$1.00 or
> revenue streams of less than ~$10.00/month are seen as
> too annoying to bother with, especially if they come with
> business attachments, contracts, advertising, emails
> from the bank about additional services, monthly statements
> that incur storage overhead and mental bandwidth, etc...
>
> Every bit of that stuff is a teeny bit of stress.  And
> humans will forego revenue streams that come with more
> stress than they are worth.

I'd agree with all that.

My perhaps contrarian view on the
spam thing is that a payments solution
dominates the hashcash solution for the
basic economic reason that it better uses
resources.

But, I have trouble seeing how a payments
system would be a solution, too, there are
too many barriers (as many people point out).

This puts me in the unenviable position of
being the naysayer;  I can poke holes in
other's proposals, but cannot propose one
of my own.  Oh well.  Let's concentrate on
the issues, rather than the egos, it may
be that out of this discussion comes the
silver bullet...

(Hashcash is a fine invention, and does
credit to its author.  I find it much
more elegant than pretty much all of the
micropayment proposals, which all seem
to lack a sense of relationship to the
dirty world of the net.)

-- 
iang

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com