Pre CIP - Oracle for XCP-BTC Derivatives, Fee Hedging, Lottery

Development Counterparty
1

This is an improvement of the Instant Lottery CIP Draft.

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.
  • XCP/BTC Price
  • Broadcast the last XCP/BTC price from the DEX
  • Can be used to lessen or leverage impact of XCP price volatility
  • Random Number
  • 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.
2 Likes
2
1 Like
3

I like it. I have some questions:

  • Does this work in conjunction with existing CP betting APIs?
  • Why 130 blocks and not 144? Because you may have 2 decisions in 1 day which makes it more complicated to set more precise deadlines.
  • Would it make sense to use a SegWit address? This is a very random question, but I’m wondering in case SW makes tx fees cheaper
4

Yes.

With 144 (~24 hrs) settlements may always be during the night, depending on your time zone. With a few hours shorter cycle, you’ll every few days some settlements during convenient hours.

I don’t think a SegWit oracle address would change anything. Every broadcast from the oracle is a dummy transaction within the CP protocol, not a real Bitcoin tx.

5

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)?

6

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.

7

I think the more blocks the less variance. The lowest accuracy would be towards the end when you can wait anywhere from “minus 60” to 60 minutes or even more, in bad cases.