System Usage

There's a saying in the world of computer programming: "There is no problem which cannot be solved through the addition of another level of indirection." Digital vouchers represent their backing asset, and as such constitute another level of indirection which allows an abstraction of value to circulate, rather than the value itself. This turns out to solve a number of thorny problems with online payment systems generally.

Inexpensive Secure P2P Digital Bearer Payments

Each of these words is significant:

• These payments are digital; a voucher is just a bit of encrypted XML. Therefore they can go anywhere a message can go. The domain is the whole internet.
• The payments are P2P, person-to-person or "peer-to-peer" in network parlance. There are no accounts, merely electronic wallets containing digital objects signed and validated by a publisher/mint.
• Payments are secure: encryption is used everywhere, and all data representing value or transaction details is always stored encrypted and digitally signed so it cannot be tampered with.
• Payments are in bearer form, meaning cash-like: anonymous, irrevocable, and untraceable. From Bob's wallet to Alice's purse, from Alice to Steve's store, from Steve to his employee Gwen, just like a $20 bill.
• Payments are extremely inexpensive. In the demonstration system, making a payment costs 13 tokens, with the value of a token set at 0.0005 grams of fine gold (approximately US $0.023 per token). Thus sending a payment costs less than thirty cents. Compare sending a Western Union or paying with a credit/debit card. Receiving and validating a payment costs 6 tokens, or about fourteen cents.

Payments Linked to Their Context

A payment of any kind always has a context. If Alice is paying Bob, there will be some reason she's doing it. They have communicated, and agreed that one will provide something to the other in exchange for payment. What then could be more natural than to embed a payment mechanism inside an instant messaging service? Not only that, but a payment is itself just another kind of message, and may therefore contain contextual communications, whether it's "Order number 12345" or simply "thanks!"

Payment Steps

Let's look at how a payment gets made. First, somebody needs to have a voucher to bootstrap the system. Vouchers are minted based on a quantity of the backing asset lodged with the Issuer/custodian, and the total value of all vouchers circulating cannot exceed the amount in custody.

