[bitcoin-dev] reviving op_difficulty

Anthony Towns aj at erisian.com.au
Sun Aug 16 22:29:23 UTC 2020


On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote:
> My understanding is that adding a single op_difficulty operation as
> proposed would enable not true difficulty futures but binary options
> on difficulty.

An alternative approach for this might be to use taproot's annex concept.

https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-5

The idea would be to add an annex restriction that's only valid if the
difficulty is a given value (or within a given range). Protocol design
could be:

  Alice, Bob, Carol, Dave want to make bets on difficulty futures
  They each deposit a,b,c,d into a UTXO of value a+b+c+d payable to
    a 4-4 of multisig of their keys (eg MuSig(A,B,c,D))
  They construct signed payouts spending that UTXO, all timelocked
    for the future date; one spending to Alice with the annex locking
    in the difficulty to Alice's predicted range, one spending to Bob
    with the annex locking in the difficulty to Bob's predicted range,
    etc

When the future date arrives, whoever was right can immediately
broadcast their payout transaction. (If they don't, then someone else
might be able to when the difficulty next retargets)

(Specifying an exact value for the difficulty rather than a range might
be better; it's smaller/simpler on the blockchain, and doesn't reveal
the ranges of your predictions giving traders slightly better privacy.
The cost to doing that is if Alice predicts difficulty could be any of 100
different values, she needs 100 different signatures for her pre-signed
payout, one for each possible difficulty value that would be encoded in
the annex)

Cheers,
aj



More information about the bitcoin-dev mailing list