Proposal: Automated Randomness Oracle for XCP Lotteries

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.


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 other not 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 supports equal/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

This looks pretty good.

Seems like you could go higher if you wanted.

11 - 1/2048
12 - 1/4096

16 - 1/65536

Is there any reason to stop at 11?

Someone pointed out in the slack that this is vulnerable to miner manipulation. A miner could hold off on mining a block if the hash doesn’t work in their favor.

So… an automated random oracle relying on a block hash probably isn’t going to be truly random enough.

  • Yes, can go as high as we want as long as the probabilities sum to 1 (the last probability must be repeated twice).

  • Miner manipulation (withholding attack) is theoretical, isn’t it? If understand correctly, the only thing a miner can do is chose to

  1. broadcast block or
  2. NOT broadcast block.
    If he gives up a block, he’ll lose a block reward. For this to be a problem, A) miner must play with XCP amounts higher than the BTC block reward, B) unless the miner is big, the chance of him finding and witholding the settling block is low. I think most players won’t mind this risk (they are risk seekers after all)

However, if we do want to address this, perhaps we can look at the block hash + Counterparty transactions in the previous block. A miner would first have to parse that block, which adds a time cost to him.

1 Like

Interesting idea.

Suppose could also include a way to disable the oracle if miner manip becomes an issue… Ideally, this would not require a code change and just hinge on another check per block processed (alongside the timestamp check). Thinking maybe a rotatable group of consensus addresses (CP Foundation?) that are checked for certain broadcast message commanding the oracle to disable or enable (most recent command/consensus is current state).

Miner manipulation should not be a concern in my opinion.
I wrote a separate post about it.

Stop should be depending on what numerical system you use, if you want ROI. You probably are much more knowledgeable in this field, so I could only offer you a simile. For example, European Roulette can be exploited if you spread-bet using an octadecimal numbering system, as that is what the numerical system it uses. It doesn’t matter there’s a zero as other numbers are less likely to appear. That is why most casino’s use countermeasures, such as a time policy, or magnets :slight_smile: .

On another note, I was mining at a multi-currency pool with a dashboard that offered account overview in btc/usd/euro. Now, USD/EU were close to what the banking system reported, but at one point in time there was a drastic difference in usd/eu, while the banking system didn’t display it. I don’t know if this is general knowledge or not, but all currencies are oriented around YEN. I knew this from hearsay, but I did some research when that happened, and financial spread betting didn’t show the real relationship between usd and euro, but when I looked at the charts of USD/YEN it was very obvious that the pool was correct. This is a very good trend, as financial betting is bad from an ethical standpoint, which I hope we all tend to uphold. Basically, its encouraging people to lend money for a higher return, and borrowers have to pay a higher interest rate. A lot of BTC was exchanged for YEN, and guess what, BTC price was about 1.134.55 USD at the time being - and 0.1135 being the numeric system most occurring in nature - Fibonacci, that is lovely. If you guys get rich of this, pls invest smart, relax and try to spread the wealth :slight_smile:

Random idea:

What if we added a second source of randomness that is out of the miner’s control? Maybe from another blockchain?

UPDATE: Ah, nevermind. I realize now this just moves the withholding attack into the hands of the Ethereum miners