summaryrefslogtreecommitdiff
path: root/34/02200d6640e3c08e976275a959475d57339adf
blob: 4fc93ee9804997c3f8cdec27a16da9b5c7321da3 (plain)
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
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 36DE0C03
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:22:03 +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 9531983A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:22:02 +0000 (UTC)
Received: by mail-ot1-f41.google.com with SMTP id r7so6495405otn.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 12:22:02 -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=yhaMG80hJG6VQGwhNG35wZoY4k7Kj6UfRIAZP19/Bes=;
	b=e5cGEmsoCM+FmP7/sUKpagjNUaMZgWqaisDfOh4B/dTltmt1RpgtDoqCmIs8dDYVow
	QBGmEq2dMmfuJJ5Yo3sqTD/m6ax0w06TQdevl8G3YtIKLMbyxIO9ijMcVf1LmTWNOBan
	srWH8Q8ohcu6LwC4mSIrM5i10NP4bmHNbibLLDKT0RXftmlgORTauvE0+oYdwVaVa2V4
	uRnnF2Xgg1/B4c+tQ5mM5Vi06JKUI2Z9PMi9n/yxzal9MtliLKxlogUtkIoGuQ+5oVPH
	i8/nfwQypQdr92kRql/r70W8e/rPOdGmu1AN8HwnL02OMcVckb/0mC6mlBipbqwfv8WI
	sKsg==
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=yhaMG80hJG6VQGwhNG35wZoY4k7Kj6UfRIAZP19/Bes=;
	b=Tm/DinLPWMLXHaUxHZATh2L35llIcKQ6J7sK1Fx22ycHP8MtmfHPU5SE8EL4tpclpB
	79NCaWjCuAsSqSQLOufkJWxR62Xhib9DwvgG+kDITv8id/TZuRwx/ingkO51o64ZZPqk
	v2o3geQtECO4RTcAC/Q/dFXXZuyKmEpidBNUuweF4VvcFkD1RSRSDthouZZHWZgzGgmK
	j5izoD5zWTKpxu4BbXv6h2dQty6TxHZDqgY/dQqtOlrASC0FN8pVlJZz4Xwnp5kLFvpv
	fcxPgnTcRV4iDIW8rVJ+/LDAQrB00W8RseYuQfZvX7upZUrEjTo07aa9R9xfT8p4/ZsB
	/4NA==
X-Gm-Message-State: APjAAAWCoFKM8hV1wykkFfG+KrO2gyMJ5teRXJm170MYYowoqYEajB/J
	jzsMBmDVVnrKD3YBIqbqjnWmmM4AvUzxGQD3Sko=
X-Google-Smtp-Source: APXvYqw5fr5oE7HkIuZG3IANBeYdwFp6gabIccjh6EvvixgE11fGBBpo1B+3gJKvWM4GgOsgJ0mudxXtkrAT49egz4Y=
X-Received: by 2002:a9d:5f04:: with SMTP id f4mr68537oti.240.1558639321669;
	Thu, 23 May 2019 12:22:01 -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>
In-Reply-To: <C6788578-80D4-44E7-8CF7-82AD15E3F12C@gmail.com>
From: Nathan Cook <nathan.cook@gmail.com>
Date: Thu, 23 May 2019 22:21:39 +0300
Message-ID: <CAGNXQMQG4KwAohfENYuUW=uABGshbJMYmdb_71ZtByCuj=14bQ@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000019e2a8058992ffa7"
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 19:22:48 +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 19:22:03 -0000

--00000000000019e2a8058992ffa7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 content o=
f
> 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 Luk=
e
> 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 ther=
eby
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditiona=
l
>> 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 blo=
ck
>> 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 ris=
k
>> 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
>>
>
>

--00000000000019e2a8058992ffa7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">It&#39;s true that it fetches the block h=
ash; the idea is to compare the block hash&#39;s numeric value to the desir=
ed (uncompressed) difficulty directly, using a 256-bit version of OP_LESSTH=
AN.</div><div dir=3D"ltr"><br clear=3D"all"><div><div dir=3D"ltr" class=3D"=
m_-660591142197038773gmail_signature" data-smartmail=3D"gmail_signature">Na=
than Cook</div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Thu, 23 May 2019 at 22:18, Tamas Blummer &lt;<a=
 href=3D"mailto:tamas.blummer@gmail.com" target=3D"_blank">tamas.blummer@gm=
ail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div><div>That opcode would not help as it fetches block hash and no=
t the content of the header.</div><br><div><blockquote type=3D"cite"><div>O=
n May 23, 2019, at 21:05, Nathan Cook &lt;<a href=3D"mailto:nathan.cook@gma=
il.com" target=3D"_blank">nathan.cook@gmail.com</a>&gt; wrote:</div><br cla=
ss=3D"m_-660591142197038773gmail-m_6837987650471914851Apple-interchange-new=
line"><div><div dir=3D"ltr">You can get the same effect with OP_CHECKBLOCKA=
THEIGHT as proposed by Luke Dashjr (<a href=3D"https://github.com/luke-jr/b=
ips/blob/bip-cbah/bip-cbah.mediawiki" target=3D"_blank">https://github.com/=
luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki</a>) if you also re-enable/ex=
tend certain opcodes like OP_AND and OP_LESSTHAN. See=C2=A0<a href=3D"https=
://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.ht=
ml" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-d=
ev/2016-September/013149.html</a>=C2=A0and the ensuing thread.<div><br clea=
r=3D"all"><div><div dir=3D"ltr" class=3D"m_-660591142197038773gmail-m_68379=
87650471914851m_403880825204588202m_-2348348040253356886gmail_signature">Na=
than Cook</div></div><br></div></div><br><div class=3D"gmail_quote"><div di=
r=3D"ltr" class=3D"gmail_attr">On Thu, 23 May 2019 at 21:33, Tamas Blummer =
via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex">Difficulty change =
has profound impact on miner=E2=80=99s production thereby introduce the big=
gest risk while considering an investment.<br>
Commodity markets offer futures and options to hedge risks on traditional t=
rading venues. Some might soon list difficulty futures.<br>
<br>
I think we could do much better than them natively within Bitcoin.<br>
<br>
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.<br>
A new OP_DIFFICULTY opcode would put onto stack the value of difficulty 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 those who enter=
ed the bet. <br>
The winner would broadcast. <br>
<br>
Once signed by both the transaction would not carry any counterparty risk a=
nd 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 serve significa=
nt economic interest of Bitcoin economy, and is compatible with 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" target=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.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div></div>

--00000000000019e2a8058992ffa7--