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
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
|
Return-Path: <nathan.cook@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D2C6EEE4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:07:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com
[209.85.210.41])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8D306C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:07:49 +0000 (UTC)
Received: by mail-ot1-f41.google.com with SMTP id g18so6584695otj.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 13:07:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=H+8q1EiMFEDvbKddQXIVGCxAjJu41HAm2k6U1hYL5tU=;
b=erS0D09CnXn79USHad29gLjTdbuWyC5XBI8k4o2hRWqfYdBJCqZWgHy9mhtGoezZbv
6jFMHVc25smqlNqGo58TLTxoO5BN91dTZj6LlISnW9P99hgSkqwgw6YM/iSTF5KyMMLV
5hiIVzpGNna+vz3IGJthjZxN31dYASYckZCd5LE9Ay/6yEePuWvdyXx3FmjW8nvSpUJa
e/ZFy6n9FSeh40QvNXa/gXKq2n/tan4Je1n5LgPFyievJIao4FdigVqBb1HZVNR5xBDB
sAXeUUq+SIT7n2NlZcInwd22cLYILvtEi0G96r5hociBytKk+UJ5EELVxhiukkfuP4Mz
yu9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=H+8q1EiMFEDvbKddQXIVGCxAjJu41HAm2k6U1hYL5tU=;
b=Ecyv5rg4g33p7+VnZzKH29G3APAIlOoEI/XgNDvhWgfinT1qfI7dVH6jZFhqR5Soac
ARlfVN7+KKHH9OQFDCvltdpZLZzduF3kAB/ZIivuAQ9KwgdQLEBTyZClMk3CmgRDYgHa
/pOSDBJMIdyhA95uthg6KdRblsyDwo99TSQqftk9pYMGmR7gBCtMnE6djNNeuvBCkELx
S+0HadQjA12Jzt/51ZRCANqJjX8n0NReNhfEy77FYoWhzLM0FjRa/qcaH0Yy6XO1fuNM
HzzdLp7aBz/P1CT9+AZI+MjcD46OsivnmWbTcbOvcFQtwcAQIJwc/xi4H/Ss8Ebhr5Sd
F7cw==
X-Gm-Message-State: APjAAAWPrwqIMynQ8lK3AvWKxPW0yT6iixmPAzlsQFHnetOYEcYRLCcc
xuVYXS88IWR04WXlbuQNdBIpy6Nk6UzBGT8V7yAGXv2I
X-Google-Smtp-Source: APXvYqx0xpZZWTIery6Gc6c2NJr5inw5IHICsfyLCnRqkPIvC1q5OCiSBvXy8VfzFznckRkf6HT/KJvOTOwfNvozmYI=
X-Received: by 2002:a9d:d17:: with SMTP id 23mr24437513oti.122.1558642068713;
Thu, 23 May 2019 13:07:48 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
<CAGNXQMTLjkC+i7YcVyWC0Z0ixTkwhYR2qF4R0qeMNTT4ntj9oQ@mail.gmail.com>
<C6788578-80D4-44E7-8CF7-82AD15E3F12C@gmail.com>
<CAGNXQMQG4KwAohfENYuUW=uABGshbJMYmdb_71ZtByCuj=14bQ@mail.gmail.com>
<09724852-6971-4E5A-AAB5-3FBAEEA1D995@gmail.com>
<FC1E77CA-929C-40E1-A80E-ADC1CBD65A6E@gmail.com>
In-Reply-To: <FC1E77CA-929C-40E1-A80E-ADC1CBD65A6E@gmail.com>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Thu, 23 May 2019 23:07:30 +0300
Message-ID: <CAGNXQMQ9z4hOaZctVu6gR14yUd=JzxgyXcaxReYYRJdhauofOw@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d675da058993a2df"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 23 May 2019 20:08:34 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
without an oracle and 3rd party.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 23 May 2019 20:07:50 -0000
--000000000000d675da058993a2df
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
You're right, I didn't remember the whole procedure. You provide the
80-byte header in the spend script, duplicate it on the stack, hash it, and
compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on
the header with OP_AND to extract the difficulty. You can compare two
compressed difficulties directly by using more bit masking to separate the
exponent and mantissa.
On Thu, 23 May 2019 at 22:54, Tamas Blummer <tamas.blummer@gmail.com> wrote=
:
> Block hash can suggest much higher difficulty than what is in effect, so
> OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the
> level of the bet.
>
> > On May 23, 2019, at 21:45, Tamas Blummer <tamas.blummer@gmail.com>
> wrote:
> >
> > I see. The uncompressing needs to be done either to compare. How are
> chances for that BIP?
> >
> > This BIP would be explicitly offering risk managment of miners biggest
> risk.
> > Doing so without relying on external markets or oracle, self cointained
> would be an impressive and adequate feature.
> >
> > Tamas Blummer
> >
> >> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote:
> >>
> >> It's true that it fetches the block hash; the idea is to compare the
> block hash's numeric value to the desired (uncompressed) difficulty
> directly, using a 256-bit version of OP_LESSTHAN.
> >>
> >> Nathan Cook
> >>
> >>
> >> On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com>
> wrote:
> >> That opcode would not help as it fetches block hash and not the conten=
t
> of the header.
> >>
> >>> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
> >>>
> >>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by
> Luke Dashjr (
> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you
> also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/01=
3149.html
> and the ensuing thread.
> >>>
> >>> Nathan Cook
> >>>
> >>>
> >>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >>> Difficulty change has profound impact on miner=E2=80=99s production t=
hereby
> introduce the biggest risk while considering an investment.
> >>> Commodity markets offer futures and options to hedge risks on
> traditional trading venues. Some might soon list difficulty futures.
> >>>
> >>> I think we could do much better than them natively within Bitcoin.
> >>>
> >>> A better solution could be a transaction that uses nLocktime
> denominated in block height, such that it is valid after the difficulty
> adjusted block in the future.
> >>> A new OP_DIFFICULTY opcode would put onto stack the value of
> difficulty for the block the transaction is included into.
> >>> The output script may then decide comparing that value with a strike
> which key can spend it.
> >>> The input of the transaction would be a multi-sig escrow of those who
> entered the bet.
> >>> The winner would broadcast.
> >>>
> >>> Once signed by both the transaction would not carry any counterparty
> risk and would not need an oracle to settle according to the bet.
> >>>
> >>> I plan to draft a BIP for this as I think this opcode would serve
> significant economic interest of Bitcoin economy, and is compatible with
> Bitcoin=E2=80=99s aim not to introduce 3rd party to do so.
> >>>
> >>> Do you see a fault in this proposal or want to contribute?
> >>>
> >>> Tamas Blummer
> >>>
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev@lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
>
>
--000000000000d675da058993a2df
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">You're right, I didn't remember t=
he whole procedure. You provide the 80-byte header in the spend script, dup=
licate it on the stack, hash it, and compare to what OP_CHECKBLOCKATHEIGHT =
gives you.=C2=A0Then you do bit masking on the header with OP_AND to extrac=
t the difficulty. You can compare two compressed difficulties directly by u=
sing more bit masking to separate the exponent and mantissa.<div><br></div>=
</div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On T=
hu, 23 May 2019 at 22:54, Tamas Blummer <<a href=3D"mailto:tamas.blummer=
@gmail.com">tamas.blummer@gmail.com</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex">Block hash can suggest much higher diffi=
culty than what is in effect, so OP_CHECKBLOCKATHEIGHT would not work to de=
cide if difficulty is above the level of the bet.<br>
<br>
> On May 23, 2019, at 21:45, Tamas Blummer <<a href=3D"mailto:tamas.b=
lummer@gmail.com" target=3D"_blank">tamas.blummer@gmail.com</a>> wrote:<=
br>
> <br>
> I see. The uncompressing needs to be done either to compare. How are c=
hances for that BIP?<br>
> <br>
> This BIP would be explicitly offering risk managment of miners biggest=
risk.<br>
> Doing so without relying on external markets or oracle, self cointaine=
d would be an impressive and adequate feature.<br>
> <br>
> Tamas Blummer<br>
> <br>
>> On May 23, 2019, at 21:21, Nathan Cook <<a href=3D"mailto:natha=
n.cook@gmail.com" target=3D"_blank">nathan.cook@gmail.com</a>> wrote:<br=
>
>> <br>
>> It's true that it fetches the block hash; the idea is to compa=
re the block hash's numeric value to the desired (uncompressed) difficu=
lty directly, using a 256-bit version of OP_LESSTHAN.<br>
>> <br>
>> Nathan Cook<br>
>> <br>
>> <br>
>> On Thu, 23 May 2019 at 22:18, Tamas Blummer <<a href=3D"mailto:=
tamas.blummer@gmail.com" target=3D"_blank">tamas.blummer@gmail.com</a>> =
wrote:<br>
>> That opcode would not help as it fetches block hash and not the co=
ntent of the header.<br>
>> <br>
>>> On May 23, 2019, at 21:05, Nathan Cook <<a href=3D"mailto:n=
athan.cook@gmail.com" target=3D"_blank">nathan.cook@gmail.com</a>> wrote=
:<br>
>>> <br>
>>> You can get the same effect with OP_CHECKBLOCKATHEIGHT as prop=
osed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/bips/blob/bip-cb=
ah/bip-cbah.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.=
com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enabl=
e/extend certain opcodes like OP_AND and OP_LESSTHAN. See <a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.htm=
l" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2016-September/013149.html</a> and the ensuing thread.=
<br>
>>> <br>
>>> Nathan Cook<br>
>>> <br>
>>> <br>
>>> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev &l=
t;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank=
">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
>>> Difficulty change has profound impact on miner=E2=80=99s produ=
ction thereby introduce the biggest risk while considering an investment.<b=
r>
>>> Commodity markets offer futures and options to hedge risks on =
traditional trading venues. Some might soon list difficulty futures.<br>
>>> <br>
>>> I think we could do much better than them natively within Bitc=
oin.<br>
>>> <br>
>>> A better solution could be a transaction that uses nLocktime d=
enominated in block height, such that it is valid after the difficulty adju=
sted block in the future.<br>
>>> A new OP_DIFFICULTY opcode would put onto stack the value of d=
ifficulty for the block the transaction is included into.<br>
>>> The output script may then decide comparing that value with a =
strike which key can spend it.<br>
>>> The input of the transaction would be a multi-sig escrow of th=
ose who entered the bet.<br>
>>> The winner would broadcast.<br>
>>> <br>
>>> Once signed by both the transaction would not carry any counte=
rparty risk and would not need an oracle to settle according to the bet.<br=
>
>>> <br>
>>> I plan to draft a BIP for this as I think this opcode would se=
rve significant economic interest of Bitcoin economy, and is compatible wit=
h Bitcoin=E2=80=99s aim not to introduce 3rd party to do so.<br>
>>> <br>
>>> Do you see a fault in this proposal or want to contribute?<br>
>>> <br>
>>> Tamas Blummer<br>
>>> <br>
>>> _______________________________________________<br>
>>> bitcoin-dev mailing list<br>
>>> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
>>> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.org/mailman/listinfo/bitcoin-dev</a><br>
>> <br>
> <br>
<br>
</blockquote></div></div>
--000000000000d675da058993a2df--
|
