Proposed Feature
An oracle built into the protocol which periodically broadcasts a random number.
It will broadcast an integer value with the following probabilities.
 Prob(1) = 1/2
 Prob(2) = 1/4
 Prob(3) = 1/8
 …
 Prob(9) = 1/512
 Prob(10) = 1/1028
 Prob(11) = 1/1028
As with any other feed, anyone can place bets on any outcome. E.g. Alice and Bobs play on value=1 to simulate a coin flip. Carly and Dave simultaneously play on value=10 where Carly has a tiny chance of winning a huge amount and Dave is ‘the house’ with an edge.
Implementation
When Counterparty processes a block, it will check if
 this is the first block today with a timestamp after 3am, 9am, 3pm or 9pm UTC?
If yes, create a new broadcast transaction with the following parameters:
 Address = 1RandomNumberXXXXX5jfxc (a burn address  TODO needs a valid checksum)
 Text = Random Int = {Value}
 Value = {Value}
 Fee Fraction = 0
 Timestamp = {Current block’s timestamp}
The value is a random integer from 111 with the probability distribution described above. The value is derived from a randomness function with the current block’s blockhash as seed.
The broadcast will be added to the Counterparty database as if it were a normal Counterparty transaction.
Playing on the Feed
As with any other feed, two bets will match if they have
 the same target value
 the same deadline timestamp
 one is
equal
, the othernot equal
 matching or overlapping odds
Two examples:
Alice and Bob play a simple coin flip game. Both A and B set target value = 1. They put deadline at tomorrow’s date at 3pm. A plays on the outcome equal 1 and B sets it not equal 1. Both put wager = 1 XCP and counterwager = 1 XCP.
The bets match, and both A and B now have 1 XCP escrowed. The first oracle broadcast with a timestamp after 3pm tomorrow settles the bet. At the first block after 3pm, the settling broadcast is generated. It turns out value = 3. B, who bet on not equal 1, wins. He gets the 2 XCP.
Carly bets 1 XCP on equals 10. Since this is a very unlikely event, she asks for a counterwager of at least 900 XCP. Dave is fine with this. He then puts 900 XCP on NOT equal 10 and demands a counterwager of only 1 XCP.
Mathematically speaking, Carly expects to end up with only 901 * 1/1028 = 0.88 XCP, which is less than the 1 XCP she initially played with. She’s okay with the negative expectancy, as the odds are anyway better than at any other lottery. Dave takes the opposing side. He views this as a business opportunity. He risks 900 XCP and is almost certain to end up with 901 XCP. There’s a tiny risk he’ll lose all 900 XCP though, but he’s confident he’ll win in the long run.
Value Proposition

Lotteries are a multi billion dollar industry. They all feature the same fundamentals; bet a small amount for a tiny chance of winning a huge amount; players always have a negative mathematical expectancy

Unlike tradional lotteries, the XCP payout amounts are set dynamically. This will force a market outcome, which is likely much better for the players than most (or all) established lotteries today

No trust needed. The oracle is automatic and its behavior is in the opensource Counterparty code

Minimal fees. A player can place a bet days in advance, thus set a low transaction fee. Only one transaction is needed to play

No registration. Bitcoin and Counterparty are permissionless and pseudoanonymous

XCP is deflationary. As more players come along and buy XCP to play, the XCP held by existing players should go up in value. Imagine if this were the case in a casio; each chip would be more valuable when you leave than when you entered
Technical Considerations

No modification of existing protocol code should be needed. Just add the oracle code right after a block has been parsed. A new oracle broadcast is added just as any other broadcast, and from there on it exists in the database as any other Counterparty transaction

The computational weight should be negligible

The storage cost in the database should be negligible with just four transactions per day

The proposed probabilities simulate runs of coin flips. Dice rolls would require other probabilities

Ideally the random number should be a uniform decimal between 0 and 1. It would make any probability possible to bet on BUT it would require a new bet type;
greater than/not greater than
. The current protocol only supportsequal/not equal

To place a bet you need to send some BTC dust to the oracle address. This will be a burn address. This may be considered a good thing; an antispam fee. If not, a new way to encode bet transaction must be introduced, and I think there’s enough space in op_return to include the oracle address there