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 1-11 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 open-source 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 permission-less and pseudo-anonymous
-
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 anti-spam 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
.