Ethereum Probabilistic Micropayments

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:

1. 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.
2. The sender locally creates and signs a ticket— a cryptographic data structure that includes payment data, such as recipient and amount.
3. The sender sends the ticket directly to the recipient without posting anything on the Ethereum network.
4. 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.
5. 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.

Example: Video Streaming

Let’s imagine a decentralized YouTube where anyone can host video streaming to any viewer.

Payment Channel Scenario:

1. You’re a video streamer host, charging $1 per hour of video streamed.
2. A new user connects to your service and watches exactly 10 seconds of cute kittens.
3. A transaction without data currently costs around $0.006, if one is OK waiting a few blocks for confirmation. However, as we need to setup the channel before streaming video (to avoid freeloaders), we probably want quicker confirmation, which would cost $0.026. Setting up a payment channel would cost a bit more, as it requires some smart contract execution. A rough estimate would be twice as much — $0.052.
4. The overhead of a payment channel here is several times what you, as a host, want to charge the user. If the user ends up watching more, the overhead may be reasonable, but there is some friction here for new or sporadic users.

Probabilistic Payment Scenario:

1. You’re the video streaming host, charging $1 per hour of video streamed.
2. A new user connects to your service and watches exactly 10 seconds of cute kittens.
3. Every 4s, the user sends you a off-chain ticket with 1/2500 probability of winning. The winning amount is set to $2.78.
4. If you do not receive a payment ticket every 4s (within some margin to account for network latency), you simply disconnect the viewer.
5. If the viewer does not receive any video feed, they immediately cease sending payment tickets.
6. When you receive a winning ticket, you claim it with an on-chain transaction, which transfers the wining value to you from the tokens locked up by the sender.

Even if a ticket is not winning, you still have cryptographic proof that you’re being paid, since neither the sender nor the recipient can manipulate the value that determines if a ticket wins. With the proof, you’re happy to continue streaming video to the viewer. As thousands of (new) viewers connect to you, there is no overhead per viewer — the only overhead is when you claim your winning tickets.

For a given “average total payment”, the odds of winning (and frequency of tickets) determine the number of on-chain transactions required. Thus, the higher the winning amount, the less transaction fees paid over time by the recipient. The lower the winning amount, the less tokens have to be locked up by the sender, lowering their liquidity cost.

For video streaming, a reasonable winning amount might be $2.78. For electricity or energy markets maybe it’s $27.

Preventing Double Spending

A crucial part of probabilistic payments is to ensure double spending is impossible, or, failing that, unprofitable for the sender. The “penalty escrow” mentioned earlier makes double spends in our scheme unprofitable for the sender. The way this works is that the sender has to lock up (commit to) a certain multiple of the ticket winning amount before they can construct tickets. The recipient verifies that the sender has not only enough funds to cover a winning ticket, but that their penalty escrow has enough balance.

In the event of a double spend, the on-chain claim of a winning ticket after the sender’s balance is no longer sufficient to cover the ticket will cause a slash of the sender’s penalty escrow account. This effectively burns a small deposit the sender was required to post, creating a economic disincentive for a sender to double spend. The size of the penalty escrow should be set high enough to deter double spends but low enough that it does not cause too much inconvenience for the sender.

Conclusion

Ethereum Probabilistic Micropayments have several advantages over payment channels for systems where a continuous, granular service is provided to users. The reduction in transaction fees allows for not only efficient micropayments, but also for practical nano payments.

Video streaming, electricity/energy markets and bandwidth sharing are good examples of applicable systems. Instead of incurring setup costs per each sender/recipient pair, or using complicated payment channel networks, we only require one on-chain transaction per recipient. Service providers are able to immediately begin servicing users without risking freeloaders. And users can quickly disconnect if they cease receiving the service.

This allows services to completely avoid the cost of freeloaders as well as immediately block denial of service attacks as we can require even the very first request to have an attached micro payment.

PS. David Salamon independently arrived at probabilistic micropayments during our research before we realized the concept is very similar to PoW mining pool rewards and actually dates back to 1996 in the literature (see our whitepaper for references).