If blockchain is to be truly commercial, it is inevitable that payments and settlements will take place on the chain. It is no surprise that in order to do so, we would need to reduce a blockchain’s operational costs as much as possible.

Probabilistic micropayment is one of the solutions to this problem.

The original concept of probabilistic payment predates blockchain technology. In 1996, David Wheeler first published a paper explaining the concept of probabilistic payment and how to apply it to electronic protocols that use random number promises.

Then in 1997, Ronald Rivest published a paper on how to apply probabilistic payments to electronic micropayments.

In 2015, Pass and Shelat proposed in their paper “Micropayments for Decentralized Currencies” a method to apply probabilistic micropayments to tokens such as BTC, and pointed out that previous solutions all relied on trusted third parties.

In recent years, research on probability payments has gradually extended to zero-knowledge proofs, and is used to help build decentralized blockchain protocols and anonymous micropayments.

To better understand probabilistic micropayments, we need to know what micropayments are and why we need them.

1. Micropayments

The act of paying is all too familiar in the world, no matter if it’s exchanging physical currency or purchasing with Apple Pay, we know it well. But in the blockchain world, a simple payment becomes slightly more complicated. With a blockchain, the third-party is now removed from the transaction. And without that independent third party, the two parties involved in a trade have little reason to trust each other; with either side potentially believing the other will not act in a fair and just manner.

Here’s how a transaction can look on the blockchain:

Alice and Bob are trading on Ethereum, where Alice uses ETH to purchase bandwidth services provided by Bob. In this scenario, if Alice pays Bob first, she will worry Bob won’t provide her with bandwidth services. At the same time, Bob worries that if he provides bandwidth first, Alice will refuse to pay after using it.

As a result, both sides are unable to carry out the transaction because of trust issues.

Alice and Bob’s dilemma — neither side trusts each other so no deal is made

Let’s say this was happening in the real world and not on the blockchain. How would it work?

By relying on third parties.

Alice first entrusts the money to a trusted third party. When Bob sees that Alice has entrusted the money, he will provide his service to Alice. After the service is completed, the trusted third party transfers the escrow funds to Bob’s account. If during this process, either party deceives the other through cheating, fraud, or other means, the harmed party can seek a third party for arbitration.

Back in the blockchain world, there is no trusted third party that can arbitrate a dispute. So the next best thing is to reduce the risk by reducing the size of the trade; breaking up a large transaction into a series of smaller ones.

For example, Alice downloads 100GB of data from Bob and in return pays Bob a total of 1 ETH. To prevent Bob from taking the money without rendering services, Alice can split the transaction into 100 pieces. In this case, for every 0.01 ETH received by Bob, he will send 1GB of data to Alice. After Alice confirms that the received data is correct, she will transfer another 0.01 ETH, in which Bob will send another 1GB. This will repeat until 100GB has been transferred to complete the transaction.

If Bob receives the nth 0.01 ETH, he no longer gives Alice data, then Alice will only lose the nth amount of 0.01 ETH at most. The smaller the units shared in the transaction, the less one side has to lose.

The act of breaking a large payment into a series of smaller payments in order to reduce risk is, you guessed it, micropayments.

Micropayments solve the problem of trading between two untrusted parties. However, it does not completely solve the risk of trading, it merely reduces it.

2. Payment Channel

Although micropayments allow two people who do not trust each other to trade, there is a cost involved when implementing this solution on the chain.

We all know that an on-chain transfer is a transaction sent by the payer. The transaction is considered successful after the transaction is packaged and is confirmed by the block-producing node. However, sending transactions comes with a cost:

  1. There are fees for sending transactions, such as burning gas on Ethereum
  2. It takes time to confirm the transaction, ranging from minutes to hours

Considering the cost of money and time, micropayments on the chain become infeasible.

For example, each time Alice pays 0.01 ETH to Bob, he sends a transfer transaction. The gas fee burned by the transaction may require 0.005 ETH, and the two parties must wait before a second transaction can be performed.

Obviously, the handling fee here is too high and the efficiency too low.

Therefore, it is necessary to reduce the number of transactions on the chain and to shorten the waiting time for a transaction.

