Easy Money

This is yet another scheme to move towards DSR. Dean Tribble drastically improved this with a simple suggestion.

Assume a service B that is an IP host. It keeps accounts for many clients with most of whom it has a modest financial arrangement, and with a few of whom it has more than a modest arrangement. With each arrangement there is an account that is never negative.

Suppose that a web page, produced by server S, solicits a payment for some small service. It displays a simple payment request such as “pay 14377289:156 $0.031”. In this request the “14377289” is S’s account. It identifies S and the serving computer to B. The “$0.031” is the amount of the proposed payment.

To pay, the user copies the request from the web page and pastes it into a window for an application called BA (local agent for B). The user presumably understands, since he can see the text, that he is agreeing to pay $0.031 to this page owner. BA sends a payment order to B, and B tells S.

More Detail

B shares a different secret with each of its clients, perhaps generated with Diffie-Hellman logic. A payment order is a UDP containing a Message Authentication Code based on the shared secret. The payment order from the user to B comprises:

An account number by which B knows the user
Payment amount + fee, ($0.031 in example)
Payee ID, (14377289 in example)
Context ID, which identifies the context awaiting payment, to the server (156 in example)
Serial number of payment order for this account, distinguishing payment orders between this payer account and B.
MAC (Message Authentication Code)

The above fee is between the user and B. Contingent on funds in the user’s account, this causes B to launch a payment notification UDP to S. This is authenticated as above and includes:

Context ID from payment order (156)
payment amount - fee ($0.030)
Serial number of payment order for this account, a counter shared between B and S.
MAC (Message Authentication Code)

This fee is between B and the server. C’s account is decremented and S’s account is incremented. B takes its cut and is $.002 richer. Some may want privacy and others will want non-repudiation. This version provides neither. I argue here that this protocol requires neither for its own purposes. I am looking for the minimal solution in order identify the fundamental issues. Things to omit initially:

Privacy
Non-repudiation
Protocol for payment acknowledgment by server to payer

Error Control

Different serial numbers apply to the two link directions. The serial numbers detect lost or duplicate UDPs. Loss detection is not prompt however. B will arrange, for a price, prompt positive acknowledgments which promptly detect lost UDPs. The authentication code provides high quality error detection. Positive acknowledgments are cumulative and are made from either end upon:

Idle period (say 60 sec) following an unacknowledged message
A large accumulation of payments, say $.50
Request for ACK.

The sender of a packet keeps the packet until is has been acknowledged. It can be retransmitted without rehashing.

The acknowledgment includes the serial number of the most recent payment processed by B and the current balance. I think that it may be logically necessary to unify these two functions.

An informal and useful convention is for B, when it receives a duplicate payment order from a payer, to resend the corresponding payment notification to the payee. The payer, fearing packet loss, need not reason about which packet was lost.

For purposes of adjudication one end can periodically or on demand, send a signed stream hash which, if either party has really bothered to store the stream, can be used to replay the transactions between two nodes and thus find honest or malicious bugs. There is a poker game here for one side does not know whether the other is storing the stream. I presume that usually neither side computes the stream hash.

Web Server

The web server has a slightly more complex problem. We discuss these cases:

Charge for the content of an infrequent HTML document.
Charge for computing f(x) where x is supplied by payer.
Running a tab.

The first case seems at first to require that the server match the payment with serving the goods to the correct payer. This is tricky in http/1.0 which affords no continuity between server requests by the client. There is no context with which to associate a payment request and payment. Consider the following however. The server publishes the price sheet with embedded cleartext “pay me” requests. Each such request identifies the priced URL. When such a payment arrives, the server makes the priced page free to all for about 10 minutes. This is subject to collusion among clients but consider the game further. One person pays and several colleagues each get a copy. On the other hand in this scenario those colleagues could more easily have bought the page once and copied it among themselves. If I pay the New York Times for an article that appeared several years ago it is unlikely that anyone else will seek the same article at the same time. If I can collude to cheat the NYT’s payment system, I can even more easily cheat by unwarranted copying of the article. The service of the NYT is to store, index and retrieve the article. It has done that and been paid. If some past article becomes popular among an unassociated group, then there will presumably be multiple payments. In this case the context ID is a hash of the document to be delivered. See case 3 for popular URLs.

In case 2 the service is a computation, which may accesses a data base. First a simple example. Consider the “Distiller” service of converting a PostScript file (.ps) to a Portable Document Format file (.pdf). You could go to the service page where they would describe the pricing and where you could enter an URL that located the .ps file. If you provided the .ps URL then shortly it would respond with a new URL for the .pdf form and a price in the form of a “pay me” string. Very shortly after submitting that string to your local agent the new URL would be available to all. It would be valuable and known presumably only to you.

In scheme three we assume that the user anticipates incurring several charges and trusts the node for perhaps a few dollars. He sets up a IP address tab at the node. This requires no special code in the user’s local agent or B. The web server keep a running account associated with the user’s IP address. The server presumably requires that those funds cover service as provided. After long inactivity, perhaps an hour, the node could refund the balance to the user. If the user is disconnected, B could queue the refund notification for delivery upon the next message from the user’s local agent.

The above refund raises a privacy question. Should payment notifications from B identify the payer, beyond including the Context ID? So far only the refund scenario needs it. I would suggest that a checkbox in the user’s local agent window instruct B whether to include payer account in the payment notification.