Probabilistic Payment

What Is a Probabilistic Payment?

A probabilistic payment is a transfer where the sender does not pay the exact intended amount directly. Instead, the sender issues a "lottery ticket": a larger payment that only pays out with a small probability. Over many transactions, the total amount received converges on the intended value through the law of large numbers.

Consider a scenario where Alice wants to pay Bob 1 millisatoshi per data packet. That amount is far below Bitcoin's smallest on-chain unit (1 satoshi) and well under the dust limit (546 sats for P2PKH, 294 sats for P2WPKH). Direct settlement is impossible. With a probabilistic payment, Alice instead sends Bob a 1-sat payment that has a 0.001 (0.1%) chance of being valid. For every 1,000 packets, Bob statistically receives 1 sat: exactly the intended rate.

The idea was first proposed by cryptographer Ronald Rivest in 1997 as "electronic lottery tickets." In his scheme, the bank only processes winning tickets, dramatically reducing the cost of handling millions of sub-cent transactions. The concept has since been adapted for decentralized systems like Bitcoin, where on-chain transaction fees make small direct payments economically irrational.

How It Works

The core mechanism requires two ingredients: a way to generate verifiable randomness that neither party can manipulate, and a payment structure that enforces the outcome. In Bitcoin, this is typically achieved through cryptographic commit-reveal protocols.

Basic Lottery Mechanism

1. Alice and Bob agree on a face value (V) and a win probability (p). The expected payment per ticket is V × p. For a 1-sat expected payment: V = 10,000 sats and p = 0.01% (1 in 10,000).
2. Alice constructs a "ticket" that pays Bob the face value V, but only if a cryptographic condition is met. This condition depends on secrets from both parties, so neither can predict or manipulate the outcome.
3. Both parties reveal their secrets. A deterministic function (typically a hash) combines them to produce a pseudo-random result.
4. If the result falls below the probability threshold, Bob wins and claims V. Otherwise, the ticket expires worthless and Alice keeps her funds.

Commit-Reveal Randomness

Generating fair randomness on Bitcoin is challenging because Bitcoin Script has no native randomness opcode. A 2025 proposal by Oleksandr Kurbatov describes emulating an OP_RAND operation using a two-party interactive protocol built on elliptic curve commitments:

1. The challenger generates random values and commits to one selection by publishing a hash of the corresponding elliptic curve point.
2. The accepter verifies the commitment proof, selects a candidate, and publishes their own commitment along with a proof of construction.
3. The challenger reveals their original selection. The accepter wins if their guess matches.

Because each party commits before seeing the other's choice, neither can cheat. The scheme requires no protocol changes or new opcodes, relying only on existing signature verification and hash operations available in Bitcoin today.

Expected Value Calculation

The mathematics behind probabilistic payments is straightforward:

Expected value per ticket = face_value × win_probability

Example configurations:
  face_value = 10,000 sats, probability = 0.01%  → EV = 1 sat
  face_value = 1,000 sats,  probability = 0.1%   → EV = 1 sat
  face_value = 100 sats,    probability = 1%      → EV = 1 sat

Over N tickets:
  total_received ≈ N × face_value × win_probability
  variance decreases as N increases (law of large numbers)

Higher face values with lower probabilities reduce the number of on-chain transactions but increase variance for the recipient. Lower face values settle more frequently but save less on fees. The optimal configuration depends on the payment frequency and the recipient's tolerance for income volatility.

Use Cases

Streaming Micropayments

Payment streaming applications, such as pay-per-second media consumption or real-time data feeds, generate enormous volumes of sub-satoshi payments. Direct settlement of each increment is impossible: even on the Lightning Network, routing a payment requires multiple signatures and network round trips. Probabilistic payments let a stream of thousands of micro-increments collapse into occasional larger settlements, preserving the correct aggregate value without per-packet overhead.

Pay-per-API-Call

API providers serving millions of requests per day face a billing problem: individual calls may be worth fractions of a cent. Traditional billing aggregates usage into monthly invoices, introducing credit risk and reconciliation overhead. Probabilistic payments enable real-time settlement where each API call carries a lottery ticket. The provider receives statistically fair compensation without maintaining account balances or billing infrastructure.

