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
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
|
Return-Path: <thomashartman1@gmail.com>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 87B09C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 15:41:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id 7732220009
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 15:41:43 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from silver.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id syHvdGAuBAHc
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 15:41:42 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com
[209.85.216.49])
by silver.osuosl.org (Postfix) with ESMTPS id 339F11FB6B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 15:41:42 +0000 (UTC)
Received: by mail-pj1-f49.google.com with SMTP id mt12so6562861pjb.4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 08:41:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=hzCyS5rtm3YwDMQD6EXv27cEpqwHLeNnc/F6YzTStfE=;
b=L7j+I+W4K67iIcRXG2GD7/6tVue6Jn7jIzpix18HWF5lD2+24l2ls9vW3zzzGUQVFu
8pkKQT3hnzb9jyLw/5TG6+LQ53c6YG52vtdIB73Atal2r6NlCltWFwcF8Nu65Pc0Ss8p
9lbjCJGph6G1rqr2tfw1IVvR9VoLp/SrC/G8h1ycXUxrTsaTu0etoNMeBaNAsxWlu0b/
nmNbSlE5Cq5HoOQ0vDOtj6rKbCjZt2RshmdAW3FZ7SRpWO7BeAAUWirKx5MDmvFkmppI
Ak9mGahedmNO0frOLqKHnfykMfynfUlXAsgwyYvqMxqF4J2FnqTGHPLJF/Ndy90kUCvn
6RBQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=hzCyS5rtm3YwDMQD6EXv27cEpqwHLeNnc/F6YzTStfE=;
b=HrbN5txvSeKLbLBkranjA4gxyBoLdQKyXCgUiQk11VNf2FV6ce8UBPGDehqwZMsiLI
PXLwW03ucUoeGGmU/lqxjK6SSnSUxAuRUE+azqH2NJhTvmXdKzhlanblCZ+B3AGrce/m
rArGT711iSJ2IEHVswpdwHbVlvSZUiTy1uiWZQr9obKepEbF6VL5pvb6j55ynidi/8E4
KK1rEWOCYRGyYVwt98Fz9M+GRHCl+W4HHDz+LUXPt2g7WZ9x5XS+F+uPMmAhk7x0LQmG
Pjq9n3bjJ+MbmEv4kXTlQ8fTeGv/JBcoGWmzsK76tVD82EURFhIoFVto6x6ce8ewV1iP
EFwQ==
X-Gm-Message-State: AOAM533QaCIkXq8yD90iYnBp4JWuplcD5mf6r+18QwhpK+MPHznZagsZ
jRE/WjhM4On+cltr+6WYDb12/gg5H29coZY82SUyK+AZi+ozOqTg
X-Google-Smtp-Source: ABdhPJyQS7MnbY/l+uobxIrwtIb0E2guWDh0IrxER3DRlrNQz9SbWwpBvpg1lkr57gApYjHVvorf0g1tpf/ny8M8vPE=
X-Received: by 2002:a17:902:b18b:: with SMTP id
s11mr8524857plr.211.1597592501323;
Sun, 16 Aug 2020 08:41:41 -0700 (PDT)
MIME-Version: 1.0
From: Thomas Hartman <thomashartman1@gmail.com>
Date: Sun, 16 Aug 2020 11:41:30 -0400
Message-ID: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset="UTF-8"
X-Mailman-Approved-At: Sun, 16 Aug 2020 15:50:50 +0000
Subject: [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 15:41:43 -0000
First, I would like to pay respects to tamas blummer, RIP.
https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
Tamas proposed an additional opcode for enabling bitcoin difficulty
futures, on this list at
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html
I really like this idea.
1) Trusted third parties are security holes
https://nakamotoinstitute.org/trusted-third-parties/
and oracles (eg discreet log contracts) are really just trusted third
parties in a blockchain's clothing. So truly ttp-free oracle-free on
chain contracts are good.
2) Difficulty is a proxy for energy, which is a proxy for usd, which
is what everyone currently cares about, which is bad. Energy is real.
Bitcoin traders should care about future difficulty, not future usd
price.
So in sum I think this is a very good idea, and I would like to
continue this work. Ideally I would like to see to completion the BIP
that Tamas was unable to produce.
Some initial thoughts on the technical merits.
My understanding is that adding a single op_difficulty operation as
proposed would enable not true difficulty futures but binary options
on difficulty.
https://en.wikipedia.org/wiki/Binary_option
As the wikipedia article notes, "While binary options may be used in
theoretical asset pricing, they are prone to fraud in their
applications and hence banned by regulators in many jurisdictions as a
form of gambling." The trouble is that because of the all or nothing
nature binary options are more of a gamble than a hedge. They are
popular with scammers, and even licensed binary options exchanges such
as nadex are under constant scrutiny by regulators.
Because any form of trusted third party-free / oracle free speculation
would encourage economic use of blockchain space and support the
transaction fee market, perhaps an economic case can be made for naive
op_difficulty as above even it has more of a flavor of gambling than
hedging. I think at a psychological level it would be good for a
ttp-free difficulty speculation tool to capture mindshare.
That being said, true difficulty futures -- real hedging and not just
gambling -- would be far healthier for bitcoin than binary options. I
am trying to wrangle what additional opcodes and protocol changes
would be required beyond just op_difficulty, to get true difficulty
futures on chain.
I envision something like this. To give some context: Current
difficulty is 16.9 Trillion. We're a week in to the current difficulty
regime so there's aboout 1000 blocks to retarget, and predicted next
difficuly is 18.5 Trillion. So let's pretend we sell a difficulty
future that pays out in sats, of the next difficulty divided by a
trillion. A reasonable price for this would be, say, 17.4 sats.
So in our op_difficulty utxo, one address (the futures buyer) would
get current difficulty / trillion, and the other address (the seller)
would get however much value is locked in the utxo, minus that amount
and miner fee. The payout would be limited by however much value is
locked in the utxo. Since difficulty adjusts very slowly I don't think
overflowing the locked up value would be much of a problem in
practice. We also want a mechanism to enable on-chain purchase of such
a contract, say for 17.4 sats.
One additional opcode that apparently would be required is division.
Some version of rshift could also do.
I am not clear if there is a way to solve the accounting for the
payouts, but perhaps there is a way to do this with covenants.
I'm somewhat new to protocol and script. I would appreciate if anyone
has any further advice on this.
Cheers, Thomas.
|
