1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
Return-Path: <aj@erisian.com.au>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 2E21EC07FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 22:29:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 2468D87D8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 22:29:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id GUEna5gC-MqX
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 22:29:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
by whitealder.osuosl.org (Postfix) with ESMTPS id 635F887D0C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 22:29:33 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian))
id 1k7R9c-0000SF-LU; Mon, 17 Aug 2020 08:29:30 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
Mon, 17 Aug 2020 08:29:23 +1000
Date: Mon, 17 Aug 2020 08:29:23 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Thomas Hartman <thomashartman1@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200816222923.zf47qrmqdiuv6yfp@erisian.com.au>
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] reviving op_difficulty
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Aug 2020 22:29:34 -0000
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
|