IoT Machine-to-Machine Payments

Connected devices that exchange small units of value (sensor readings, bandwidth, compute cycles) need a payment mechanism with near-zero marginal cost. On-chain Bitcoin transactions are too expensive, and even Lightning payments carry routing overhead that exceeds the value of individual data points. Probabilistic payments allow machines to transact at effectively any granularity, with settlement costs amortized across thousands of interactions.

Replacing Trimmed HTLCs

In Lightning Network channels, payments below the channel's economic threshold for on-chain resolution are called "trimmed HTLCs." When a channel force-closes, the value of trimmed HTLCs goes to transaction fees rather than to either party, creating a loss. A malicious counterparty can exploit this by adding trimmed HTLCs they never intend to resolve, forcing their partner to subsidize miner fees.

Probabilistic payments offer an alternative: instead of trimming a 1-sat HTLC, the channel creates a 10,000-sat output with a 1-in-10,000 chance of paying out. If the channel stays open (the common case), Alice and Bob simply sign a mutual update transferring 1 sat. The probabilistic output only matters during force-close, where it replaces the lost value of trimmed HTLCs with a fair lottery. This approach was discussed in the Bitcoin development community in early 2025 alongside proposals for emulating on-chain randomness.

Comparison with Other Micropayment Approaches

Probabilistic payments and Lightning solve overlapping problems from different angles. Lightning reduces per-payment cost by batching settlements into channel opens and closes. Probabilistic payments reduce per-payment cost by settling only a statistical fraction of transactions. The two can be combined: a Lightning channel could use probabilistic HTLCs for sub-satoshi forwarding, avoiding the trimmed HTLC problem entirely. For more on how micropayment economics compare across rails, see the research on micro-transaction cost comparison and Bitcoin micropayment use cases.

Why It Matters

Probabilistic payments unlock an economic layer that Bitcoin cannot reach today. The dust limit exists because processing and storing tiny outputs costs more than they are worth. The minimum relay fee creates a floor below which transactions are not propagated. These safeguards protect the network but also prevent entire categories of commerce: sub-cent content purchases, real-time metered services, and machine-to-machine value exchange.

By converting many small payments into occasional large ones, probabilistic payments preserve Bitcoin's economic protections while enabling sub-satoshi value transfer. This is particularly relevant for Layer 2 protocols like Spark, where off-chain transaction costs are already low but the granularity of payments still depends on the smallest representable unit. Probabilistic techniques could extend these systems further into the domain of true micropayments.

Risks and Considerations

Variance Risk

Probabilistic payments are fair on average, but any individual ticket is all-or-nothing. A merchant serving 100 customers per day with a 0.01% win probability might go weeks without a payout, then receive a large lump sum. This variance is manageable at scale (millions of tickets per day) but can be problematic for low-volume recipients. The choice of face value and probability must balance fee savings against income predictability.

Gaming and Manipulation

If the randomness source is not cryptographically fair, one party can selectively retry tickets until they get a favorable outcome. Lightning developer Rusty Russell raised this concern in 2018: a participant "can just retry until you get the desired skew." Secure implementations must ensure that both parties commit to their random inputs before either reveals, making selective retries detectable or impossible.

No Standardized Implementation

As of late 2026, no standardized Bitcoin or Lightning protocol for probabilistic payments exists. The 2025 OP_RAND emulation proposal demonstrates feasibility but lacks formal security analysis. Academic designs like MicroCash and the Pass lottery protocol remain research prototypes. Adoption depends on consensus around a randomness mechanism that is both Script-compatible and resistant to manipulation.

Regulatory Ambiguity

Probabilistic payments resemble lotteries or gambling from a legal perspective: one party pays money and may or may not receive value in return. Jurisdictions with strict gambling regulations may classify these mechanisms as regulated activities, even when the expected value equals a fair payment. Implementers must consider local laws before deploying lottery-style payment systems.

Counterparty Availability

Commit-reveal protocols require both parties to be online and interactive during the randomness generation phase. This is acceptable for streaming payments between connected devices but poorly suited to asynchronous payment scenarios where the recipient may be offline. Combining probabilistic payments with store-and-forward protocols remains an open design challenge.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.