Suppose that the backing asset were gold, the ultimate international money. Alice has some gold which she deposits ("bails in") with the Issuer, or perhaps purchases from the Issuer using some other legacy payment mechanism. She tells the Issuer her voucher safe number (VS#) which is, say: alice123@voucher-safe.org.

The Issuer mints a voucher equaling the metal weight Alice has bailed in, and assigns the voucher an unique serial number. The voucher value and serial number are communicated to the Voucher Publisher (VP), which generates a digital (XML) representation of the voucher and signs it with its private key. The voucher is encrypted with the public key of Alice's VS, and placed on the DHT at the hash of her VS#. The VP records the voucher's serial number, indexed by a hash of Alice's VS# and the amount of the voucher.

Alice logs into her safe, and pings the DHT to see if she has any activity. The record stored there by the VP is retrieved, and her client decrypts it using her private key. The message contains a voucher, which is validly signed by the VP. Alice must now validate this incoming payment with the VP. Her client does this by constructing a message to the VP encrypted with the VP's public key, and sending it to the VP via the OFS she's logged into. (If Alice's safe is empty when she does this, then no tokens are required, i.e. there's no charge to pick up your first voucher payment.)

Because Alice's client knows the correct voucher serial number, and can reconstruct the hash of the payer, payee, and amount, and because her pickup request is signed with her private key, the VP knows that it really is Alice picking up the payment. Therefore, it asks the Issuer to retire the voucher from circulation and issue a new one of equal amount, with a fresh serial number, which the VP then signs and places on the SDS in the folder for Alice's VS. At this point Alice has a voucher available in her safe, equal to the amount of gold she bailed in.

Next Alice purchases some tokens, because she'll need those to make a payment to Bob. The amount is deducted from her voucher, and she receives the tokens plus a change voucher (bearing a new serial number, of course). The total value circulating has not changed, since the VP received a voucher equal to the value of the tokens it created for Alice.

Alice will need to know Bob's VS#. She can obtain this by chatting with him directly, from his website, over the phone, or by any other means. Bob does not need to be logged into his own safe in order to receive a voucher payment.

So Alice makes a payment of the agreed amount to Bob's VS#. If she needs to pay him a specific amount of some national currency, her client's payment form includes a handy calculator for figuring out the right weight in gold. She can also include any identifying information Bob might need to figure out who is paying him or what it was for. In addition, she is able to specify the length of time Bob will have to pick up his payment: 1-7 days, with a week being the default.

Her payment message, encrypted so that only the VP can read it, is forwarded by the OFS to the VP, which performs the operation as requested. It will ask the Issuer to retire the voucher(s) Alice supplied as payment, and get two new vouchers to replace it: one for Bob, and one for Alice's change. The first goes on the DHT in a payment notification stored at Bob's hash and encrypted with his safe's public key. The second goes on the DHT in a confirmation record for Alice.

When Alice picks up her confirmation, her client decrypts her change voucher and inserts a "pending payment" record into her safe's folder on the SDS. If Bob never picks up his payment within the time Alice specified, Alice will be able to use the information in this record to recover the value which she spent to Bob.

At this point one of two things happens:

1. Bob logs into his VS and picks up his payment. He validates it, just as Alice did the voucher from her bailment. His client generates a receipt signed with his private key, and places it on the DHT for Alice to pick up.
2. Bob never picks up his payment.

In the first case, Alice gets a signed receipt off the DHT echoing the payment details. This is her proof of payment, just as if she had purchased something from Bob with cash and gotten a receipt from him. Processing the receipt deletes her corresponding pending payment record. Alice can store Bob's receipt permanently in her safe if she wishes, or discard it, or store it and purge it later.

In the second case, anytime after the payment has expired, Alice uses her pending payment record to recover the value which she spent to Bob. She'll get back a voucher of equal weight. (Note there is no token cost for recovering a dropped payment.)

Splits and Merges

Alice or Bob may combine their vouchers into one larger voucher, or they may split a voucher into smaller parts. This operation returns them the exact same total value, but does cost the same number of tokens as a payment. In addition, any voucher may be "revalidated" at any time, which means validating it with the VP. Validation always destroys the voucher, causing it to be replaced with another voucher with a different serial number but the same value.

So why do it? First, vouchers expire after six months. This is meant to be a transactional system, not a savings account. Secondly, vouchers track their "generation," i.e. the number of times the same value has been re-issued in another voucher since original minting (in-bail). The VP accomplishes this by the simple expedient of taking the minimum generation of all the vouchers which are input, adding one (1) to it, and using that as the generation of all output vouchers for that transaction. For example, if Bob pays Alice using two vouchers, one of generation 3 and the other of generation 5, both Alice's payment voucher and Bob's change voucher will be of generation 4.

Closing the Loop

Bob probably can't pay his bills with vouchers he got from Alice or his other customers, so at some point he may wish to "unbail" assets from the Issuer. In this case he makes a payment to a special VS#, including his unbailment details. The Issuer withdraws the voucher value from circulation, and Bob will be paid in the backing asset, or allowed to sell it for some other kind of payment, according to the terms stipulated by the Issuer or its agent.

Summary

• In-bail
• Pickup initial voucher
• Voucher's value circulates internally n times among safes
• Optional: out-bail

Website Payments

Using a package called SparkWeb, it's possible for a web browser to act as a Jabber client. In a similar vein, we provide a shopping cart tool (written in PHP) so that a vendor site can construct an order for a visitor, of any complexity, just as it normally would. If the user opts to pay with a voucher, the site asks the visitor to enter their JID (Jabber identifier), and sends the order information to their client as a message, encrypted using a randomly selected hash. The hash is displayed to the user in their browser as an image, for security. The voucher client captures this message, and once the user enters the decryption hash from the website, decrypts it and uses it to pre-fill the payment form with the values sent from the website, such as order or shipping details.

This makes it possible for P2P voucher payments to be used as an additional payment vehicle on websites.

Note: A newer and cleaner way of accepting website payments is now available through OnionPay. Please see the OnionPay website for details.

---