Payment channels solve both of these problems. Payment channels are also called state channels (in the strictest sense, payment channels are actually a subset of state channels. The essence of a payment channel is a smart contract from which funds can be held, but where withdrawals from the contract must meet specific conditions.

According to the payment direction, payment channels can be divided into one-way payment channels and two-way payment channels.

Taking a one-way payment channel as an example, Alice can escrow money in the payment channel in advance, and specify in the contract that the receiver can only be Bob. Then for each payment, Alice gives Bob a credit under the chain. The credit contains the address of the channel, the amount paid, the Nonce value, and Alice’s signature. When Bob receives the voucher, he can withdraw money from the payment channel contract. However, Bob does not need to withdraw the money as soon as he receives the voucher; he can withdraw the entire transaction with the last voucher.

The reason for this is that the voucher is an incremental payment credential e.g. the amount of Alice’s first payment credit to Bob is 0.01 ETH, the second payment credit is 0.02 ETH, and so on. Therefore, as long as Bob receives the new, larger amount of credits after each transaction, the old smaller amount then becomes useless. Bob only needs to keep the latest and valid voucher. After the transaction is over, Bob can use this voucher to withdraw the money.

Using a payment channel will reduce the number of on-chain transaction

Based on the payment channel, and in the case that both parties are being honest, generally, only two transactions on-the-chain are needed to complete the transaction between the two parties. This greatly improves transaction efficiency and reduces transaction costs.

3. Probabilistic Micropayments

Although a one-to-one payment method mentioned above can be implemented, a more realistic scenario will require a method that offers a one-to-many payment.

For example, a user requests to download3 the same resource from several different servers in order to complete the download more quickly. The user would then need to establish a payment channel with multiple download service providers. Each download service provider would submit a payment on the chain after the download is completed. This puts a lot of pressure on the chain.

And this is where probabilistic micropayments do their magic.

Probabilistic micropayments are the addition of probability to micropayments. Simply put, the recipient will receive the payment with a certain probability, and the mathematical expectation of receiving that payment is the same as that of receiving the payment.

For example:

Alice is dealing with two service providers at the same time. If the standard one-way payment channel is followed, Alice will create two smart contracts on the chain, one for each provider, and then will put an advance payment into two payment channels. As before, a credit of ETH 0.01 is then sent to each service provider, and withdrawal is required for each service provider.

If Alice used a probabilistic micropayment scheme, then she only needs to make a one-time advance payment into a contract, and then pay 1 ETH to the service provider with a probability of 1%. If the total number of services used by Alice does not change, then only one service provider, in probability, will receive a credit of 1 ETH.

Probabilistic micropayments can further reduce the number of on-chain transactions

Of course, since it is probabilistic, there will be a special case where Alice wins n prizes while using the service, so Alice actually pays n ETH. Here n can be greater than 1 (paying more than 1 ETH) or it can be equal to 0 (not paying, resulting in a free service). But in the long run in the example above, Alice’s average payment will approach the mathematical expectation of 1 ETH * 1% = 0.01 ETH.

In other words, as long as Alice uses probabilistic payments for a long time, she will not lose or make a profit.

4. Principle of Probabilistic Micropayments

What is the principle behind probability payments?

The answer is randomness.

Before Alice makes a probabilistic payment to Bob, Bob will randomly generate a secret number. Then Bob will send the abstract of the secret, namely the Hash(secret), to Alice.

Each value sent as follows:

  • ChannelAddress is the address of the payment channel
  • BobAddress is the address of Bob’s wallet
  • Nonce refers to the value of Nonce in the channel; used for anti-replay
  • FaceValue is the denomination value, such as 1 ETH
  • WinProp is the winning ratio multiplied by 2 ^ 256, For example, WinProp = 0.01 * (2 ^ 256) which corresponds to a 1% chance of winning

After Bob receives the vouchers, he can judge whether he has won the prize or not by the following methods:

Bob calculates h1 =Hash(ChannelAddress, Hash(secret), BobAddress, Nonce, FaceValue, WinProp, SigAlice), h2 =Hash(h1, secret). If h2 < WinProp wins, Bob can use this voucher to withdraw money from the channel.

Since Alice does not know Bob’s secret number at the moment she signs the voucher, Alice cannot construct a signature so that Bob cannot win. At the same time, Bob did not have Alice’s signature on the voucher at the moment when he randomly generated his secret number, so he couldn’t construct a secret that was guaranteed to win.

This shows that neither side can cheat. The only factor that makes a payment successful is probability.

5. To Sum It Up

A probabilistic micropayment is an interesting payment idea. It is equivalent to aggregating multiple micropayments through probability. This aggregation also makes for fewer transactions on-the-chain.

Payments in traditional payment schemes are deterministic. For each payment, the payer will pay the withdrawal voucher, which includes a fee, to the payee. With this withdrawal voucher, the payee must mention the payment in the chain channel contract. In short, if the payer pays, the payee will receive the money.

In a probabilistic micropayment scheme, the payer does not pay the recipient a withdrawal voucher for each payment operation. Instead, an uncertain withdrawal voucher is paid. This new type of voucher is similar to a “lottery ticket”. After receiving this type of lottery ticket, the payee can draw the prize. If the payee wins, then the ticket becomes a definite withdrawal voucher, which can be mentioned in the contract of the channel on the chain. If the payee doesn’t win, the ticket becomes worthless. The winning factor depends entirely on randomness. Neither the payer or the payee unilaterally controls it.

The uncertainty of probabilistic micropayment has its advantages and disadvantages:

1. Sometimes, it will cause the payer to pay more than the actual payable amount, which is equivalent to an overpayment. Other times it will cause the service party to lose meaning they won’t be paid.

2. Although probabilistic micropayment has its advantages in a one-to-many payment scenario, this type of payment method also essentially increases the risk of double-spending. Therefore, the payer must mortgage enough funds in the contract to reduce this risk and make the service party willing to trade with it.

As a result, the use of probabilistic micropayments needs to be determined according to real-life scenarios where it will be used. What we have learned from probabilistic micropayments is not only a technical solution but also its idea. It teaches us that certainty and efficiency can be transformed into each other within a certain range.