A Reactionary Rant by The Famous Brett Watson, 31-Aug-2001.
It's commonly believed that the web needs a system for making micropayments — payments so small that they aren't viable via traditional "online" payment schemes such as credit card. I take this need as given for now, without discussing (yet) exactly why we need it, or, more importantly, who would want it for what. With this assumption in mind, I critique Ronald L. Rivest's 1997 paper, Electronic Lottery Tickets as Micropayments [PDF, Postscript]. The critique compares the lottery ticket system to a purely deterministic (but otherwise similar) system, centering around the question of whether the lottery ticket concept is helpful in practice. I do not discuss whether Rivest's mathematics "works as advertised" (I assume it does), but rather if it is useful. I then list the factors I consider to be significant hurdles; the problems I believe any proposed micropayment scheme must overcome, especially the social factors — the desires and goals of the various participants in the scheme.
In describing the lottery ticket scheme, Rivest has cause to refer to an earlier paper by himself and Adi Shamir entitled PayWord and MicroMint: Two simple micropayment schemes [PDF, Postscript]. Some familiarity with "payword" will help you understand both Rivest's paper and this critique. If the brief description of payword provided in the "lottery tickets" paper is insufficient, refer to the relevant parts of this earlier paper for clarification.
Note: Rivest uses the term "digital coin" for what I am calling a "token" here. I adopt this term because it has better symmetry with "lottery ticket", and because "digital" is somewhat redundant in the context of online payments. A token is simply the conceptual monetary unit in a deterministic online payment system.
The primary difference between a lottery ticket and a token as a means of payment is that the token has a fixed (small) value, whereas the lottery ticket has a larger potential value, but a small probability that it will actually pay that value. Thus, the expected value of the lottery ticket can be made the same as that of a token by choosing an appropriate value and probability. In accordance with the law of averages, the more payments are made by lottery ticket, the closer the actual value will come to the expected value (as a percentage of the total). Thus, from a purely mathematical perspective, the difference between a lottery ticket and a token is that the token is deterministic, whereas the lottery ticket is non-deterministic and will have an expected error.
The advantage of the lottery ticket over the token is that only winning tickets need be processed by the bank. Thus, this is a form of non-deterministic aggregation: if the standard lottery ticket has a one in one thousand chance of paying up, each monetary transaction will be a thousand times more than a similarly-valued token system, and there will be around one thousandth the total number of individual transactions. In a situation where a per-transaction fee is charged, the lottery ticket system immediately reduces the transaction fee overhead by a factor of one thousand (in this example), at the expense of introducing an expected error into the actual amount of money changing hands.
In terms of the mathematical operations and protocols that would be utilised by these systems, the lottery ticket system requires a superset of the functionality of the token system; the additional functionality being the means of determining whether any particular ticket is a winner. This functionality does incur some communications and computational overhead — Rivest's example implementation using "payword" chains as lottery tickets results in a symmetric scheme which has twice the computation and communications overhead of standard deterministic payword. Given that payword is a very lightweight system, the additional burden of non-determinism is not very significant: I won't take it into consideration as a disadvantage of the lottery ticket scheme.
One should realise that some other micropayment schemes, such as payword, are themselves aggregated to some extent. A payword chain could easily be one thousand words valued at one cent each, and the words in this chain would be consumed over time until the vendor cashed it in. The chain need not be completely consumed at this time, so the aggregated amount may be less than the full ten dollars, but it's only the process of "cashing in" that counts as a transaction with the bank. If, as Rivest suggests, a payword chain is valid for one month, then there is no benefit to the lottery ticket scheme relative to payword if typical monthly payments by a user exceed the face value of one lottery ticket.
For example, if a user makes daily visits to a "penny per page" website, accruing on average ten cents in charges per day, then the user is likely to attract a monthly bill in the order of three dollars. The benefits of the lottery ticket in this situation, in terms of the number of bank transactions involved, is only better by a factor of about three. This margin could be further reduced by extending the lifetime of the payword chain, at the expense of increasing the credit risk associated with the chain.
It is also possible for an intermediate party to act as the aggregator. A rough outline of this scheme is given in an I, Cringely column entitled Let's Get Small. This is not a technical paper, but the idea is processual rather than mathematical. Put simply, the payments made by any given user to any given site may not be large enough to warrant a transaction, but the sum of all their payments to all sites may be. If each user makes an aggregated payment for all sites to a central agency, and the agency then redistributes the payments to the sites in aggregated form, the total number of transactions is vastly reduced.
To be more precise, the mathematics of the situation is as follows. We hypothesise a number of users (U), and a number of vendors (V). Each user deals with a small subset of V, containing an average of W vendors per user. We expect U to be much larger than V, which is in turn much larger than W (U>>V>>W). Where the users pay the vendors directly, there will be a total of UW transactions per billing cycle. Where the users make aggregated payments via an intermediate party, there will be a total of U+V transactions per billing cycle. This will be an improvement for any situation where W is two or more. The improvement has an upper bound of W, meaning that the total number of transactions is reduced by something approaching (but less than) a factor of W. Note that the number of financial transactions is U+V, but the number of claims processed by the intermediate party is still UW — the intermediary aggregates at the financial transaction level, not the individual claim level.
The aggregation schemes described here can be used in a complementary manner. Indeed, the "intermediate party" system would probably use a payword-like scheme for tracking user payments to each vendor. The vendors would send in their (arbitrarily small) claims to the intermediate party without a "financial transaction" having taken place. The intermediate would then aggregate these, actually billing a user's credit card when a certain threshold was reached. The intermediary would probably pay the vendors by cheque or direct deposit, possibly on a weekly or monthly basis, thus further reducing the number of transactions.
It should be fairly obvious by now that the supposed advantages of lottery tickets over deterministic systems such as payword are pretty nominal, except under special circumstances. Lottery tickets can work without an intermediate, and with very low payment levels, but in the absence of these conditions their advantages fade rapidly. On top of that, there is almost certainly a substantial social impediment that is entirely overlooked by Rivest: the simple fact that people are used to money being deterministic. The average man in the street asked to use a lottery-based system would find it unnatural. It's hard to quantify this objection, but it's very real. A practical micropayment system must appeal to a sufficiently large portion of both users and vendors that it will actually be adopted!
There are many other objections to micropayment systems in general, or rather to the particular practice of money being forcibly extracted from the user in exchange for web page views, which is the usual application suggested for micropayments. Suppose you want to charge some fraction of a cent for each page view on a site: some of the concerns your potential customers may have could be as follows.
Once again, these objections are hard to quantify, but they are very real. In reaction to the "intermediate party" aggregation proposal, Robert X. Cringely received a great deal of negative feedback, much of it echoing these very sentiments. The I, Cringely column which documents this is Paying the Piper. (Note: I am mentioned in the article — I wrote to Cringely in response to the previous article, and he elected to include some of my comments.)
These potential end-user concerns are a very big problem, because a micropayment system must be widely-adopted in order to be useful, and in order to attain wide adoption it needs to be attractive. All the above factors are things that make the system unattractive, and they must be counteracted just to get back to square one. But suppose none of the above points were in fact an issue: what is the selling point of the micropayment system? From the perspective of the end user, it's just a way for other people to take money away from them. This is yet another problem that must be overcome, and generally the only way to do it is to have a whole bunch of vendors with attractive products. Alas, the vendors are unlikely to find the system attractive unless it already has users — a chicken and egg problem.
The final clincher is the fact that users are lazy. Even having a "free registration required" restriction on the content of your site, such as done by The New York Times, can seriously impact the number of people willing to view the site. If the same (or similar) information is available elsewhere, many users will take the path of least resistance. Micropayments for viewing web pages are unattractive enough as a general concept; to expect users to go through the rigmarole of registering for a micropayment service, up to and including handing over their email address and credit card number, is a little too optimistic.
Although lottery-based micropayments have some interesting properties, I do not believe they offer much in the way of answers to the problem of actually getting a micropayment system to be widely adopted. If an intermediate aggregator is not a possibility, and the amount of money to be collected is very low and from a very large number of people, then lotteries do in fact offer a real per-transaction advantage. Making the system financially viable, however, is necessary but far from sufficient.
Lotteries do not significantly address any of the concerns that users would have over the question of payment for online services. Indeed, the only thing they contribute in that particular sense is an additional disincentive: the fact that payments are imprecise by design!
Interesting though they are, lottery tickets aren't the silver bullet we need to make micropayments a reality. It seems likely, in fact, that the silver bullet will have to come from the application domain. If a "must have" application for micropayments arises, just about any of the proposed micropayment systems could step in to fill the resulting vacuum.
Until then, please have your credit card ready for all online purchases, and enjoy your free web pages.
Author: The Famous Brett Watson