Most Ethereum projects in need of micropayments have, so far, focused on payment channels. Payment channels allow for the sending of arbitrary number of transactions while only requiring two on-chain transactions:

One transaction to initialize the payment channel.

One transaction to close the channel and settle total amounts transferred.

Between these two we can send as many off-chain transactions as we want. This is a great improvement from regular on-chain transactions, as services such as video streaming and energy markets can be paid continuously for tiny amounts of service.

Because two on-chain transactions are required, we can’t simply send a tenth of a cent to someone we do not already have a channel with, as the transaction fees of channel initialization and settlement would be many times higher than the payment.

What if we could send arbitrarily small amounts to an arbitrary number of recipients, without the need for initialization or settlement transactions?

Ethereum Probabilistic Micropayments can send an arbitrary number of payments to an arbitrary number of recipients, without any per-recipient initialization or settlement transactions.

Sounds too good to be true? It almost is — we always need at least one on-chain transaction to settle payments, but it is possible to effectively receive payments without any on-chain transactions taking place.

In the above claim, note the per-recipient qualification; a subtle but important distinction. Ethereum Probabilistic Micropayments require a single initialization transaction per sender, locking up an amount of tokens that is then used to send tokens to any recipients. And recipients do not need to settle payments per-sender. Below we go through an example to see how this works.

The Orchid Protocol

At Orchid Labs we’re working on removing surveillance and censorship from the Internet through a new decentralized overlay network. In the Orchid Network, bandwidth contributors (called nodes) share their bandwidth and relay traffic for users who access the Internet. Users continuously pay tokens to bandwidth contributors (automated by the user client).

An Orchid node may service thousands of other nodes, and users may use hundreds of nodes to access different websites, the transaction fees of setting up a payment channel between each node (even if using networks of channels such as the Raiden Network) would be prohibitive.

Instead, we use Ethereum Probabilistic Micropayments:

The sender deposits tokens (can be ETH, ERC20 tokens or equivalent) into an Ethereum smart contract (shared by all senders) which maintains, for each sender, payment balance and penalty escrow. The sender locally creates and signs a ticket— a cryptographic data structure that includes payment data, such as recipient and amount. The sender sends the ticket directly to the recipient without posting anything on the Ethereum network. The recipient verifies the ticket. If it’s valid the recipient now has cryptographic proof that they are being paid. Note that even if a ticket is not a “win” the recipient still has absolute proof of being paid, since the randomness used to determine whether a ticket wins or not is derived from both the sender and the recipient in such a way that neither can manipulate the outcome. A valid ticket may be a “win”, in which case it can be claimed by posting an on-chain Ethereum transaction.

This scheme is detailed (and in part formalized) in the Orchid Draft Whitepaper, which discusses and references prior research on probabilistic micropayments and their applicability to blockchains.

While we can’t use this scheme for a single payments — since the recipient has no guarantee of actually being paid — we can use it to prove, cryptographically, to a recipient that the ticket they receive have a certain probability of resulting in a claimable payment.

As we can configure the exact probability of winning, the winning amount, and frequency of tickets over time, we can reduce the variance (balance of trade) to such a degree that it becomes effectively negligible.

In other words, probabilistic payments are more efficient than payment channels whenever the service provided is continuous and granular enough for the probabilistic variance to become negligible.