Every 130 blocks (~21hr 40min) an automated oracle broadcasts data from Bitcoin and Counterparty. The oracle is hard-coded into the Counterparty protocol to make it completely trustworthy.
Some values it can broadcast:
BTC Fee Ratio
From each of the 10 previous blocks, take the coinbase tx amount minus block reward (currently 12.5 BTC) to get the total amount of fees. Divide by the block size to get the fee ratio. Broadcast the median value from the ten last blocks.
Most BTC businesses are hurt by high fees. Opening up for betting on the fee ratios let them hedge against this.
Broadcast the last XCP/BTC price from the DEX
Can be used to lessen or leverage impact of XCP price volatility
Derived from last block hash, broadcast a decimal between 0 and 1
Opens op for any probability, be it a 50-50 coin flip or 1-to-6 dice roll or 1-in-1000 lottery
The oracle will look at the current block height:
If Height mod 130 = 0 broadcast fee ratio
If Height mod 130 = 1 broadcast xcp price
If Height mod 130 = 2 broadcast random number
These are just three possible values. Any others you’d like to see?
In future updates new broadcast values can be added or existing ones removed.
Relatively few changes are needed to implement this:
Currently only equal / not-equal comparisons are possible. New bet types should allow for greater-than / not-greater-than
Currently some BTC dust is sent to Oracle when placing a bet. To save a few pennies, an update should make the Oracle address embedded into the bet message itself
Currently bet expiry is the number of blocks until an unmatched bet expires. There should be an option to specify the exact block height for expiry.
That’s not a bad idea, but it is also unpredictable.
on some days you’d have 2 events, so you have to be precise in creating bets. Two people betting on the same day in the same timezone could end up placing bets in different cycles.
unless one bets daily, it’s impossible for him or her to know when the next broadcast is supposed to happen. This creates less excitement for everyone.
it becomes more difficult to build this app into existing wallets or apps; instead of a simple betting module that doesn’t have to do any checking, one has to have the math built in, or query the blockchain and calculate when the next decision is going to happen. Imagine trying to set a betting reminder for “every 130 blocks” vs. “daily” on your phone. The latter is trivial to add to any wallet or app.
If a “moving announcement window” is desired, why not every 12 hours, midnight and noon (UTC)?
The timestamp is the block height (in this CIP) . I know the docs say it has to be a unix timestamp but this is incorrect. It can be any integer counter the oracle defines. By using block height is is trivial for users (and wallets) to know at what block the next broadcast is.
I see the disadvantage of using block height. If next cycle is in 90 blocks, you know it is in 15 hours +/- randomness in block creation. The more blocks to wait, the less accurate the time estimate is.
If instead starting a cycle at the first block after e.g. 16.00, you can expect this to happen somewhere in the first 0-15 minutes (at least 80% or so of the time). And I agree, this is a significant advantage.
But using block timestamps open up other issues:
A miner can set the timestamp at the real time +/- 2 hrs, I think.
A dishonest miner can abuse this.
The random number should be from the first block after the timestamp
A DEX price broadcast can be triggered by a miner 2 hr early
If fee/ratio broadcast is median of last ten blocks, then we should make broadcast ten blocks after timestamp
If we analyze these cases more thoroughly, I’m open to using timestamp for some/all feeds.