How Bitcoin’s Lightning Network Can Be Used as a Decentralized Betting Platform

At Stanford's Scaling Bitcoin workshop this past weekend, Tadge Dryja presented discreet log contracts, a framework designed to strengthen Bitcoin smart contracts while reducing how much users must trust the external information sources those contracts depend on. Dryja is a Research Scientist with MIT's Digital Currency Initiative.

Dryja began by defining what he means by smart contracts. They are "payment conditional on some external data." Throughout his presentation, he relied on a single example to make the concept concrete. Alice and Bob place a bet on what tomorrow's weather will be. To determine a winner, someone outside the Bitcoin network must provide weather information. That person fills the role of an oracle.

Today's Bitcoin implementation uses a 2-of-3 multisig address for such arrangements. The oracle signs to declare the winner, and that signature unlocks funds for the winning party. This method works in theory, but theory and practice diverge when real money sits on the line.

"These things work great with friends, but bitcoin is the currency of enemies," Dryja said.

If an oracle stops responding, the locked funds go nowhere. Both parties must cooperate to recover the money unless they can convince the oracle to act. One party can bribe or pressure the oracle to side with them and declare them the winner regardless of actual circumstances. An oracle can also hand down different verdicts for different bets. For the Alice and Bob weather wager, an oracle might report sunny conditions. For another contract using the same oracle, it could announce rain. That power to apply different rulings to different situations creates fundamental vulnerabilities.

"They have a lot of power, and it'd be better if you could have an oracle system where they couldn't equivocate and even better if they weren't aware of the contracts that people were using based on their data," Dryja said.

Discreet log contracts reshape how this oracle system functions. Alice and Bob place funds in a 2-of-2 multisig address, meaning both must agree before money moves. They pre-sign a collection of possible transactions in advance, an approach borrowed from the Lightning Network architecture that Dryja helped design. When the oracle releases its prediction, the winner merges that information with their own data and broadcasts the transaction that transfers their winnings to them.

The oracle's information gets blended with the winner's information before the transaction appears on the blockchain. This design prevents the oracle from knowing which contract, or even whether any contract at all, is using its data. All bets relying on a particular oracle's predictions follow the same rule set. No oracle can issue separate outcomes for separate contracts.

"You are trusting this oracle, but it's somewhat limited by the fact they can't equivocate and they don't have visibility," Dryja explained. "[The oracle] doesn't necessarily know Alice and Bob are entering this contract."

Users could combine multiple oracles into a single wager to distribute trust across several parties. The potential number of outcomes a contract could support is boundless.

The system also operates through the Lightning Network. When both parties reach agreement and work together, the transaction never touches the blockchain. Lightning channels offer two distinct benefits. No one except the two parties ever sees the details of the contract. The arrangement remains "pretty anonymous" if the blockchain must be used to settle a disagreement between the two sides.

"There's very little incentive to try to be a jerk," Dryja added regarding scenarios with mutual cooperation.

An oracle's disappearance or failure to perform doesn't trap the money. Both parties can recover their funds without needing the oracle's involvement or consent.

At the conclusion of his talk, Dryja addressed the investment community directly. "There's no token, and there's no ICO. Sorry (not sorry)," he said.