From: Anthony Towns <aj@erisian•com.au>
To: Thomas Hartman <thomashartman1@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Date: Mon, 17 Aug 2020 08:29:23 +1000 [thread overview]
Message-ID: <20200816222923.zf47qrmqdiuv6yfp@erisian.com.au> (raw)
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
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
next prev parent reply other threads:[~2020-08-16 22:29 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-16 15:41 Thomas Hartman
2020-08-16 18:59 ` Tier Nolan
2020-08-17 5:04 ` ZmnSCPxj
2020-08-17 19:48 ` Thomas Hartman
2020-08-17 23:14 ` ZmnSCPxj
2020-09-01 20:07 ` Thomas Hartman
2020-09-02 14:40 ` Thomas Hartman
2020-08-17 21:55 ` Tier Nolan
2020-08-19 21:15 ` Thomas Hartman
2020-08-19 23:32 ` Thomas Hartman
2020-08-16 22:29 ` Anthony Towns [this message]
2020-08-22 16:46 ` David A. Harding
2020-09-02 18:27 ` Jeremy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200816222923.zf47qrmqdiuv6yfp@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=thomashartman1@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox